Dell Venue 8 Pro imaging/eMMC

[AsGF2MX]

@Tom-Elliott I can definitely hold on for a little bit. I am not sure if a diff is sufficient to identify what changed but it has to do with SPI and I2C options mostly. Not sure if there is some sort of cheat sheet with all kernel options and path in menuconfig but if not, it will have to be side by side compare. I took the base and added only the SPI and I2C options but I will need a bit to pick the options again and document what I had to change exactly.

@Wayne-Workman Fingers crossed we can see this through to completion and put Bay Trail on FOG’s compatibility list. Poking around the forums, I did see a request from @reub_rester (https://forums.fogproject.org/topic/5238/trying-to-image-a-dell-venue-pro-11-5130-x64) and his issue was the same as mine so this should help it get further along. The only thing is that in the device basic options, he will need to put in /dev/mmcblk0 and at least inventory will work.

@Uncle-Frank If need be, I will grab the dmesg output. Just let me know.

Also it seems I misread the error message on image pull. I stripped bitlocker from one of the units only to find it would throw the same error. So I think what is happening is a mount point issue.

I am not sure where the relevant code is or how complicated it would be to modify but it looks like what is happening is that the enumeration is not expecting two character suffixes.

Typical setup is: /dev/sdXY where x is usually a and Y could be anything from 1 to 5.
MMCBLK setup is /dev/mmcblkXpY and unlike the above, X is a number and so is Y.

However it looks like partition resize input is not being fed Y although the script before it is showing the path correctly. Function input variable size too small?

I am poking around to figure where this comes out of but if anyone has any pointers, I can have a look.

[AsGF2MX]

@Tom-Elliott @Wayne-Workman @Uncle-Frank

Regarding the error that was being displayed earlier, I did manage to track it down and it requires a minor patch to partition-functions.sh in the ram disk. There is an extra character in addition to the number that needs to be stripped out. I just re-piped through another sed and tested and it works. The patch takes care of all functions and it has no impact on hdXY or sdXY devices unless you really have to clone sdp1 then you might have a problem.

I got as far as resizing partitions before what looks like an attempt to hit the rpmb part of the emmc caused the whole it error out. Got this far:

Still poking around but I think the missing patches is probably what is causing this. But I could be wrong. I am not sure what is triggering the updates to the rpmb.

part-funcs-mmcmod.patch

[Tom Elliott]

@AsGF2MX I did work to get a “cheat sheet” but the kernel’s are ever changing so I gave up on that approach.

A diff -u <originalfilename> <changedfilename> is sufficient to see the changes. Just remember to use the TomElliott.config.32 and your Config (as I saw it is 32 as well?) so that we don’t get a change of all the differences between a 32 bit config and a 64 bit one.

[AsGF2MX]

@Tom-Elliott Here you go. It is 32-bit as the 64 bit kernel doesn’t seem to working with the Venue, crashes out right after iPXE gets done. 32-bit has been good to me so far.

Point taken on the cheat sheet - hopefully this does the trick.

MMCMod-TomElliotConfig.32.patch

On another note on the init_32.xz - I tried to get rpmb to stay out by using udev rules but then I noticed you have got part of the rules there. Is there any way to stop the unit from rebooting and drop to a shell to see what last happened before it failed?

[Sebastian Roth]

@AsGF2MX Wow, you are doing a great job here! Thanks a lot for digging into the details and sharing all this here! Awesome.

I tried comparing the kernel configs and I found CONFIG_X86_INTEL_LPSS to be set in your new config. According to this post this is exactly what might be missing to make eMMC working with Bay Trail: https://chromium-review.googlesource.com/221327

And too CONFIG_SPI (with some more sub options) is set in AsGF2MXs config. SPI also seams to be related to eMMC and I guess I will not hurt to be enabled (keep fingers crossed).

I am not sure about the I2C stuff. Both configs have I2C in gerneral enabled. Just some of the I2C settings are different. @AsGF2MX could you please try Toms original config (http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/kernel/TomElliott.config.32) and enable INTEL_LPSS + SPI and see if it is working??

Maybe I have missed that part of the discussion but why do you use resizable image type?? Maybe use “single disk - multiple partitions” or even “raw” first to get it working without poking around patching the scripts (this might be the second step).

[Sebastian Roth]

@AsGF2MX said:

On another note on the init_32.xz - I tried to get rpmb to stay out by using udev rules but then I noticed you have got part of the rules there. Is there any way to stop the unit from rebooting and drop to a shell to see what last happened before it failed?

Do you have the patch applied to your kernel (https://dev-nell.com/rpmb-emmc-errors-under-linux.html). This should keep rpmb out of the way I think. You might be able to get along without rebooting by running a debug upload session.

[AsGF2MX]

@Uncle-Frank That was a good call on the single-disk multiple partitions.

Need a few moments to recompile the kernel will test it out as well.

By the way, my kernel is not patched - straight off the kernel site, along with Tom’s 32 bit config file, only magic was the ones you pointed out and possibly the little modification to the partition functions.

[Wayne Workman]

All you guys are amazing… keep up the great work!!

[Joe Schmitt]

I’d just like to step and and thank you @AsGF2MX. You’re doing an AMAZING job helping us debug this.

[Tom Elliott]

I’ve, once again, updated the kernels. I followed the information from the patch. I just basically made a replica.

Please try them when you can and keep us informed.

[AsGF2MX]

@Jbob Thank you but honestly I have all of you to thank - especially Tom with my obscure and off beat recompile requests! Haven’t had a dev box (VM or otherwise) since 2008 so I’m a bit rusty but I’m glad I can contribute back to the project in some way.

@Tom-Elliott I have not had a chance to test your kernel yet or finish up on @Uncle-Frank 's request as I had to step out for a few moments and I had triggered a download before I read the message. The good news is the upload succeeded!

Will check to see the OS made it back in a sane state and if it’s good, I will test your kernel right after.

[AsGF2MX]

@Tom-Elliott The upload and download on my compiled kernel worked - not so much as a hint of something being wrong. Everything works! Currently testing the kernel that you just uploaded and promising so far on upload. I think the unit has just enough battery to go through a download before it shuts off.

One point of note I should mention (in case someone comes across this post while looking for Venues and PXE booting) is that I am using Level One’s USB-301 Fast Ethernet adapter. I have both the AXIS (died after the first post!) and Realtek variants but all screenshots I’ve posted in this thread are using the Realtek variant.

[Wayne Workman]

@AsGF2MX

What’s the exact model of the adapter? And what boot file are you using?

[AsGF2MX]

@Wayne-Workman Adapter is Level 1 USB-0301 v4 http://global.level1.com/Network-Card/USB-0301/p-3285.htm which uses a Realtek chip. The v3 used the AXIS chip which Dell puts in its docks.

I’m using the 32-bit ipxe and bzImage32 as well.

@Tom-Elliott Your kernel worked flawlessly. Downloaded and uploaded perfectly and managed to check everything just before the battery hit 0%.

@Uncle-Frank It will be a little while before I can test the changes you requested.

[Sebastian Roth]

@AsGF2MX said:

@Uncle-Frank It will be a little while before I can test the changes you requested.

Not sure if we really need any of those if everything seams to work for you now! Awesome…

The only thing still in question (as far as I can remember) is the kernel patch (https://dev-nell.com/rpmb-emmc-errors-under-linux.html). Might be all good without this… Unfortunatelly I can’t test this. All up to you. But I don’t see a need to test this if things seam to work for you!

[Tom Elliott]

@Uncle-Frank He was running my kernels too, and I did have that patch in there just for this reasoning.

OP, did the 64bit kernel work for you out of the box, or only the 32 bit?

[d4rk3]

IT WORKS!!! You guys are amazing!

I did have to set Host Primary Disk to /dev/mmcblk0 but that was it

Single Disk - Resizable works!

[Wayne Workman]

So much happiness in this thread, I can’t take anymore! Stop it! lol

[Tom Elliott]

@d4rk3 I’m sorry it has taken sooooo long man. I know we have been trying for a while. Thank you all in this thread.

[AsGF2MX]

@Tom-Elliott 64-bit didn’t work for me at all before - I will retest the latest build once more and see if there is a difference. I am currently running FOG with both the bzImage and init set to point to the 32-bit variant in FOG Configuration. I will hold back one unit from this lot for “testing” purposes so if you need me to test anything to fine tune things, I can help.

Also @d4rk3 how did you get single disk - resizable to work? I am still seeing errors. With the little patch on the ramdisk I applied, I can get further but not to the point I can image.

My init_32.xz is dated Aug 31 12:01 what is the date on yours?

@Uncle-Frank I think the patches have made Tom’s build a bit smoother than mine without the patches. Less chatter in front when it loads up. However I can confirm without any patches it works as well. I’m happy to help test any variants if you wish.