Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4
Hi!
I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim that this configuration is unsupported, but it enables fairly quick development and was very useful for me in past.
Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before I start bisecting it, I wanted to ask if someone has idea what might be responsible?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Pavel,
Quoted 3 lines · Pavel Machek
I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim that this configuration is unsupported, but it enables fairly quick development and was very useful for me in past.
Yes, I use this chainloading also quite frequently on some platforms. It should generally work on platforms with SPL support. Where the preloader / SPL / BootROM has initialized the base HW and the SDRAM. So that the U-Boot proper can get loaded into SDRAM. So it should also work on SoCFPGA. I have to admit, that I haven't tested it lately on SoCFPGA though.
Quoted 3 lines
Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before I start bisecting it, I wanted to ask if someone has idea what might be responsible?
As mentioned above, I've not tested on this platform lately, sorry. But I assume that you also test the latest release version, yes? And current master as well. Also failing there?
Thanks,
Stefan
Hi!
Quoted 7 lines
I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim that this configuration is unsupported, but it enables fairly quick development and was very useful for me in past.
Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before I start bisecting it, I wanted to ask if someone has idea what might be responsible?
When I merge 1c84cc6e3badb31e55bdf05ff2d3f8f058a5da47, I get:
U-Boot 2016.01-rc2-01393-gc28dfb5 (Jan 20 2016 - 10:42:36 +0100)
CPU: Altera SoCFPGA Platform FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0 BOOT: SD/MMC External Transceiver (1.8V)
Watchdog enabled
I2C: ready
DRAM: 1 GiB
Error binding driver 'socfpga_dwmmc'
Some drivers failed to bind
Error binding driver 'generic_simple_bus'
Some drivers failed to bind
initcall sequence 3ffb10a4 failed at call 01003257 (err=-96) ### ERROR ### Please RESET the board ###
(But that's not failure I was looking for).
Commit 0c890879fe2a5731df7aee3dd38e455008fa9977 worked ok.
Commit 8e535af2e441030f5e4b940a3756a0d92646b5fe breaks compilation (previous one worked ok in my config).
LD lib/built-in.o
LD u-boot
board/altera/cyclone5-socdk/built-in.o: In function `g_dnl_board_usb_cable_connected':
/home/pavel/amp/u-boot/board/altera/cyclone5-socdk/socfpga.c:25:
multiple definition of `board_init' arch/arm/mach-socfpga/built-in.o::(.text.board_init+0x0): first defined here
board/altera/cyclone5-socdk/built-in.o: In function `s_init':
/home/pavel/amp/u-boot/board/altera/cyclone5-socdk/socfpga.c:17:
multiple definition of `s_init'
...
Disabling "CONFIG_USB" fixes compilation for me, and can get back to u-boot that starts but then pritns "initcall sequence 3ffb1300 failed at call 01003263 (err=-96)".
Commit 07806977878130dd27dfc926ef7002041f6cf288 seems to break compilation again (previous one worked), with:
drivers/usb/host/dwc2.c: In function 'usb_lowlevel_init':drivers/usb/host/dwc2.c:1027:40: error: 'CONFIG_USB_DWC2_REG_ADDR' undeclared (first use in this function)
priv->regs = (struct dwc2_core_regs *)CONFIG_USB_DWC2_REG_ADDR;
^ drivers/usb/host/dwc2.c:1027:40: note: each undeclared identifier is reported only once for each function it appears in
I'm able to get it back to compile when I rip out complete USB support.
I have merged 68909e823eb4074a7e559e0c03d16533813c86cf, and now it fails to boot at all.
While bisecting, this commit jumped to my attention:
commit 574967c241301b924748ce205f29f494e32967fe
Author: Marek Vasut <[email protected]> Date: Tue Dec 22 04:16:01 2015 +0100
arm: socfpga: Enable simple bus in SPL on all boards
The simple bus support must be enabled in SPL, otherwise the boards will not be able to parse the DT and will fail to boot.
That's probably is biting me. Any idea which commit introduced this "U-Boot proper needs U-Boot-SPL to have CONFIG_SPL_SIMPLE_BUS=y dependency?
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
Quoted 12 lines · Pavel Machek
Quoted 3 lines
I'm loading u-boot using tftp from u-boot 2013.01. Marek will claim that this configuration is unsupported, but it enables fairly quick development and was very useful for me in past.
Yes, I use this chainloading also quite frequently on some platforms. It should generally work on platforms with SPL support. Where the preloader / SPL / BootROM has initialized the base HW and the SDRAM. So that the U-Boot proper can get loaded into SDRAM. So it should also work on SoCFPGA. I have to admit, that I haven't tested it lately on SoCFPGA though.
Quoted 7 lines
Quoted 3 lines
Unfortunately, it stopped working between 2016.01-rc1 and -rc4. Before I start bisecting it, I wanted to ask if someone has idea what might be responsible?
As mentioned above, I've not tested on this platform lately, sorry. But I assume that you also test the latest release version, yes? And current master as well. Also failing there?
I have not got to current master. I retested 2016.01 now, and used config not based on my previous one, but based on defconfig, and it seems to work.
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Dear Pavel,
Quoted 3 lines · In message <20160120101901.GA9656@amd> you wrote:
Commit
8e535af2e441030f5e4b940a3756a0d92646b5febreaks compilation (previous one worked ok in my config).
Maybe it would help if, for this bisecting, you used the default config? Once the problem is isolated, you can switch back to your custom config.
Best regards,
Wolfgang Denk
Signature · 6 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - George Bernard Shaw