From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Booting non devicetree enabled kernels using u-boot build with CONFIG_OF_LIBFDT ?
Date: Mon, 17 Nov 2014 16:00:17 +0100 [thread overview]
Message-ID: <546A0D81.5080401@redhat.com> (raw)
In-Reply-To: <20141117145207.GV21184@bill-the-cat>
Hi,
On 11/17/2014 03:52 PM, Tom Rini wrote:
> On Thu, Nov 13, 2014 at 07:38:50PM +0100, 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) ?
>
> So first, I have to take it back. This isn't a behavior change
> introduced by Simon's re-org (Sorry Simon!). This is a real long
> standing "feature". I am agreeable to doing whatever the lowest impact
> change would be to allow a non-DT tree to boot with CONFIG_OF_LIBFDT
> set. I'm thinking we turn the error into a warning (so that it's still
> clear to the user that they booted without a DT, for when they didn't
> mean to do that)
I was thinking along the same lines, except that when a third argument
is explicitly given to u-boot, and then we do not find a dt, that should
be treated as an error IMHO. I've put whipping up a patch for this on my
todo list.
> and instead of a hang we just don't do the follow-up
> steps.
Actually not doing the follow-up steps (as in bootm execution steps) is what
we currently do. What we want to do is skip further dt processing / prepping,
but otherwise still continue with trying to boot the kernel.
> That should let all the existing scripts work, yes?
With the amendments done above, I think so, yes. But the proof is in the
pudding, iow I'll find out when I go work on that patch.
Regards,
Hans
prev parent reply other threads:[~2014-11-17 15:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 18:08 [U-Boot] Booting non devicetree enabled kernels using u-boot build with CONFIG_OF_LIBFDT ? Hans de Goede
2014-11-13 18:34 ` Tom Rini
2014-11-13 18:38 ` Hans de Goede
2014-11-16 19:41 ` Hans de Goede
2014-11-17 7:24 ` Simon Glass
2014-11-17 14:52 ` Tom Rini
2014-11-17 15:00 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546A0D81.5080401@redhat.com \
--to=hdegoede@redhat.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.