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

[Simon Glass]

Hi Hans,

On 16 November 2014 19:41, Hans de Goede <hdegoede at redhat.com> wrote:
> 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.

I'm not so sure. If I go back to v2011.03 I see that bootm_start()
calls boot_get_fdt() and prints that message if it fails. This call is
protected by CONFIG_OF_LIBFDT. So in this respect I don't see the new
code (bootm refactor of mid-2013) being different from the old.

It looks like this was created in this commit from 2008:

06a09918f bootm: refactor fdt locating and relocation code

It moved the PPC behaviour over to be common for all archs.

Of course I could be missing something, but I can't see it.

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

You can go through the steps using the bootm sub-commands, but it is a
bit painful. I'm not sure about the intended behaviour.

If you look at the README, it says:

> CONFIG_OF_LIBFDT
> New kernel versions are expecting firmware settings to be
> passed using flattened device trees (based on open firmware
> concepts).
> CONFIG_OF_LIBFDT
> * New libfdt-based support
> * Adds the "fdt" command
> * The bootm command automatically updates the fdt

My feeling is that CONFIG_OF_LIBFDT probably means that an FDT should
be provided to the kernel. If that is true then I don't like this
either - it should add the capability, not require it to be used. But
it appears to be long-standing behaviour going back 6 years.

What could we do? We presumably do want to report an error if there is
no FDT when the kernel needs it, but I'm not sure how we know. The
'dance' described above seems reasonable to me.

Regards,
Simon