New eMMC with 3.8.13 kernel

GoogleGroups
1

I have a project that I have been working on for some several years. It started out on a BeagleBone White, but recently it was moved to the BeagleBone Green so it run off eMMC instead of an SD card. I have been using embedded Ubuntu 14.04 (trusty) with the 3.8.13-bone79 bb-kernel following the instructions at https://eewiki.net/display/linuxonarm/BeagleBone.

I just received a newer BBG last week and I was unable to flash my image to the eMMC. Monitoring the debug output, I noticed that the eMMC failed to initialize when the SD card was used so the flashing could not be done. After some research, it appears that the eMMC hardware has been changed on the Green. On the BBB Wiki, I also saw that the Black appears to have a similar change in Rev C. Experimenting with several of the flashing images on http://beagleboard.org/latest-images, the one one I can get working is the Debian 8.4 Jessie version.

Is there a way to get the eMMC working with embedded Ubuntu 14.04 (trusty) with the 3.8.13-bone79 bb-kernel?

Thanks!

Mark

2

I believe you need the correct board file. e.g. it’s possibly missing from your build.

$ ls /boot/dtbs/4.4.9-bone-rt-r10/
am335x-abbbi.dtb am335x-boneblack-cape-bone-argus.dtb am335x-chiliboard.dtb
am335x-arduino-tre.dtb am335x-boneblack-emmc-overlay.dtb am335x-evm.dtb
am335x-baltos-ir5221.dtb am335x-boneblack-hdmi-overlay.dtb am335x-evmsk.dtb
am335x-base0033.dtb am335x-boneblack-nhdmi-overlay.dtb am335x-lxm.dtb
am335x-bone-cape-bone-argus.dtb am335x-boneblack-overlay.dtb am335x-nano.dtb
am335x-bone.dtb am335x-boneblack-wl1835mod.dtb am335x-olimex-som.dtb
am335x-boneblack-audio.dtb am335x-boneblack.dtb am335x-pepper.dtb
am335x-boneblack-bbb-exp-c.dtb am335x-bonegreen-overlay.dtb am335x-sancloud-bbe.dtb
am335x-boneblack-bbb-exp-r.dtb am335x-bonegreen-wireless.dtb am335x-sl50.dtb
am335x-boneblack-bbbmini.dtb am335x-bonegreen.dtb am335x-wega-rdk.dtb

3

Thanks William, but I checked those already. Unfortunately I think the issue is deeper than that in the kernel drivers (or a combination of both). It looks like a simple hardware change to a larger 4GB eMMC (same Micron chip series), but the mmc driver fails when reading the chip configuration. Specifically I see the driver emit an error on the EXT_CSD register version. From dmesg:

[0.940510] mmc1: unrecognised EXT_CSD revision 7
…
[0.945454] mmc1: error -22 whilst initialising MMC card

4

That’s Odd, I’m running BeagleBoard.org Debian Image 2016-05-01 on a RevC ( 4G emmc ) right now. I’ve also ran many of Roberts images prior to this one as well. Including several Wheezy images with 3.8.x kernels.

I’ve also been following Robert eewiki build guide since 2013, while building many different kernels. But I think most of those were for a 2G A5A.

5

the latest version of the bbg (and bbgw) have newer (and cheaper $
wise) eMMC (eMMC5.1)

two patches are needed on 3.8.13:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=6636bad839d9936e73e48c4841eda83a58fcdb53
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=03a59437ef6b6ad7fb0165cb9b96c08d6bf057fc

i'll be pushing out 3.8.13-bone80 shortly with that fix..

Regards,

6

Yeah, I was about to post back and say . . .

[0.940510] mmc1: unrecognised EXT_CSD revision 7

Just seem like newer unrecognized( yet ) hardware.

7

card->ext_csd.rev = ext_csd[EXT_CSD_REV];

  • if (card->ext_csd.rev > 6) {
  • if (card->ext_csd.rev > 7) {
    pr_err("%s: unrecognised EXT_CSD revision %d\n",
    mmc_hostname(card->host), card->ext_csd.rev);
    err = -EINVAL;

Dare I ask who wrote that code ?

8

atleast that "mess" was fixed in:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=03a59437ef6b6ad7fb0165cb9b96c08d6bf057fc

with an explanation..

but yeah, not forward thinking at all..

Regards,

9

Yeah, the guy who wrote it and the guy who signed of on it probably know that particular code better than I. But a fixed value in a code bock, buried only god knows how deep in a source file is not good practice. A const would have been better, but I wonder how important that check really is. Is that code even needed ?

10

Thanks Robert, you’re awesome (as always)! Ironically after spending some time looking at the JEDEC eMMC spec this morning to confirm that it should be forward compatible; I just finished commenting out that section of code and rebuilding to see if it would work… and it did. I am more confident now knowing that the official patches do the same thing.

Mark

11

hah ! I did not even look at the second patch. And it does exactly what I was thinking. Remove that whole check . . .heh

So now I’m curious why that code was there in the first place ? Someone flexing their eWenus, just to break the code when a newer version of hardware is used ?

12

hah ! I did not even look at the second patch. And it does exactly what I
was thinking. Remove that whole check . . .heh

So now I'm curious why that code was there in the first place ? Someone
flexing their eWenus, just to break the code when a newer version of
hardware is used ?

Looks like it was a spec change:

B.8. Changes from version 4.51 to 5.0

Edit to support Ver.5.0 in EXT_CSD_REV[192]
o Note: A host system should work properly considering future eMMC version. For
example, a host system is expected not to exit only due to the EXT_CSD_REV[192]
value greater than 7 which will be used for next e•MMC revision.”

So my guess, in 4.51 or earlier, something said to exit in that situation.

Regards,

13

It is my understanding that Linux has an issue with 5.1. That is why we get these devices in 4.1 mode. I suspect the lack of experience on this issue from the Green Team caused this to happen. It should have triggered a revsion change at the least.

However, some of the new controllers inside the eMMC will not support 4.1 in the future. So sooner of later, something may need to happen. I have no idea what the exact issue is.

Gerald

14

At first I was disappointed that the BBG circuit board revision had not changed. However, it was really a software issue and the boards can be differentiated by the eMMC chip marking:

Part Number FBGA Code (Marking)

OLD MTFC4GACAAAM-1M WT JWA57
NEW MTFC4GACAJCN-1M WT JY976

Mark

15

Hi,

I was able to recompile the kernel (3.8.13-bone70, debian 7)commenting the line in mmc.c.
But the image is running fine on the sd card.
When i try to flash to emmc it says panic occured and it hangs.
What might be the problem. I am stuck for days now.

Regards,
Abhilash