[U-Boot] "Writing to MMC(%d)... failed"

Wed Apr 29 11:15:48 CEST 2015

Hello Nathan,

On 04/28/2015 10:49 PM, Nathan wrote:
> On Tue, Apr 28, 2015 at 3:07 AM, Przemyslaw Marczak
> <p.marczak at samsung.com> wrote:
>> Sorry, I didn't reply last time, becouse I'm quite busy.
> No worries. I was really just keeping you apprised of my findings.
>
>> If I good remember, Exynos 54xx doesn't support sdhci, it has only dw mmc.
> I think I need to reiterate that I have the ODroid-U2 (Exynos 4412).
> I just didn't even know why dw-mmc was even being referenced in my case.
>

Yes, it's good, that you mention that. The odroid_defconfig was tested 
only on U3 and X2. You can found the info here: doc/README.odroid.

I understand, that we have many Odroid variants, and the config name 
suggest, that it can be used for any.

The SoC is the same as in U3, but maybe the revision is different or the 
part is different. You should check carefully, what's going on in the 
hardkernel's U-Boot for this board.
Please note, that there can be some things done by the BL1/BL2.

You can easy check your SoC proid by command: "md.l 0x10000000 0x1",
and the revision is: main.sub, where:
"main = val & 0xf0"
"sub = val & 0xf"

For U3, the reg "val" is 0xe4412220, so it is rev 2.0.

I don't remember exactly, but there was an issue with using bl1/bl2 for 
X2 and U3. It was about ability to boot the binary on both boards.
If I good remember the X2 binaries, doesn't boot on U3, but the version 
for U3, can boot on both.
This means, that the mainline U-Boot could require some additional 
things to do before boot on U2. Maybe it's just proper bl1/bl2, you must 
check this.

And as I wrote before, the dw-mmc driver is used for the eMMC slot card 
only, and sdhci driver is used for sd card slot.

>> The "pwr-gpio" is okay - the pin is not defined and not required here.
> OK, I'm really just grasping at straws, hoping something would be the
> cause of my problem and picking apart any error/warning. May very well
> be leading me away from the actual issue.
>
>> For this board's config, there are two mmc drivers:
>> - exynos dwmmc(mmc/exynos_dw_mmc.c) - channel 0 - for eMMC card slot
>> - s5p sdhci(mmc/s5p_sdhci.c) - channel 2 - for SD card slot
>> Each driver has it's own compatible id, which you can see in the array:
>> lib/fdtdec.c - > compat_names[COMPAT_COUNT]
> Yeah, I saw that compatible listing and was perplexed why the dw-mmc
> would have been picked out instead of sdhci. I think that was only
> when I pre-pended '/' to those 2 mmc alias items in the dts.
>
>> Note: This is quite different like for the drivers, which support the driver
>> model. We don't bind those drivers with the driver model yet.
> Ooooo, that sounds like a work-in-progress where I may be better off
> waiting until it has all been switched over.
>

This will probably take a time.

>> So now we init those drivers, by call the board_mmc_init() in
>> board/samsung/common/board.c - as you probably know - most of samsung boards
>> in U-Boot uses this common file, beside it's own board file.
>> If you not sure where to find the function, you can check, which common
>> files are compiled for your config:
>> cd board/samsung
>> find -name "*.o"
> Yeah, I was working my way back before and this time I was working my
> way forward.
>
>> And now, back to the issue with the warning, which you mentioned. This is
>> okay. I'm sure, that sdhci driver init is fine. You can study the function:
>> fdtdec_add_aliases_for_id() from lib/fdtdec.c
>> Remember, that this is the first introduced method for init the drivers with
>> the FDT support. But we are going to move all subsystems into the driver
>> model.
>>
>> Let's look at the fdtdec_add_aliases_for_id():
>> - first we find all compatible nodes,
>> - next we have an array "nodes[maxcount]" with the compatible nodes only
>> - and next we look for the "path" for our "mmc*" aliases, but only for the
>> compatible we can meet the condition: if (nodes[j] == node).
>> This is way you get the warning when init DWMMC driver.
>> This is ok.
> I'll have to look back over this again.
> Again, I don't think I would be using DWMMC because I am using my
> sd-card (sdhci).
> I don't remember if I posted this warning which occurs every time:
> "MMC:   fdtdec_add_aliases_for_id: warning: maxcount exceeded with
> alias 'mmc'"
>

You shouldn't worry about this. The mmc init starts for your sd card 
port. The one more thing is, that maybe the GPIO configuration is wrong.
It should be configured by the pinmux. Please check it by:
For GPK2:
Odroid # md.l 0x11000080 0x1
11000080: 02222022                               " ".
Odroid # md.l 0x11000088 0x1
11000088: 00000030                               0...
Odroid # md.l 0x1100008c 0x1
1100008c: 00003fdf

For GPK3:( with no eMMC inserted)
Odroid # md.l 0x110000a0 0x1
110000a0: 00000000                               ....
Odroid # md.l 0x110000a8 0x1
110000a8: 00001555                               U...
Odroid # md.l 0x110000ac 0x1
110000ac: 00000000

