* [U-Boot] "Writing to MMC(%d)... failed"
[not found] <BLU436-SMTP127C338DB532C3DF004593EA2E80@phx.gbl>
@ 2015-04-28 8:07 ` Przemyslaw Marczak
[not found] ` <BLU437-SMTP496E077CBDBF75F343C04FA2E80@phx.gbl>
0 siblings, 1 reply; 16+ messages in thread
From: Przemyslaw Marczak @ 2015-04-28 8:07 UTC (permalink / raw)
To: u-boot
Hello Nathan,
Sorry, I didn't reply last time, becouse I'm quite busy.
On 04/28/2015 07:39 AM, Nathan wrote:
> Still not sure where the problem lies. I thought I found an issue, but
> it didn't fix anything and caused a different issue.
>
> At first, after plugging in a bunch of printfs, I thought it was a
> simple issue in the dts (it appears not to be the issue):
> *****
> Getting a little back into it, I find an issue in:
> "./lib/libfdt/fdt_ro.c"
> "fdt_path_offset()" where "-FDT_ERR_BADPATH" is returned for "path"
> = "sdhci at 12530000"
> when:
> "./lib/fdtdec.c"
> "fdtdec_add_aliases_for_id()" is examining "mmc2"
>
> "fdt_path_offset()"
> "_fdt_nodename_eq()" finds "aliases"
>
> But the issue comes from
> "./lib/libfdt/fdt_ro.c"
> "_fdt_string_eq()"
> where
> "p" = "mmc2" <> "s" = "sdhci at 12530000"
>
> What I'm noticing different in the "exynos4412-odroid.dts" (odroid u2)
> and "exynos54xx.dtsi" is the "/" for the alias paths "mmc2" and
> "mmc4".
> *****
If I good remember, Exynos 54xx doesn't support sdhci, it has only dw mmc.
>
> The problem with that "finding" was:
> "fdtdec_add_aliases_for_id: warning: alias 'mmc2' points to a node
> 'sdhci at 12530000' that is missing or is not compatible with
> 'samsung,exynos-dwmmc'"
> Not sure why it would even mention dwmmc for mmc2 when it is specified
> "exynos-mmc" in "exynos4.dtsi"
>
> A common issue with or without the slash is:
> "_gpio_request_by_name_nodev: Node 'sdhci at 12530000', property
> 'pwr-gpios', failed to request GPIO index 0: -2"
>
The "pwr-gpio" is okay - the pin is not defined and not required here.
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]
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.
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"
>> I think the kicker is "No match for node 'sdhci at 12530000'".
>> I even manually set/forced the "status=okay" in the dts, but it still
>> says it's disabled.
>>
>> I shall continue to pursue this, working my way back from
>> "lists_bind_fdt()" in "lists.c"
>
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.
Which compiler are you using?
We often use this U-Boot with SD cards and no one have such issue before.
What about your power supply?
Do you have eMMC card?
Any other accessory is connected?
Can you send me your binary (u-boot-dtb.bin)?
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
[not found] ` <BLU437-SMTP496E077CBDBF75F343C04FA2E80@phx.gbl>
@ 2015-04-29 9:15 ` Przemyslaw Marczak
2015-04-29 23:34 ` Nathan
2015-04-30 2:44 ` Nathan
0 siblings, 2 replies; 16+ messages in thread
From: Przemyslaw Marczak @ 2015-04-29 9:15 UTC (permalink / raw)
To: u-boot
Hello Nathan,
On 04/28/2015 10:49 PM, Nathan wrote:
> On Tue, Apr 28, 2015 at 3:07 AM, Przemyslaw Marczak
> <p.marczak@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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-04-29 9:15 ` Przemyslaw Marczak
@ 2015-04-29 23:34 ` Nathan
2015-04-30 2:44 ` Nathan
1 sibling, 0 replies; 16+ messages in thread
From: Nathan @ 2015-04-29 23:34 UTC (permalink / raw)
To: u-boot
On Wed, Apr 29, 2015 at 4:15 AM, Przemyslaw Marczak
<p.marczak@samsung.com> wrote:
>
> 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.
"tested only on...", that I knew, but also knew the U2 and U3 both
used 4412 Prime and only had hopes that was all that would be
involved, but figured there was the possibility of differing GPIOs.
> 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 had seen that command, but never used it. Didn't even know about
that address holding the ID.
With my U2, I also got that same result:
*****
Odroid # md.l 0x10000000 0x1
10000000: e4412220 "A.
*****
But again, I am willing to bet it was wired up differently from the U3.
> 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.
I'm sure the HK BLs are fine since they work with their old
u-boot.bin, but I will see about stripping out bl2 from
u-boot-dts.bin, though I'm sure I'll have to check some other things.
> 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.
Yup, so I'll remain focused on the sdhci part of it all.
> 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
I'm getting the same values
*****
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
Also same here
*****
Odroid # md.l 0x110000a0 0x1
110000a0: 00000000 ....
Odroid # md.l 0x110000a8 0x1
110000a8: 00001555 U...
Odroid # md.l 0x110000ac 0x1
110000ac: 00000000 ....
*****
> I'm using U3 and sometimes X2 - only those were tested. I don't have U2.
> 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.
This is huge what you've done to lead me in the right direction and
very much appreciated.
It's good to know the binaries worked so I know the compiler is fine
and I really think I should just be checking out the GPIOs, as well as
the clocks that you mentioned. I remember doing that with the kernel's
dts last year.
I actually have that manual from 2013-02 as well as other
docs/schematics from HK, so at least now I know where to refer to.
You have given me a lot of good stuff to feast on, so I hope I won't
be posting back until I have solved this.
Thanks again.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-04-29 9:15 ` Przemyslaw Marczak
2015-04-29 23:34 ` Nathan
@ 2015-04-30 2:44 ` Nathan
1 sibling, 0 replies; 16+ messages in thread
From: Nathan @ 2015-04-30 2:44 UTC (permalink / raw)
To: u-boot
For good measure, I should have posted those command outputs using
HK's old u-boot as well for comparison:
*****
Exynos4412 # md.l 0x10000000 0x1
10000000: e4412220 "A.
*Same
Exynos4412 # md.l 0x11000080 0x1
11000080: 02222222 """.
*vs 02222022
Exynos4412 # md.l 0x11000088 0x1
11000088: 00003ff0 .?..
*vs 00000030
Exynos4412 # md.l 0x1100008c 0x1
1100008c: 00003fff .?..
*vs 00003fdf
Exynos4412 # md.l 0x110000a0 0x1
110000a0: 03333000 .03.
*vs 00000000
Exynos4412 # md.l 0x110000a8 0x1
110000a8: 00003ff0 .?..
*vs 00001555
Exynos4412 # md.l 0x110000ac 0x1
110000ac: 00003fff .?..
*vs 00000000
*****
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
@ 2015-04-28 5:39 Nathan
0 siblings, 0 replies; 16+ messages in thread
From: Nathan @ 2015-04-28 5:39 UTC (permalink / raw)
To: u-boot
Still not sure where the problem lies. I thought I found an issue, but
it didn't fix anything and caused a different issue.
At first, after plugging in a bunch of printfs, I thought it was a
simple issue in the dts (it appears not to be the issue):
*****
Getting a little back into it, I find an issue in:
"./lib/libfdt/fdt_ro.c"
"fdt_path_offset()" where "-FDT_ERR_BADPATH" is returned for "path"
= "sdhci at 12530000"
when:
"./lib/fdtdec.c"
"fdtdec_add_aliases_for_id()" is examining "mmc2"
"fdt_path_offset()"
"_fdt_nodename_eq()" finds "aliases"
But the issue comes from
"./lib/libfdt/fdt_ro.c"
"_fdt_string_eq()"
where
"p" = "mmc2" <> "s" = "sdhci at 12530000"
What I'm noticing different in the "exynos4412-odroid.dts" (odroid u2)
and "exynos54xx.dtsi" is the "/" for the alias paths "mmc2" and
"mmc4".
*****
The problem with that "finding" was:
"fdtdec_add_aliases_for_id: warning: alias 'mmc2' points to a node
'sdhci at 12530000' that is missing or is not compatible with
'samsung,exynos-dwmmc'"
Not sure why it would even mention dwmmc for mmc2 when it is specified
"exynos-mmc" in "exynos4.dtsi"
A common issue with or without the slash is:
"_gpio_request_by_name_nodev: Node 'sdhci at 12530000', property
'pwr-gpios', failed to request GPIO index 0: -2"
> I think the kicker is "No match for node 'sdhci at 12530000'".
> I even manually set/forced the "status=okay" in the dts, but it still
> says it's disabled.
>
> I shall continue to pursue this, working my way back from
> "lists_bind_fdt()" in "lists.c"
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-03-10 15:12 ` Przemyslaw Marczak
@ 2015-03-12 13:22 ` Nathan
0 siblings, 0 replies; 16+ messages in thread
From: Nathan @ 2015-03-12 13:22 UTC (permalink / raw)
To: u-boot
I had tried another card with the same result. I didn't think it would
be a problem since the hardkernel's release still works.
I expanded the output by defining "DEBUG" and am updating my thread
with my new findings:
...
Bound device i2c at 138d0000 to root_driver
- ignoring disabled device
- ignoring disabled device
bind node sdhci at 12530000
No match for node 'sdhci at 12530000'
- ignoring disabled device
bind node dwmmc at 12550000
No match for node 'dwmmc at 12550000'
bind node pinctrl at 11400000
- found match at 'gpio_exynos'
fdtdec_get_addr_size: reg: 11400000
...
i2c_get_chip: Searching bus 'i2c at 13860000' for address 09: found, ret=0
initcall: 43e068e4 (relocated to bde3d8e4)
MMC: fdtdec_add_aliases_for_id: warning: maxcount exceeded with alias 'mmc'
process_nodes: count = 1
fdtdec_get_int_array: interrupts
get_prop_check_min_len: interrupts
fdtdec_get_int: samsung,bus-width: 0x4 (4)
fdtdec_get_addr_size: reg: 12530000
_gpio_request_by_name_nodev: fdtdec_parse_phandle_with_args failed
_gpio_request_by_name_nodev: Node 'sdhci at 12530000', property
'pwr-gpios', failed to request GPIO index 0: -2
fdtdec_get_int: #gpio-cells: 0x2 (2)
...
gpio=118, bank=11000060
get_mmc_clk: invalid MMC index 4mmc init failed
SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
initcall: 43e06890 (relocated to bde3d890)
fdtdec_get_config_int: load-environment
...
I think the kicker is "No match for node 'sdhci at 12530000'".
I even manually set/forced the "status=okay" in the dts, but it still
says it's disabled.
I shall continue to pursue this, working my way back from
"lists_bind_fdt()" in "lists.c"
If you wish to NOT be included in the "reply to all", just let me
know. I won't take any offense.
I won't be inundating you with a lot of replies anyway as I slowly
work my way through this problem. Only updating after a notable
finding.
On Tue, Mar 10, 2015 at 10:12 AM, Przemyslaw Marczak
<p.marczak@samsung.com> wrote:
> We are often using the SD cards for a number of Odroid boards, in our
> office, with no issues.
>
> If you have other card, then I suggest to test it, the first one, could be
> tired :)
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-03-10 13:14 ` Nathan
@ 2015-03-10 15:12 ` Przemyslaw Marczak
2015-03-12 13:22 ` Nathan
0 siblings, 1 reply; 16+ messages in thread
From: Przemyslaw Marczak @ 2015-03-10 15:12 UTC (permalink / raw)
To: u-boot
Hi,
On 03/10/2015 02:14 PM, Nathan wrote:
> Sure, I understand from seeing all of the patches you submit. I
> thought I'd at least ask in case it was something easy.
> I'll continue to look into it. Thanks for submitting those links.
>
>
> I didn't try any other sdcard since the card does work fine with
> Hardkernel's old pre-built binaries.
We are often using the SD cards for a number of Odroid boards, in our
office, with no issues.
If you have other card, then I suggest to test it, the first one, could
be tired :)
>
> On Tue, Mar 10, 2015 at 8:07 AM, Przemyslaw Marczak
> <p.marczak@samsung.com> wrote:
>> Hello Nathan,
>> Now, I don't have too much time for this, but the only one you need is the
>> documentation and a time to analyze the responds for commands.
>>
>> Please check this site:
>> https://www.sdcard.org/downloads/pls/simplified_specs/index.html
>> you can also check some example spec from Jedec:
>> http://www.jedec.org/standards-documents/results/jesd84-a441
>>
>> You will solve this problem with this.
>>
>> By the way, did you tried another SD-Card?
>>
>> Best regards,
>> --
>> Przemyslaw Marczak
>> Samsung R&D Institute Poland
>> Samsung Electronics
>> p.marczak at samsung.com
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-03-10 13:07 ` Przemyslaw Marczak
@ 2015-03-10 13:14 ` Nathan
2015-03-10 15:12 ` Przemyslaw Marczak
0 siblings, 1 reply; 16+ messages in thread
From: Nathan @ 2015-03-10 13:14 UTC (permalink / raw)
To: u-boot
Sure, I understand from seeing all of the patches you submit. I
thought I'd at least ask in case it was something easy.
I'll continue to look into it. Thanks for submitting those links.
I didn't try any other sdcard since the card does work fine with
Hardkernel's old pre-built binaries.
On Tue, Mar 10, 2015 at 8:07 AM, Przemyslaw Marczak
<p.marczak@samsung.com> wrote:
> Hello Nathan,
> Now, I don't have too much time for this, but the only one you need is the
> documentation and a time to analyze the responds for commands.
>
> Please check this site:
> https://www.sdcard.org/downloads/pls/simplified_specs/index.html
> you can also check some example spec from Jedec:
> http://www.jedec.org/standards-documents/results/jesd84-a441
>
> You will solve this problem with this.
>
> By the way, did you tried another SD-Card?
>
> Best regards,
> --
> Przemyslaw Marczak
> Samsung R&D Institute Poland
> Samsung Electronics
> p.marczak at samsung.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
[not found] ` <BLU437-SMTP105D4C7DA6754615DB4E45DA2180@phx.gbl>
@ 2015-03-10 13:07 ` Przemyslaw Marczak
2015-03-10 13:14 ` Nathan
0 siblings, 1 reply; 16+ messages in thread
From: Przemyslaw Marczak @ 2015-03-10 13:07 UTC (permalink / raw)
To: u-boot
Hello Nathan,
On 03/10/2015 12:30 PM, Nathan wrote:
> I hope my last message didn't get lost during that outage last month.
>
> In the mean time, I had to finagle the HardKernel code to work with
> GCC 5.0 which ended up being only 1 line change which I may end up
> encountering in mainline if I ever get far enough.
> After transferring the "CONFIG_MMC_TRACE" to the HardKernel mmc.c, I
> have a comparable output for the U2 with the "Samsung" mainline.
>
> So the output comparison can be made more readable, I created a Google
> Drive Sheet, lining up the output when there were repeats,
> highlighting the differing output sections and changing the text color
> for the different values:
> https://docs.google.com/spreadsheets/d/1Gu10bG8wGJClorJjKoIMiAt4HR0nS22ugrL8-F5_Nbg/edit?usp=sharing
>
Now, I don't have too much time for this, but the only one you need is
the documentation and a time to analyze the responds for commands.
Please check this site:
https://www.sdcard.org/downloads/pls/simplified_specs/index.html
you can also check some example spec from Jedec:
http://www.jedec.org/standards-documents/results/jesd84-a441
You will solve this problem with this.
By the way, did you tried another SD-Card?
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-02-27 17:21 ` Nathan
@ 2015-03-10 11:30 ` Nathan
[not found] ` <BLU437-SMTP105D4C7DA6754615DB4E45DA2180@phx.gbl>
1 sibling, 0 replies; 16+ messages in thread
From: Nathan @ 2015-03-10 11:30 UTC (permalink / raw)
To: u-boot
I hope my last message didn't get lost during that outage last month.
In the mean time, I had to finagle the HardKernel code to work with
GCC 5.0 which ended up being only 1 line change which I may end up
encountering in mainline if I ever get far enough.
After transferring the "CONFIG_MMC_TRACE" to the HardKernel mmc.c, I
have a comparable output for the U2 with the "Samsung" mainline.
So the output comparison can be made more readable, I created a Google
Drive Sheet, lining up the output when there were repeats,
highlighting the differing output sections and changing the text color
for the different values:
https://docs.google.com/spreadsheets/d/1Gu10bG8wGJClorJjKoIMiAt4HR0nS22ugrL8-F5_Nbg/edit?usp=sharing
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-02-27 13:16 ` Przemyslaw Marczak
@ 2015-02-27 17:21 ` Nathan
2015-03-10 11:30 ` Nathan
[not found] ` <BLU437-SMTP105D4C7DA6754615DB4E45DA2180@phx.gbl>
0 siblings, 2 replies; 16+ messages in thread
From: Nathan @ 2015-02-27 17:21 UTC (permalink / raw)
To: u-boot
On Fri, Feb 27, 2015 at 7:16 AM, Przemyslaw Marczak
<p.marczak@samsung.com> wrote:
> This is too late for debug. The same result I can see when my card is not
> inserted.
Ugh, I meant to include the link to my post in the odroid forums which
included the entire (very long) output:
http://forum.odroid.com/viewtopic.php?f=13&t=2883#p76524
I'll inline compare my lines with yours, and prepend and append '*' to
those that differ:
> You should follow the card init sequence with the trace config, because it
> fails at init. This is the trace output from init sequence of my SD card:
>
> MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> CMD_SEND:0
CMD_SEND:0
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_NONE
MMC_RSP_NONE
> CMD_SEND:8
CMD_SEND:8
> ARG 0x000001AA
ARG 0x000001AA
> MMC_RSP_R1,5,6,7 0x000001AA
MMC_RSP_R1,5,6,7 0x000001AA
> CMD_SEND:55
CMD_SEND:55
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000120
MMC_RSP_R1,5,6,7 0x00000120
> CMD_SEND:41
CMD_SEND:41
> ARG 0x40300000
ARG 0x40300000
> MMC_RSP_R3,4 0x40FF8000
MMC_RSP_R3,4 0x40FF8000
> CMD_SEND:55
CMD_SEND:55
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000120
MMC_RSP_R1,5,6,7 0x00000120
> CMD_SEND:41
CMD_SEND:41
> ARG 0x40300000
ARG 0x40300000
> MMC_RSP_R3,4 0x40FF8000
* MMC_RSP_R3,4 0xC0FF8000*
At the moment, I don't know what that command corresponds with, but I
see the 55 and 41 are repeated 1 more time with yours before getting
that 41 output that I have. Perhaps it's a timing/retry attempt on
your system.
> CMD_SEND:55
> ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000120
*retry attempt? Not on mine.*
> CMD_SEND:41
> ARG 0x40300000
> MMC_RSP_R3,4 0xC0FF8000
*retry attempt? Not on mine.*
> CMD_SEND:2
CMD_SEND:2
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R2 0x03534453
MMC_RSP_R2 0x03534453
> 0x55303447
* 0x55303847 *
> 0x80273727
* 0x8005FCD3*
> 0x6900E700
* 0x3000A400*
>
> DUMPING DATA
DUMPING DATA
> 000 - 03 53 44 53
000 - 03 53 44 53
> 004 - 55 30 34 47
* 004 - 55 30 38 47*
> 008 - 80 27 37 27
* 008 - 80 05 FC D3*
> 012 - 69 00 E7 00
* 012 - 30 00 A4 00*
> CMD_SEND:3
CMD_SEND:3
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1,5,6,7 0xAAAA0520
* MMC_RSP_R1,5,6,7 0xE6240520*
> CMD_SEND:9
CMD_SEND:9
> ARG 0xAAAA0000
* ARG 0xE6240000*
> MMC_RSP_R2 0x400E0032
MMC_RSP_R2 0x400E0032
> 0x5B590000
0x5B590000
> 0x1D8A7F80
* 0x3B377F80*
> 0x0A404000
0x0A404000
>
> DUMPING DATA
DUMPING DATA
> 000 - 40 0E 00 32
000 - 40 0E 00 32
> 004 - 5B 59 00 00
004 - 5B 59 00 00
> 008 - 1D 8A 7F 80
* 008 - 3B 37 7F 80*
> 012 - 0A 40 40 00
012 - 0A 40 40 00
> CMD_SEND:13
CMD_SEND:13
> ARG 0xAAAA0000
* ARG 0xE6240000*
> MMC_RSP_R1,5,6,7 0x00000700
MMC_RSP_R1,5,6,7 0x00000700
> CURR STATE:3
CURR STATE:3
> CMD_SEND:7
CMD_SEND:7
> ARG 0xAAAA0000
* ARG 0xE6240000*
> MMC_RSP_R1,5,6,7 0x00000700
MMC_RSP_R1,5,6,7 0x00000700
> CMD_SEND:55
CMD_SEND:55
> ARG 0xAAAA0000
* ARG 0xE6240000*
> MMC_RSP_R1,5,6,7 0x00000920
MMC_RSP_R1,5,6,7 0x00000920
> CMD_SEND:51
CMD_SEND:51
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000920
MMC_RSP_R1,5,6,7 0x00000920
> CMD_SEND:6
CMD_SEND:6
> ARG 0x00FFFFF1
ARG 0x00FFFFF1
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:6
CMD_SEND:6
> ARG 0x80FFFFF1
ARG 0x80FFFFF1
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:55
CMD_SEND:55
> ARG 0xAAAA0000
* ARG 0xE6240000*
> MMC_RSP_R1,5,6,7 0x00000920
MMC_RSP_R1,5,6,7 0x00000920
> CMD_SEND:6
CMD_SEND:6
> ARG 0x00000002
ARG 0x00000002
> MMC_RSP_R1,5,6,7 0x00000920
MMC_RSP_R1,5,6,7 0x00000920
> CMD_SEND:16
CMD_SEND:16
> ARG 0x00000200
ARG 0x00000200
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:17
CMD_SEND:17
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:16
CMD_SEND:16
> ARG 0x00000200
ARG 0x00000200
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:17
CMD_SEND:17
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:16
CMD_SEND:16
> ARG 0x00000200
ARG 0x00000200
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:18
CMD_SEND:18
> ARG 0x00000A00
ARG 0x00000A00
> MMC_RSP_R1,5,6,7 0x00000900
MMC_RSP_R1,5,6,7 0x00000900
> CMD_SEND:12
CMD_SEND:12
> ARG 0x00000000
ARG 0x00000000
> MMC_RSP_R1b 0x00000900
MMC_RSP_R1b 0x00000900
>
> I hope this will help you to solve this issue.
I searched my output for any "ret" value < 0 and it was only for "CMD_SEND:16"
I should also add that I'm using odroid U2.
My output also doesn't stop@command 12. In fact I get an error
right after it: "*** Warning - bad CRC, using default environment".
But then that should be expected since I wipe blocks from 2560 to the
start of my first partition.
After that I get a bunch of 12, 16, 17, 18 commands (mostly 16, 17).
Thanks for taking the time to look into this issue.
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-02-26 23:59 ` Nathan
@ 2015-02-27 13:16 ` Przemyslaw Marczak
2015-02-27 17:21 ` Nathan
0 siblings, 1 reply; 16+ messages in thread
From: Przemyslaw Marczak @ 2015-02-27 13:16 UTC (permalink / raw)
To: u-boot
Hi,
On 02/27/2015 12:59 AM, Nathan wrote:
> I think I've been able to narrow down, a bit, where the issue is coming from.
>
> "mmc_set_blocklen" led me to "mmc_send_cmd" which showed that there is
> the "CONFIG_MMC_TRACE" I could use.
>
> A notable difference between hardkernel's u-boot and mainline was the
> "uint flags;" was no longer in the "mmc_cmd" struct.
>
> I did see that this removal was noted as being a problem back in 2012:
> http://lists.denx.de/pipermail/u-boot/2012-September/133409.html
>
> The result from "saveenv":
>
This is too late for debug. The same result I can see when my card is
not inserted.
> Odroid # saveenv
>
>
> Saving Environment to MMC...
>
>
> Writing to MMC(0)... CMD_SEND:16
>
>
> ARG 0x00000200
>
>
> ret: -19
>
>
> MMC_RSP_R1,5,6,7 0x00000000
>
> I added the "printf" for "ret".
>
You should follow the card init sequence with the trace config, because
it fails at init. This is the trace output from init sequence of my SD card:
MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
CMD_SEND:0
ARG 0x00000000
MMC_RSP_NONE
CMD_SEND:8
ARG 0x000001AA
MMC_RSP_R1,5,6,7 0x000001AA
CMD_SEND:55
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000120
CMD_SEND:41
ARG 0x40300000
MMC_RSP_R3,4 0x40FF8000
CMD_SEND:55
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000120
CMD_SEND:41
ARG 0x40300000
MMC_RSP_R3,4 0x40FF8000
CMD_SEND:55
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000120
CMD_SEND:41
ARG 0x40300000
MMC_RSP_R3,4 0xC0FF8000
CMD_SEND:2
ARG 0x00000000
MMC_RSP_R2 0x03534453
0x55303447
0x80273727
0x6900E700
DUMPING DATA
000 - 03 53 44 53
004 - 55 30 34 47
008 - 80 27 37 27
012 - 69 00 E7 00
CMD_SEND:3
ARG 0x00000000
MMC_RSP_R1,5,6,7 0xAAAA0520
CMD_SEND:9
ARG 0xAAAA0000
MMC_RSP_R2 0x400E0032
0x5B590000
0x1D8A7F80
0x0A404000
DUMPING DATA
000 - 40 0E 00 32
004 - 5B 59 00 00
008 - 1D 8A 7F 80
012 - 0A 40 40 00
CMD_SEND:13
ARG 0xAAAA0000
MMC_RSP_R1,5,6,7 0x00000700
CURR STATE:3
CMD_SEND:7
ARG 0xAAAA0000
MMC_RSP_R1,5,6,7 0x00000700
CMD_SEND:55
ARG 0xAAAA0000
MMC_RSP_R1,5,6,7 0x00000920
CMD_SEND:51
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000920
CMD_SEND:6
ARG 0x00FFFFF1
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:6
ARG 0x80FFFFF1
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:55
ARG 0xAAAA0000
MMC_RSP_R1,5,6,7 0x00000920
CMD_SEND:6
ARG 0x00000002
MMC_RSP_R1,5,6,7 0x00000920
CMD_SEND:16
ARG 0x00000200
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:17
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:16
ARG 0x00000200
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:17
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:16
ARG 0x00000200
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:18
ARG 0x00000A00
MMC_RSP_R1,5,6,7 0x00000900
CMD_SEND:12
ARG 0x00000000
MMC_RSP_R1b 0x00000900
I hope this will help you to solve this issue.
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-02-26 0:30 ` Nathan
2015-02-26 23:59 ` Nathan
@ 2015-02-27 13:08 ` Przemyslaw Marczak
1 sibling, 0 replies; 16+ messages in thread
From: Przemyslaw Marczak @ 2015-02-27 13:08 UTC (permalink / raw)
To: u-boot
Hello Nathan,
On 02/26/2015 01:30 AM, Nathan wrote:
> Wow, that came out as a real mess.
> I used Outlook.com to compose that message.
> Anyone experience that and can recommend how I can clean it up?
> I see that I composed using "Rich Text".
>
> I'll try to redo it in my reply here using "Plain Text":
Plain text is the right text formating.
>
> "saveenv" won't write the environment out to disk.
>
> $ sudo dd if=/dev/zero of=/dev/sde seek=1 bs=512 count=3999
> //wiping out area just to make sure no garbage is picked up.
> $ sudo dd if=bl1.HardKernel of=/dev/sde seek=1 iflag=dsync oflag=dsync
> $ sudo dd if=bl2.HardKernel of=/dev/sde seek=31 iflag=dsync oflag=dsync
> $ sudo dd if=u-boot-dtb.bin of=/dev/sde seek=63 iflag=dsync oflag=dsync
> $ sudo dd if=tzsw.HardKernel of=/dev/sde seek=2111 iflag=dsync oflag=dsync
>
> Fail:
> git://git.denx.de/u-boot.git
> commit 47d8ae4069b47ce966c0c5e0d8dd041e69ee1f86
> *****
> U-Boot 2015.04-rc2-00081-g47d8ae4 (Feb 25 2015 - 12:12:40)
>
> CPU: Exynos4412 at 1000MHz
> Model: Odroid based on Exynos4412
> DRAM: 2 GiB
> Board PMIC init
> MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
> *** Warning - bad CRC, using default environment
>
> DFU alt info setting: done
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> ** Unrecognized filesystem type **
> ** Unrecognized filesystem type **
> ** Unrecognized filesystem type **
> Bad Linux ARM zImage magic!
> Odroid # saveenv
> Saving Environment to MMC...
> Writing to MMC(0)... failed
> Odroid # mmc info
> Device: SAMSUNG SDHCI
> Manufacturer ID: 3
> OEM: 5344
> Name: SU08G
> Tran Speed: 50000000
> Rd Block Len: 512
> SD version 3.0
> High Capacity: Yes
> Capacity: 7.4 GiB
> Bus Width: 4-bit
> Erase Group Size: 512 Bytes
> Odroid # mmc list
> SAMSUNG SDHCI: 0 (SD)
> EXYNOS DWMMC: 1
> Odroid # mmc part
>
> Partition Map for MMC device 0 -- Partition Type: DOS
>
> Part Start Sector Num Sectors UUID Type
> ** Can't read partition table on 0:0 **
SD cards doesn't have hwpartitions.
> Odroid # mmc hwpartition check
> Partition configuration:
> No enhanced user data area
> No GP1 partition
> No GP2 partition
> No GP3 partition
> No GP4 partition
> eMMC >= 4.4 required for enhanced user data area
> Failed!
> Odroid # version
>
> U-Boot 2015.04-rc2-00081-g47d8ae4 (Feb 25 2015 - 12:12:40)
> armv7l-unknown-linux-gnueabihf-gcc (GCC) 5.0.0 20150221 (experimental)
> GNU ld (GNU Binutils) 2.25.51.20150221
Partition numbering starts from 1, so should use mmc 0:1
> Odroid # fstype mmc 0:0
> ** ext4fs_devread read error - block
> Failed to mount ext2 filesystem...
> ** Unrecognized filesystem type **
> Odroid # bdinfo
> arch_number = 0x000010C1
> boot_params = 0x40000100
> DRAM bank = 0x00000000
> -> start = 0x40000000
> -> size = 0x10000000
> DRAM bank = 0x00000001
> -> start = 0x50000000
> -> size = 0x10000000
> DRAM bank = 0x00000002
> -> start = 0x60000000
> -> size = 0x10000000
> DRAM bank = 0x00000003
> -> start = 0x70000000
> -> size = 0x10000000
> DRAM bank = 0x00000004
> -> start = 0x80000000
> -> size = 0x10000000
> DRAM bank = 0x00000005
> -> start = 0x90000000
> -> size = 0x10000000
> DRAM bank = 0x00000006
> -> start = 0xA0000000
> -> size = 0x10000000
> DRAM bank = 0x00000007
> -> start = 0xB0000000
> -> size = 0x0FF00000
> current eth = unknown
> ip_addr = <NULL>
> baudrate = 115200 bps
> TLB addr = 0xBFEF0000
> relocaddr = 0xBDE43000
> reloc off = 0x7A043000
> irq_sp = 0xB8E3D860
> sp start = 0xB8E3D850
> *****
> Ignore the "unrecognized filesystem type" stuff. I'm using ext4.
> mmc hwpartition only used for eMMC?
Yes, only eMMC.
>
> Success:
> https://github.com/hardkernel/u-boot.git
> commit 33e05ffb159141b640571e91470172d83a2a1273
> *****
> U-Boot 2010.12-svn (May 12 2014 - 15:05:46) for Exynox4412
>
>
> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
> APLL = 1000MHz, MPLL = 880MHz
> DRAM: 2 GiB
>
> PMIC VERSION : 0x00, CHIP REV : 3
> TrustZone Enabled BSP
> BL1 version: 20121128
>
> Checking Boot Mode ... SDMMC
> MMC Device 0: 7580 MB
> MMC Device 1 not found
> *** Warning - using default environment
> USB3503 NINT = OUTPUT LOW!
> ModeKey Check... run normal_boot
> No ethernet found.
> Hit any key to stop autoboot: 0
> Exynos4412 # wipeenv 0
> spot on!
> 0: wipeenv
> 1:0
> MMC Device 1 not found
> Wiping u-boot env at MMC: 0
> Exynos4412 # mmcinfo
> Device: S3C_HSMMC2
> Manufacturer ID: 3
> OEM: 5344
> Name: SU08G
> Tran Speed: 0
> Rd Block Len: 512
> SD version 2.0
> High Capacity: Yes
> Size: 0MB (block: 7580)
> Bus Width: 4-bit
> Boot Partition Size: 0 KB
> Exynos4412 # saveenv
> Saving Environment to SMDK bootable device...
> done
> *****
>
I tested the latest mainline HEAD on U3, rev.0.2, on some two cheap
Sandisk 4GB SD cards. It works fine for both
Maybe your card is little tired and need some more timeout for some
operations, this could be the reason of that issue.
Can you test a different card?
Best regards,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-02-26 0:30 ` Nathan
@ 2015-02-26 23:59 ` Nathan
2015-02-27 13:16 ` Przemyslaw Marczak
2015-02-27 13:08 ` Przemyslaw Marczak
1 sibling, 1 reply; 16+ messages in thread
From: Nathan @ 2015-02-26 23:59 UTC (permalink / raw)
To: u-boot
I think I've been able to narrow down, a bit, where the issue is coming from.
"mmc_set_blocklen" led me to "mmc_send_cmd" which showed that there is
the "CONFIG_MMC_TRACE" I could use.
A notable difference between hardkernel's u-boot and mainline was the
"uint flags;" was no longer in the "mmc_cmd" struct.
I did see that this removal was noted as being a problem back in 2012:
http://lists.denx.de/pipermail/u-boot/2012-September/133409.html
The result from "saveenv":
Odroid # saveenv
Saving Environment to MMC...
Writing to MMC(0)... CMD_SEND:16
ARG 0x00000200
ret: -19
MMC_RSP_R1,5,6,7 0x00000000
I added the "printf" for "ret".
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
2015-02-25 19:14 Nathan Royce
@ 2015-02-26 0:30 ` Nathan
2015-02-26 23:59 ` Nathan
2015-02-27 13:08 ` Przemyslaw Marczak
0 siblings, 2 replies; 16+ messages in thread
From: Nathan @ 2015-02-26 0:30 UTC (permalink / raw)
To: u-boot
Wow, that came out as a real mess.
I used Outlook.com to compose that message.
Anyone experience that and can recommend how I can clean it up?
I see that I composed using "Rich Text".
I'll try to redo it in my reply here using "Plain Text":
"saveenv" won't write the environment out to disk.
$ sudo dd if=/dev/zero of=/dev/sde seek=1 bs=512 count=3999
//wiping out area just to make sure no garbage is picked up.
$ sudo dd if=bl1.HardKernel of=/dev/sde seek=1 iflag=dsync oflag=dsync
$ sudo dd if=bl2.HardKernel of=/dev/sde seek=31 iflag=dsync oflag=dsync
$ sudo dd if=u-boot-dtb.bin of=/dev/sde seek=63 iflag=dsync oflag=dsync
$ sudo dd if=tzsw.HardKernel of=/dev/sde seek=2111 iflag=dsync oflag=dsync
Fail:
git://git.denx.de/u-boot.git
commit 47d8ae4069b47ce966c0c5e0d8dd041e69ee1f86
*****
U-Boot 2015.04-rc2-00081-g47d8ae4 (Feb 25 2015 - 12:12:40)
CPU: Exynos4412 at 1000MHz
Model: Odroid based on Exynos4412
DRAM: 2 GiB
Board PMIC init
MMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment
DFU alt info setting: done
Net: No ethernet found.
Hit any key to stop autoboot: 0
** Unrecognized filesystem type **
** Unrecognized filesystem type **
** Unrecognized filesystem type **
Bad Linux ARM zImage magic!
Odroid # saveenv
Saving Environment to MMC...
Writing to MMC(0)... failed
Odroid # mmc info
Device: SAMSUNG SDHCI
Manufacturer ID: 3
OEM: 5344
Name: SU08G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
Odroid # mmc list
SAMSUNG SDHCI: 0 (SD)
EXYNOS DWMMC: 1
Odroid # mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
** Can't read partition table on 0:0 **
Odroid # mmc hwpartition check
Partition configuration:
No enhanced user data area
No GP1 partition
No GP2 partition
No GP3 partition
No GP4 partition
eMMC >= 4.4 required for enhanced user data area
Failed!
Odroid # version
U-Boot 2015.04-rc2-00081-g47d8ae4 (Feb 25 2015 - 12:12:40)
armv7l-unknown-linux-gnueabihf-gcc (GCC) 5.0.0 20150221 (experimental)
GNU ld (GNU Binutils) 2.25.51.20150221
Odroid # fstype mmc 0:0
** ext4fs_devread read error - block
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Odroid # bdinfo
arch_number = 0x000010C1
boot_params = 0x40000100
DRAM bank = 0x00000000
-> start = 0x40000000
-> size = 0x10000000
DRAM bank = 0x00000001
-> start = 0x50000000
-> size = 0x10000000
DRAM bank = 0x00000002
-> start = 0x60000000
-> size = 0x10000000
DRAM bank = 0x00000003
-> start = 0x70000000
-> size = 0x10000000
DRAM bank = 0x00000004
-> start = 0x80000000
-> size = 0x10000000
DRAM bank = 0x00000005
-> start = 0x90000000
-> size = 0x10000000
DRAM bank = 0x00000006
-> start = 0xA0000000
-> size = 0x10000000
DRAM bank = 0x00000007
-> start = 0xB0000000
-> size = 0x0FF00000
current eth = unknown
ip_addr = <NULL>
baudrate = 115200 bps
TLB addr = 0xBFEF0000
relocaddr = 0xBDE43000
reloc off = 0x7A043000
irq_sp = 0xB8E3D860
sp start = 0xB8E3D850
*****
Ignore the "unrecognized filesystem type" stuff. I'm using ext4.
mmc hwpartition only used for eMMC?
Success:
https://github.com/hardkernel/u-boot.git
commit 33e05ffb159141b640571e91470172d83a2a1273
*****
U-Boot 2010.12-svn (May 12 2014 - 15:05:46) for Exynox4412
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
APLL = 1000MHz, MPLL = 880MHz
DRAM: 2 GiB
PMIC VERSION : 0x00, CHIP REV : 3
TrustZone Enabled BSP
BL1 version: 20121128
Checking Boot Mode ... SDMMC
MMC Device 0: 7580 MB
MMC Device 1 not found
*** Warning - using default environment
USB3503 NINT = OUTPUT LOW!
ModeKey Check... run normal_boot
No ethernet found.
Hit any key to stop autoboot: 0
Exynos4412 # wipeenv 0
spot on!
0: wipeenv
1:0
MMC Device 1 not found
Wiping u-boot env at MMC: 0
Exynos4412 # mmcinfo
Device: S3C_HSMMC2
Manufacturer ID: 3
OEM: 5344
Name: SU08G
Tran Speed: 0
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Size: 0MB (block: 7580)
Bus Width: 4-bit
Boot Partition Size: 0 KB
Exynos4412 # saveenv
Saving Environment to SMDK bootable device...
done
*****
^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] "Writing to MMC(%d)... failed"
@ 2015-02-25 19:14 Nathan Royce
2015-02-26 0:30 ` Nathan
0 siblings, 1 reply; 16+ messages in thread
From: Nathan Royce @ 2015-02-25 19:14 UTC (permalink / raw)
To: u-boot
"saveenv" won't write the environment out to disk.
$ sudo dd if=/dev/zero of=/dev/sde seek=1 bs=512 count=3999 //wiping out area just to make sure no garbage is picked up.$ sudo dd if=bl1.HardKernel of=/dev/sde seek=1 iflag=dsync oflag=dsync$ sudo dd if=bl2.HardKernel of=/dev/sde seek=31 iflag=dsync oflag=dsync$ sudo dd if=u-boot-dtb.bin of=/dev/sde seek=63 iflag=dsync oflag=dsync$ sudo dd if=tzsw.HardKernel of=/dev/sde seek=2111 iflag=dsync oflag=dsync
Fail:
git://git.denx.de/u-boot.gitcommit 47d8ae4069b47ce966c0c5e0d8dd041e69ee1f86*****U-Boot 2015.04-rc2-00081-g47d8ae4 (Feb 25 2015 - 12:12:40)
CPU: Exynos4412 at 1000MHzModel: Odroid based on Exynos4412DRAM: 2 GiBBoard PMIC initMMC: SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1*** Warning - bad CRC, using default environment
DFU alt info setting: doneNet: No ethernet found.Hit any key to stop autoboot: 0** Unrecognized filesystem type **** Unrecognized filesystem type **** Unrecognized filesystem type **Bad Linux ARM zImage magic!Odroid # saveenvSaving Environment to MMC...Writing to MMC(0)... failedOdroid # mmc infoDevice: SAMSUNG SDHCIManufacturer ID: 3OEM: 5344Name: SU08GTran Speed: 50000000Rd Block Len: 512SD version 3.0High Capacity: YesCapacity: 7.4 GiBBus Width: 4-bitErase Group Size: 512 BytesOdroid # mmc listSAMSUNG SDHCI: 0 (SD)EXYNOS DWMMC: 1Odroid # mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type** Can't read partition table on 0:0 **Odroid # mmc hwpartition checkPartition configuration: No enhanced user data area No GP1 partition No GP2 partition No GP3 partition No GP4 partitioneMMC >= 4.4 required for enhanced user data areaFailed!Odroid # version
U-Boot 2015.04-rc2-00081-g47d8ae4 (Feb 25 2015 - 12:12:40)armv7l-unknown-linux-gnueabihf-gcc (GCC) 5.0.0 20150221 (experimental)GNU ld (GNU Binutils) 2.25.51.20150221Odroid # fstype mmc 0:0 ** ext4fs_devread read error - blockFailed to mount ext2 filesystem...** Unrecognized filesystem type **Odroid # bdinfoarch_number = 0x000010C1boot_params = 0x40000100DRAM bank = 0x00000000-> start = 0x40000000-> size = 0x10000000DRAM bank = 0x00000001-> start = 0x50000000-> size = 0x10000000DRAM bank = 0x00000002-> start = 0x60000000-> size = 0x10000000DRAM bank = 0x00000003-> start = 0x70000000-> size = 0x10000000DRAM bank = 0x00000004-> start = 0x80000000-> size = 0x10000000DRAM bank = 0x00000005-> start = 0x90000000-> size = 0x10000000DRAM bank = 0x00000006-> start = 0xA0000000-> size = 0x10000000DRAM bank = 0x00000007-> start = 0xB0000000-> size = 0x0FF00000current eth = unknownip_addr = <NULL>baudrate = 115200 bpsTLB addr = 0xBFEF0000relocaddr = 0xBDE43000reloc off = 0x7A043000irq_sp = 0xB8E3D860sp start = 0xB8E3D850*****Ignore the "unrecognized filesystem type" stuff. I'm using ext4.mmc hwpartition only used for eMMC?
Success:https://github.com/hardkernel/u-boot.gitcommit 33e05ffb159141b640571e91470172d83a2a1273*****U-Boot 2010.12-svn (May 12 2014 - 15:05:46) for Exynox4412
CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]APLL = 1000MHz, MPLL = 880MHzDRAM: 2 GiB
PMIC VERSION : 0x00, CHIP REV : 3TrustZone Enabled BSPBL1 version: 20121128
Checking Boot Mode ... SDMMCMMC Device 0: 7580 MBMMC Device 1 not found*** Warning - using default environmentUSB3503 NINT = OUTPUT LOW!ModeKey Check... run normal_bootNo ethernet found.Hit any key to stop autoboot: 0Exynos4412 # wipeenv 0spot on!0: wipeenv1:0MMC Device 1 not foundWiping u-boot env at MMC: 0Exynos4412 # mmcinfoDevice: S3C_HSMMC2Manufacturer ID: 3OEM: 5344Name: SU08G Tran Speed: 0Rd Block Len: 512SD version 2.0High Capacity: YesSize: 0MB (block: 7580)Bus Width: 4-bitBoot Partition Size: 0 KBExynos4412 # saveenvSaving Environment to SMDK bootable device...done*****
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-04-30 2:44 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <BLU436-SMTP127C338DB532C3DF004593EA2E80@phx.gbl>
2015-04-28 8:07 ` [U-Boot] "Writing to MMC(%d)... failed" Przemyslaw Marczak
[not found] ` <BLU437-SMTP496E077CBDBF75F343C04FA2E80@phx.gbl>
2015-04-29 9:15 ` Przemyslaw Marczak
2015-04-29 23:34 ` Nathan
2015-04-30 2:44 ` Nathan
2015-04-28 5:39 Nathan
-- strict thread matches above, loose matches on Subject: below --
2015-02-25 19:14 Nathan Royce
2015-02-26 0:30 ` Nathan
2015-02-26 23:59 ` Nathan
2015-02-27 13:16 ` Przemyslaw Marczak
2015-02-27 17:21 ` Nathan
2015-03-10 11:30 ` Nathan
[not found] ` <BLU437-SMTP105D4C7DA6754615DB4E45DA2180@phx.gbl>
2015-03-10 13:07 ` Przemyslaw Marczak
2015-03-10 13:14 ` Nathan
2015-03-10 15:12 ` Przemyslaw Marczak
2015-03-12 13:22 ` Nathan
2015-02-27 13:08 ` Przemyslaw Marczak
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.