[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Stefan Roese]

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

[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Pavel Machek]

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 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] Chain-loading u-boot stopped working between 2016.01-rc1 and 2016.01-rc4

[Wolfgang Denk]

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

-- 
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