[U-Boot] 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

Hi Pavel,
On 20.01.2016 10:31, Pavel Machek wrote:
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.
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!
On 20.01.2016 10:31, Pavel Machek wrote:
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.
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

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?
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 marex@denx.de 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.
Signed-off-by: Marek Vasut marex@denx.de Cc: Dinh Nguyen dinguyen@opensource.altera.com
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

Dear Pavel,
In message 20160120101901.GA9656@amd you wrote:
Commit 8e535af2e441030f5e4b940a3756a0d92646b5fe breaks 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
participants (3)
-
Pavel Machek
-
Stefan Roese
-
Wolfgang Denk