From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] cmd: pxe: Use internal FDT if external one cannot be retrieved
Date: Thu, 29 Aug 2019 14:35:33 -0600 [thread overview]
Message-ID: <40c2ba60-4ef5-7861-8725-9347f9346439@wwwdotorg.org> (raw)
In-Reply-To: <CAPbbKZZeok5+qOjdf8mKJ-uMjUsY5rGu3+gmaSsnfVC4dWrNVQ@mail.gmail.com>
On 8/29/19 5:20 AM, Anton Leontiev wrote:
> 2019-08-26 at 18:59, Stephen Warren <swarren@wwwdotorg.org>:
>> On 8/23/19 8:40 AM, Anton Leontiev wrote:
>>> From: Anton Leontiev <aleontiev@elvees.com>
>>>
>>> Original commit c61d94d86035 ("pxe: implement fdtdir extlinux.conf tag")
>>> states, that if FDT file cannot be retrieved then FDT packaged in
>>> firmware should be used.
>>
>> It's not meant to say that. I believe the part of the description you're
>> referring to is:
>>
>> if no FDT file was loaded, and $fdtaddr is set:
>> # This indicates an FDT packaged with firmware
>> use the FDT at $fdtaddr
>>
>> That wasn't meant to say anything about "if there was an error loading
>> the FDT file", but rather is meant to mean "if no FDT file was loaded
>> because extlinux.conf contained no fdt or fdtdir statement". Nothing
>> there is intended to refer to errors loading a specified FDT file.
...
>> What specific problem are you trying to solve?
>
> We have a GNU/Linux distribution that use FDTDIR in its extlinux.conf
> to support several boards. But some boards have FDT embedded in U-Boot
> and it is't present in FDTDIR. In such configuration U-Boot fails to
> boot an entry, despite no exact FDT is specified in it. Distribution
> itself is designed to work on any board.
I lookead at that referenced commit description in full and the code,
and I believe what you want is for U-Boot to set fdt_addr to the
location of the in-RAM DT, and leave fdt_addr_r unset. This will
indicate to the pxe code that no FDT should be loaded when parsing
extlinux.conf, but instead to use fdt_addr directly.
Does that work for you, or does it break some other script/use-case on
this board?
next prev parent reply other threads:[~2019-08-29 20:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-23 14:40 [U-Boot] [PATCH] cmd: pxe: Use internal FDT if external one cannot be retrieved Anton Leontiev
2019-08-26 15:59 ` Stephen Warren
2019-08-29 11:20 ` Anton Leontiev
2019-08-29 20:35 ` Stephen Warren [this message]
2019-08-31 19:52 ` Anton Leontiev
2019-09-03 16:16 ` Stephen Warren
2019-09-03 7:52 ` [U-Boot] [PATCH v2] cmd: pxe: Use internal FDT if retrieving from FDTDIR fails Anton Leontiev
2019-09-03 16:18 ` Stephen Warren
2019-09-17 6:07 ` Anton Leontiev
2019-10-15 5:59 ` Anton Leontiev
2020-12-02 21:21 ` Tom Rini
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=40c2ba60-4ef5-7861-8725-9347f9346439@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--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.