On Sun, Feb 26, 2017 at 9:10 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Am 25.02.2017 um 23:52 schrieb Grazvydas Ignotas notasas@gmail.com:
This development made me unpack my board again hoping it would boot with all the fixes, unfortunately it doesn't, must be dead beyond hope. Even the board version detection is unstable on it:
U-Boot SPL 2016.11-01304-g918c4c4 (Feb 26 2017 - 00:12:35) OMAP5432-GP ES2.0 Trying to boot from MMC1 Found LC15 V5.5 board_mmc_init called (vers = 0) ERROR : check_gpio: invalid GPIO -1
Hm. I have seen this also once or twice on my boards. Version detect reports V5.5.
I can reproduce it reliably by doing this: - disconnect all power (battery, USB debug port), remove all boot media - wait for half a minute or so - connect battery, USB debug cable (no boot media at this point) - press and release power - insert boot SD
at this point it starts MLO and always reports V5.5. I've investigated it and it seems it's because DRAM init fails. There is a static variable "vers" and according to the map file it goes to DRAM, and reading that you'll always get 0 (but occasionally trash). gcc will cache the result of second pair of gpio_get_value() to a register so you get a partially valid result. I've attached patches 0001 and 0002 to deal with this situation.
I've tried to find out why DRAM init fails and found something with the help of patch 0003, where it prints: "SDRAM: identified size not same as expected size identified: 4 expected: 40000000" so something goes wrong during setup. There is a warm_reset() function that's used quite a bit by RAM init code (emif-common.c) and it returns 0x20 (EXTERNAL_WARM_RST) in above described scenario, so emif-common thinks it's a warm reset and probably skips some init (the code is confusing so I'm not sure). Might be worth printing warm_reset() result in lc15.c, might help to figure out the boot mysteries.
I'm not sure why I need patch 0004 (and apparently you don't), u-boot never loaded for me without it. Perhaps the "boot mode" that comes from ROM code is different on my broken board (u-boot SPL seems to use it to decide how to load main u-boot). You can read it from gd->arch.omap_boot_device , apparently arch/arm/include/asm/arch-omap5/spl.h has the meanings of that variable.
Gražvydas