Hi Notaz,
Am 26.02.2017 um 22:24 schrieb Grazvydas Ignotas notasas@gmail.com:
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.
Ok!
I already had observed that there is some "memory effect" which has something to do with how fast and in which sequence power is (re)applied and so far I thought that the Palmas backup (supercap) has something to do with it.
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).
Ah, interesting! I always thought that MLO does not use DRAM at all because it runs from and within SRAM. But since it is now built as SPL from the U-Boot sources, the linker commands may do differently.
The problem might have become visible only after this version detection was moved to SPL as well. Before, we only had it in U-Boot where DRAM is already initialized by SPL/MLO.
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.
Thanks! Have applied them and see no negative effects... Well, I haven't seen the positive one either, but let's observe.
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.
Yes, there must be something wrong with warm reset. If I "reboot" from Linux everything works well, up to Kernel starting... where nothing happens any more.
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.
I have always seen the warning but it still did boot for me.
So I have applied all 4 patches and reverted the 2µs delay for reading gpios and it works equally good for me. Hopefully better for everyone else.
Are you now able to boot to Linux with these patches?
BR and thanks, Nikolaus