Dell Venue 8 Pro imaging/eMMC

[AsGF2MX]

@Tom-Elliott It says 4.2.0 i686

[Sebastian Roth]

Tom pointed me to a discussion here in the forum about a similar issue some time ago. Search for emmc and you’ll find a thread with a user called d4rk3.

Could you please enter a FOG debug session and run the following two commands fdisk -l /dev/mmcblk0 and lsblk /dev/mmcblk0
I guess the output of fdisk will be empty. Would be interesting to see what you get from lsblk.

As far as I can see clonezilla is showing the partitions with fdisk because it is debian based and debian has added the mentioned patch. See here: https://launchpad.net/debian/+source/linux/3.16.7-ckt9-1 (“eMMC: Don’t initialize partitions on RPMB flagged areas”) I downloaded the debian patchset to look through it and it’s got this patch by Nell Hardcastle (https://dev-nell.com/rpmb-emmc-errors-under-linux.html) in it!

@Tom-Elliott Would you mind adding this patch to 4.2? I know you’ve done this for d4rk3 some months ago. Didn’t seam to work for him but I wonder why.

[Tom Elliott]

@Uncle-Frank I’m rebuilding now, should be done in about 5 minutes. I added the patch. Just a note, I don’t have a simple way to patch this to work around the block. I had to manually code the patch, which would only be good on a one-to-one patch of the version as things change quite often between kernel updates.

I, again, won’t know if this works until somebody tests/confirms it as well. Hopefully your suggestion here will be viable and help ALL users out with eMMC SSD Cards.

[Tom Elliott]

Patched mmc drivers and built kernels are now up and running. You can update by choosing the latest kernels in the kernel update list, or by simply rerunning installer if you’re running development versions.

Thank you,

[d4rk3]

I’ll give the kernel a whirl tomorrow at work and report back if anything’s changed.

[AsGF2MX]

@Uncle-Frank @Tom-Elliott the output of fdisk -l /dev/mmc* or lsblk with the same returns no such file or directory. This is even with the newest kernel.

Since we don’t even see the MMC device, I’ve been going through a few things over the weekend and I might have found something. The eMMC device is operating in ACPI mode per windows and also per Clonezilla. The HS200 device sits at ACPI\80860f41:0001 Comparing the dmesg outputs between clonezilla and fog, I don’t see the above address anywhere in the FOG dmesg output.

After a little poking around for Kernel issues with Baytrail, it turns out there is an extra kernel option needed to make Baytrail work in a sane manner: CONFIG_PINCTRL_BAYTRAIL=“y”

When I looked at the kernel options with your name in git, the above is not configured or even defined. Would you be able to set the above to “y” and recompile the 32-bit kernel once more please? If it is already there then something is a miss.

This seems to very specific to Baytrail which the Venue is using. I do not have any info on Cherrytrail. If this works then the patch sets applied earlier should also take out the rpmb issue so it should theoretically be the one kernel that just works!

References:
https://lists.debian.org/debian-kernel/2015/09/msg00023.html
https://bbs.archlinux.org/viewtopic.php?id=193180
https://embedded.communities.intel.com/thread/7507

[Sebastian Roth]

Looking through the links I find they are talking about SD cards not eMMC drives. Maybe I got this wrong?

I wish I had one of those devices here to poke around with it myself to make it work.

[AsGF2MX]

@Uncle-Frank Not all of them but the SD and eMMC controllers are on die so being unable to address them correctly could explain why it doesn’t show. I would think that at least mmc0 would show in FOG but it doesn’t - there is no dev node for the micro sd card - the SD card shown as SDA1 is actually a USB SD card reader.

http://cdn.arstechnica.net/wp-content/uploads/2013/09/Screen-Shot-2013-09-13-at-6.32.07-PM-640x423.jpg

Thoughts?

[Tom Elliott]

I’m adding CONFIG_PINCTRL_BAYTRAIL and other devices to the kernel as we speak, will be about 5-10 minutes.

[Tom Elliott]

Kernels are updated if you would be willing to give them a shot.

[AsGF2MX]

@Tom-Elliott I gave it a shot and no dice. Something is amiss and I keep comparing the Clonezilla boot process and that of FOG. The only thing I do notice is that the boot process of FOG is a whole lot quicker than that of FOG and also the /proc/iomem from clonezilla is a lot longer.

I am wondering if we need to patch the initxz with a /lib/modules/modules.builtin to make this work as I don’t see modules loading and am not sure how to detect if a module compiled in is actually getting used or not.

[Wayne Workman]

@AsGF2MX We need to get @Tom-Elliott a Dell Venue 8 pro he’s had a rough day.

http://www.newegg.com/Product/Product.aspx?Item=N82E16834298232&Tpk=N82E16834298232

[Sebastian Roth]

@AsGF2MX Could you please upload the full dmesg output of FOG and Clonezilla?

You should be able to safe the output on your NFS share. Bootup Clonezilla/FOG in debug mode and then:

mkdir /images
mount -t nfs -o nolock x.x.x.x:/images /images
dmesg > /images/dmesg_fog.txt
umount /images

Where x.x.x.x is the IP address of your FOG server… Don’t copy/paste the files here (way too long) but attach or upload them (http://pastebin.com/).

[AsGF2MX]

@Uncle-Frank Had to disappear for a bit as I got buried for a bit but hopefully I’m not empty handed and I’ve got something.

@Tom-Elliott I took the make file from the SVN and went through a few compiles - started fat - with a lot of suspected options ticked and eventually one set worked.

A little bit of reading on eMMC interfaces and after going through a few posts in various places, I then took a different approach - add a few items and compile then recompile and retry. When I enabled a few extra options more towards the I2C and SPI interfaces, I ended up with one set that worked and my makefile is attached. There is an SPI and I2C bus involved but it took some digging to find the connection and unfortunately I didn’t bookmark the page before my browser crashed out.

I did try to pull the image and although there were a few errors (I don’t have the patch sets applied) but I also do think part of it may have been because the partitions are in fact bitlockered - still trying to figure that part out.

MMCEnabledConfig.32

This post wouldn’t be complete without the pictures and a request:

I am betting if you recompile with the above make and the patches you applied, at least @d4rk3 should be up and running and myself, I am trying to figure out if I can sysprep the unit for the purpose of testing so that fog can read the partitions but I will need a little while for that.

[Wayne Workman]

@AsGF2MX BRAVO!

[Tom Elliott]

I will compare the differences between them and see what I can come up with. This may take a bit though, as you don’t know the differences between what I had and you added directly. Like specifically. So it will be a little bit of a wait, but I hope you can bare it.

[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?