If your values are different, you can write them by using "mw" command, e.g:
"mw.l 0x11000080 0x02222022 0x1"

>> Which compiler are you using?
> Self-compiled using linux-from-scratch (clfs) as a "guide".
> $ armv7l-unknown-linux-gnueabihf-gcc -v
> Using built-in specs.
> COLLECT_GCC=armv7l-unknown-linux-gnueabihf-gcc
>
> COLLECT_LTO_WRAPPER=/home/user/Desktop/CLFS/cross-tools/bin/../libexec/gcc/armv7l-unknown-linux-gnueabihf/5.0.0/lto-wrapper
> Target: armv7l-unknown-linux-gnueabihf
> Configured with: ../gcc/configure --prefix=/cross-tools
> --build=x86_64-cross-linux-gnu --host=x86_64-cross-linux-gnu
> --target=armv7l-unknown-linux-gnueabihf
> --with-sysroot=/home/user/Desktop/CLFS
> --with-local-prefix=/armv7l-unknown-linux-gnueabihf
> --with-native-system-header-dir=/armv7l-unknown-linux-gnueabihf/include
> --disable-nls --enable-shared --disable-static
> --enable-languages=c,c++ --enable-__cxa_atexit --enable-c99
> --enable-long-long --enable-threads=posix --disable-multilib
> --with-mpfr=/cross-tools --with-gmp=/cross-tools
> --with-isl=/cross-tools --with-cloog=/cross-tools
> --with-mpc=/cross-tools --with-arch=armv7-a --with-float=hard
> --with-fpu=neon --disable-isl-version-check --with-system-zlib
> --enable-checking=release --enable-libstdcxx-time AR=ar
> LDFLAGS='-L/cross-tools/lib -Wl,-rpath -Wl,/cross-tools/lib'
> 'CFLAGS_FOR_BUILD=-O3 -pipe -march=corei7 -mtune=corei7'
> 'CXXFLAGS_FOR_BUILD=-O3 -pipe -march=corei7 -mtune=corei7'
> 'CFLAGS_FOR_TARGET=-O3 -pipe' 'CXXFLAGS_FOR_TARGET=-O3 -pipe'
> Thread model: posix
> gcc version 5.0.0 20150221 (experimental) (GCC)
>
>> We often use this U-Boot with SD cards and no one have such issue before.
>> What about your power supply?
> Haven't had a problem with it. Again, I could use HardKernel's old
> u-boot and it works just fine.
>
>> Do you have eMMC card?
> No
>
>> Any other accessory is connected?
> No, other than the USART.
>
>> Can you send me your binary (u-boot-dtb.bin)?
> It would be my pleasure and I'd be so grateful to find it if it would
> work on your ODroid-U2.

I'm using U3 and sometimes X2 - only those were tested. I don't have U2.

> I've attached 2 versions of it, one compiled from a clean/reset git
> and the other with "#define DEBUG"
>
> $ make ARCH=arm CROSS_COMPILE=/cross-tools/bin/${CLFS_TARGET}- mrproper
> $ make HOSTCC=gcc ARCH=arm
> CROSS_COMPILE=/cross-tools/bin/${CLFS_TARGET}- odroid_defconfig 2>&1 |
> tee configure.log
> $ make HOSTCC=gcc ARCH=arm
> CROSS_COMPILE=/cross-tools/bin/${CLFS_TARGET}- all 2>&1 | tee make.log
> $ sudo dd if=/dev/zero of=/dev/sd? seek=1 bs=512 count=3999
> $ sudo dd if=${CLFS}/boot/sd_fuse/bl1.HardKernel of=/dev/sd? seek=1
> iflag=dsync oflag=dsync
> $ sudo dd if=${CLFS}/boot/sd_fuse/bl2.HardKernel of=/dev/sd? seek=31
> iflag=dsync oflag=dsync
> $ sudo dd if=${CLFS}/boot/sd_fuse/u-boot-dtb.bin of=/dev/sd? seek=63
> iflag=dsync oflag=dsync
> $ sudo dd if=${CLFS}/boot/sd_fuse/tzsw.HardKernel of=/dev/sd?
> seek=2111 iflag=dsync oflag=dsync
>
> It really isn't important at this stage to have any partitions set
> since I'm not yet at the point where I can even boot yet because
> "Writing to MMC(0)... failed".
> However, "saveenv" would be the tell-tale-sign whether it succeeds or not.
>

Both binnaries, which you send me - works proper. I can list my 
partitions with them. But the problem is your board - it's U2.

You need to work with hardkernel's version. You should check, the 
clocks, and the GPIO registers for MMC.
Compare the registers from your working hardkernel's version with the 
mainline one.
Check the function board_clock_init(), the mmc clocks are set at the end 
of it, then you can check, which registers it writes.

There is a public documentation for the Exynos4412 rev. 1.0,
search on google with: "samsung exynos4 quad manual"

There may be some differences, but this would help you.

Good luck!
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com