[U-Boot] Booting non devicetree enabled kernels using u-boot build with CONFIG_OF_LIBFDT ?

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 11/13/2014 07:38 PM, Hans de Goede wrote:
> Hi,
> 
> On 11/13/2014 07:34 PM, Tom Rini wrote:
>> On Thu, Nov 13, 2014 at 07:08:59PM +0100, Hans de Goede wrote:
>>> Hi all,
>>>
>>> So as you know I've been working on getting mainline u-boot to boot the
>>> older android derived linux-sunxi kernels, as some people need features
>>> not yet in mainline, and I would like there to be only one u-boot for both.
>>>
>>> I had this working a while ago, but recently it broke, this is caused by
>>> config_distro_defaults.h setting CONFIG_OF_LIBFDT, if I undef that
>>> after including config_distro_defaults.h things work again.
>>>
>>> I do not know if CONFIG_OF_LIBFDT is a recent addition to config_distro_defaults.h,
>>> or if something else broke things. But if I do not undef it, boot fails with:
>>>
>>> sun7i# bootm start 0x48000000
>>> ## Booting kernel from Legacy Image at 48000000 ...
>>>    Image Name:   Linux-3.4.75.sun7i+
>>>    Image Type:   ARM Linux Kernel Image (uncompressed)
>>>    Data Size:    3966672 Bytes = 3.8 MiB
>>>    Load Address: 40008000
>>>    Entry Point:  40008000
>>>    Verifying Checksum ... OK
>>> Could not find a valid device tree
>>
>> My hunch is that we've got more fall-out from Simon's re-org of the
>> bootm code ages ago.  It should be valid to try and boot a kernel
>> without a device tree and other parts of the code base (for example
>> arch/arm/lib/bootm.c) still do a FDT-or-ATAGS dance for example.
> 
> That is good news, because ideally upstream u-boot build with
> OLD_SUNXI_KERNEL_COMPAT should be able to boot old disk images without
> needing them to modify their boot.scr, which requiring bootm 0xfoo - -
> would do.
> 
> So maybe check if there is a third argument to bootm, and if there
> is not still try the dance for finding one appended in various ways,
> and if that fails continue normally (where as with the third
> argument present this of course needs to stay an error) ?

Ping ? The above was intended as a question, I'm willing to spend some
time on getting the behavior suggested above, but first I would like to
heat that such behavior is desirable (and thus my patch has a chance of
getting applied).

Regards,

Hans