* [U-Boot] efi_loader: Add distro boot script for removable media
@ 2016-04-13 17:54 Stephen Warren
2016-04-13 18:24 ` Alexander Graf
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Warren @ 2016-04-13 17:54 UTC (permalink / raw)
To: u-boot
I've spotted a couple of problems in 74522c898b35 "efi_loader: Add
distro boot script for removable media". These help explain something I
found strange in the commit description of the recently sent patch
"jetson-tk1: Set fdtfile environment variable"; "The 4.5.0 kernel cannot
cope with U-Boot's internal device tree".
> "load_efi_dtb=" \
> "load ${devtype} ${devnum}:${distro_bootpart} " \
> "${fdt_addr_r} ${prefix}${fdtfile}; " \
> "fdt addr ${fdt_addr_r}\0" \
> \
The "fdt addr" command shouldn't be there. That affects the DT that
U-Boot's internal commands operate on internally. That is entirely
unrelated to the the DT that is passed to the Linux kernel. Instead, the
EFI code should pass the DTB at ${kernel_addr_r} to the kernel, just
like all other boot mechanisms do.
If by some chance U-Boot is configured by DTB and that DTB is fully
suitable to pass to the Linux kernel, then the board-specific code can
arrange for ${kernel_addr_r} to point at that same DTB, thus removing
the need to load one. However, that's unlikely to happen too often at
present; the most complete DTBs are housed in the Linux kernel source
tree, and DTB ABI still isn't really a thing, so in practice one mostly
wants to load a DTB that was built as part of the kernel being booted,
and hence U-Boot's DTB isn't relevant.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: Add distro boot script for removable media
2016-04-13 17:54 [U-Boot] efi_loader: Add distro boot script for removable media Stephen Warren
@ 2016-04-13 18:24 ` Alexander Graf
2016-04-13 18:31 ` Stephen Warren
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Graf @ 2016-04-13 18:24 UTC (permalink / raw)
To: u-boot
On 13.04.16 19:54, Stephen Warren wrote:
> I've spotted a couple of problems in 74522c898b35 "efi_loader: Add
> distro boot script for removable media". These help explain something I
> found strange in the commit description of the recently sent patch
> "jetson-tk1: Set fdtfile environment variable"; "The 4.5.0 kernel cannot
> cope with U-Boot's internal device tree".
>
>> "load_efi_dtb=" \
>> "load ${devtype} ${devnum}:${distro_bootpart} " \
>> "${fdt_addr_r} ${prefix}${fdtfile}; " \
>> "fdt addr ${fdt_addr_r}\0" \
>> \
>
> The "fdt addr" command shouldn't be there. That affects the DT that
> U-Boot's internal commands operate on internally. That is entirely
> unrelated to the the DT that is passed to the Linux kernel. Instead, the
> EFI code should pass the DTB at ${kernel_addr_r} to the kernel, just
> like all other boot mechanisms do.
I guess you mean $fdt_addr_r?
I wasn't sure which one to pick back when I implemented it. "fdt addr"
seemed like a nice fit because it gets you an explicit fdt rather than a
"this is an address, go and see whether there happens to be a dtb loaded
there".
But I don't think it'll hurt to move it to fdt_addr_r instead.
> If by some chance U-Boot is configured by DTB and that DTB is fully
> suitable to pass to the Linux kernel, then the board-specific code can
> arrange for ${kernel_addr_r} to point at that same DTB, thus removing
> the need to load one. However, that's unlikely to happen too often at
> present; the most complete DTBs are housed in the Linux kernel source
> tree, and DTB ABI still isn't really a thing, so in practice one mostly
> wants to load a DTB that was built as part of the kernel being booted,
> and hence U-Boot's DTB isn't relevant.
It depends on the camp you're coming from ;). If you come from the
traditional server camp that used to work with server class ppc in the
past, then device tree by firmware is a pretty natural concept. Also,
all ARM servers available today have a stable dtb ABI, because they all
provide dtb via uEFI.
In the embedded world this doesn't hold true quite as well
unfortunately. People only realize that their device trees are
incomplete / wrong when they write the respective drivers. So there we
see much more churn.
Over time however as a platform ages, the "embedded" style systems
should end up with stable dtbs as well, at which point having them
provided by U-Boot straight away is a nice compromise.
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: Add distro boot script for removable media
2016-04-13 18:24 ` Alexander Graf
@ 2016-04-13 18:31 ` Stephen Warren
2016-04-13 18:47 ` Alexander Graf
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Warren @ 2016-04-13 18:31 UTC (permalink / raw)
To: u-boot
On 04/13/2016 12:24 PM, Alexander Graf wrote:
>
>
> On 13.04.16 19:54, Stephen Warren wrote:
>> I've spotted a couple of problems in 74522c898b35 "efi_loader: Add
>> distro boot script for removable media". These help explain something I
>> found strange in the commit description of the recently sent patch
>> "jetson-tk1: Set fdtfile environment variable"; "The 4.5.0 kernel cannot
>> cope with U-Boot's internal device tree".
>>
>>> "load_efi_dtb=" \
>>> "load ${devtype} ${devnum}:${distro_bootpart} " \
>>> "${fdt_addr_r} ${prefix}${fdtfile}; " \
>>> "fdt addr ${fdt_addr_r}\0" \
>>> \
>>
>> The "fdt addr" command shouldn't be there. That affects the DT that
>> U-Boot's internal commands operate on internally. That is entirely
>> unrelated to the the DT that is passed to the Linux kernel. Instead, the
>> EFI code should pass the DTB at ${kernel_addr_r} to the kernel, just
>> like all other boot mechanisms do.
>
> I guess you mean $fdt_addr_r?
Sorry, yes.
> I wasn't sure which one to pick back when I implemented it. "fdt addr"
> seemed like a nice fit because it gets you an explicit fdt rather than a
> "this is an address, go and see whether there happens to be a dtb loaded
> there".
>
> But I don't think it'll hurt to move it to fdt_addr_r instead.
Sounds good.
>> If by some chance U-Boot is configured by DTB and that DTB is fully
>> suitable to pass to the Linux kernel, then the board-specific code can
>> arrange for ${kernel_addr_r} to point at that same DTB, thus removing
>> the need to load one. However, that's unlikely to happen too often at
>> present; the most complete DTBs are housed in the Linux kernel source
>> tree, and DTB ABI still isn't really a thing, so in practice one mostly
>> wants to load a DTB that was built as part of the kernel being booted,
>> and hence U-Boot's DTB isn't relevant.
>
> It depends on the camp you're coming from ;). If you come from the
> traditional server camp that used to work with server class ppc in the
> past, then device tree by firmware is a pretty natural concept. Also,
> all ARM servers available today have a stable dtb ABI, because they all
> provide dtb via uEFI.
>
> In the embedded world this doesn't hold true quite as well
> unfortunately. People only realize that their device trees are
> incomplete / wrong when they write the respective drivers. So there we
> see much more churn.
>
> Over time however as a platform ages, the "embedded" style systems
> should end up with stable dtbs as well, at which point having them
> provided by U-Boot straight away is a nice compromise.
Yes, unfortunately DTB ABI or completeness isn't something that many
downstreams think about. I'm not convinced that will change much at the
time boards (or drivers for specific HW modules) first appear upstream.
You're right that boards that have been around a while will tend to
stabilize.
For embedded targets, given that we already support loading DTBs
separately, I'm not sure I would want to change away from that. The
system works and people are familiar with it. Switching to a different
scheme means everyone has to adapt. Still, it might work out well on a
case-by-case basis.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: Add distro boot script for removable media
2016-04-13 18:31 ` Stephen Warren
@ 2016-04-13 18:47 ` Alexander Graf
2016-04-13 18:54 ` Andreas Färber
0 siblings, 1 reply; 6+ messages in thread
From: Alexander Graf @ 2016-04-13 18:47 UTC (permalink / raw)
To: u-boot
On 13.04.16 20:31, Stephen Warren wrote:
> On 04/13/2016 12:24 PM, Alexander Graf wrote:
>>
>>
>>> If by some chance U-Boot is configured by DTB and that DTB is fully
>>> suitable to pass to the Linux kernel, then the board-specific code can
>>> arrange for ${kernel_addr_r} to point at that same DTB, thus removing
>>> the need to load one. However, that's unlikely to happen too often at
>>> present; the most complete DTBs are housed in the Linux kernel source
>>> tree, and DTB ABI still isn't really a thing, so in practice one mostly
>>> wants to load a DTB that was built as part of the kernel being booted,
>>> and hence U-Boot's DTB isn't relevant.
>>
>> It depends on the camp you're coming from ;). If you come from the
>> traditional server camp that used to work with server class ppc in the
>> past, then device tree by firmware is a pretty natural concept. Also,
>> all ARM servers available today have a stable dtb ABI, because they all
>> provide dtb via uEFI.
>>
>> In the embedded world this doesn't hold true quite as well
>> unfortunately. People only realize that their device trees are
>> incomplete / wrong when they write the respective drivers. So there we
>> see much more churn.
>>
>> Over time however as a platform ages, the "embedded" style systems
>> should end up with stable dtbs as well, at which point having them
>> provided by U-Boot straight away is a nice compromise.
>
> Yes, unfortunately DTB ABI or completeness isn't something that many
> downstreams think about. I'm not convinced that will change much at the
> time boards (or drivers for specific HW modules) first appear upstream.
> You're right that boards that have been around a while will tend to
> stabilize.
>
> For embedded targets, given that we already support loading DTBs
> separately, I'm not sure I would want to change away from that. The
> system works and people are familiar with it. Switching to a different
> scheme means everyone has to adapt. Still, it might work out well on a
> case-by-case basis.
I've seen it work pretty well on server class ARM systems, so I'm
convinced the model can work. If people care :).
The interesting bit is that in the "real" embedded case, the model would
work as well, because U-Boot would get updated in conjunction with the
kernel, so they'd be in sync.
But what I'm aiming for is a waterfall model. Basically allow people to
provide the device tree using
* internal U-Boot (either its own or a separate dtb)
* distro override
* grub override
Each come with their own pitfalls. Grub override is the worst of the
bunch, because you're losing all of the device tree patching for memory
size, simplefb, secondary entry points, etc. There's simply no efi hook
for it and I'm not sure it's worth implementing our own protocol just
for this use case.
But nobody forces you to use any of these, in any model. If U-Boot
provides a dtb, you are free to use it or override it. If you provide a
dtb at the known-good location, you can still override it using grub
overrides.
In fact, if you don't want to you don't even have to use the distro
bootcmd. You can create your own bootcmd that does
load mmc 0 $fdt_addr_r my_awesome.dtb ;\
load mmc 0 $kernel_addr_r some/random/path/grub2.efi ;\
bootefi $kernel_addr_r
and it would work just like you would expect it to work. The point about
these defaults is that we have some path for users to not have to know
these details :). I think one of U-Boot's great strengths is its
modularity where you can do pretty much anything you want. But I guess
I'm preaching to the choir ;).
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: Add distro boot script for removable media
2016-04-13 18:47 ` Alexander Graf
@ 2016-04-13 18:54 ` Andreas Färber
2016-04-13 19:01 ` Alexander Graf
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Färber @ 2016-04-13 18:54 UTC (permalink / raw)
To: u-boot
Am 13.04.2016 um 20:47 schrieb Alexander Graf:
> load mmc 0 $fdt_addr_r my_awesome.dtb ;\
> load mmc 0 $kernel_addr_r some/random/path/grub2.efi ;\
> bootefi $kernel_addr_r
If we're going in that direction, I would rather pass $fdt_addr_r as
second optional argument to bootefi. That would be more consistent with
bootm, bootz, booti.
While at it, is there a reason that bootz/booti create some output about
memory locations of initrd/fdt but bootefi does not?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] efi_loader: Add distro boot script for removable media
2016-04-13 18:54 ` Andreas Färber
@ 2016-04-13 19:01 ` Alexander Graf
0 siblings, 0 replies; 6+ messages in thread
From: Alexander Graf @ 2016-04-13 19:01 UTC (permalink / raw)
To: u-boot
On 13.04.16 20:54, Andreas F?rber wrote:
> Am 13.04.2016 um 20:47 schrieb Alexander Graf:
>> load mmc 0 $fdt_addr_r my_awesome.dtb ;\
>> load mmc 0 $kernel_addr_r some/random/path/grub2.efi ;\
>> bootefi $kernel_addr_r
>
> If we're going in that direction, I would rather pass $fdt_addr_r as
> second optional argument to bootefi. That would be more consistent with
> bootm, bootz, booti.
Yes, probably.
> While at it, is there a reason that bootz/booti create some output about
> memory locations of initrd/fdt but bootefi does not?
Is that important information? I don't quite get the feeling that it is.
Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-04-13 19:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-13 17:54 [U-Boot] efi_loader: Add distro boot script for removable media Stephen Warren
2016-04-13 18:24 ` Alexander Graf
2016-04-13 18:31 ` Stephen Warren
2016-04-13 18:47 ` Alexander Graf
2016-04-13 18:54 ` Andreas Färber
2016-04-13 19:01 ` Alexander Graf
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.