* [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
* [U-Boot] "Writing to MMC(%d)... failed" 2015-02-25 19:14 [U-Boot] "Writing to MMC(%d)... failed" 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-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-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-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-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
[parent not found: <BLU437-SMTP105D4C7DA6754615DB4E45DA2180@phx.gbl>]
* [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-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" 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 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-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-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[parent not found: <BLU436-SMTP127C338DB532C3DF004593EA2E80@phx.gbl>]
* [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
[parent not found: <BLU437-SMTP496E077CBDBF75F343C04FA2E80@phx.gbl>]
* [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
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 --
2015-02-25 19:14 [U-Boot] "Writing to MMC(%d)... failed" 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
2015-04-28 5:39 Nathan
[not found] <BLU436-SMTP127C338DB532C3DF004593EA2E80@phx.gbl>
2015-04-28 8:07 ` 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
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.