Re: [U-Boot] distro boot on ls2085ardb

[Peter Newton]

> From: york sun
> Sent: Wednesday, February 08, 2017 5:06 PM
> To: Stuart Yoder ; ag...@suse.de; Prabhakar Kushwaha 
> 
> Cc: Peter Newton ; u-boot@lists.denx.de
> Subject: Re: distro boot on ls2085ardb
> 
> On 02/08/2017 02:55 PM, Stuart Yoder wrote:
> > All,
> >
> > The patch Alex submitted to enable distro boot on ls2085ardb sets up a
> > default bootcmd that looks like this:
> >
> >   bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x58070 &&
> >   cp.b $kernel_start $kernel_load $kernel_size &&
> >   bootm $kernel_load || run distro_bootcmd
> >
> > Was there any particular reason to attempt the NOR flash boot first?
> > (Just backwards compatibility?)  That "cp.b" takes a full
> > 30 seconds and seems potentially unnecessary.  I thought the board was
> > hung.
> >
> > We want to support distro boot on all NXP LS* boards, and I'm
> > wondering if it's better to just make running distro_bootcmd the
> > default, and then fall back to NOR flash boot if distro boot fails.
> >
> >   bootcmd=run mcinitcmd && fsl_mc lazyapply dpl 0x58070 &&
> >   run distro_bootcmd ||
> >   cp.b $kernel_start $kernel_load $kernel_size &&
> >   bootm $kernel_load
> >
> > Thoughts?
> 
> It was for backward compatibility. Even I have pointed out numerous times 
> (internally) that cp.b should not be used for this case, and
> even pointed out how to make a FIT image with load address, the board
> maintainer(s) didn't act. One change I can propose is to drop the "cp.b 
> $kernel_start $kernel_load $kernel_size" and run "bootm
> $kernel_start"
> directly. If it fails, then falls to distro_bootcmd.

I wondered why we needed the cp.b at all.  How do you add the load address to 
fit?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

[Peter Newton]

> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, May 16, 2016 7:21 AM
> To: Bhupesh Sharma ; Amit Tomer 
> 
> Cc: york sun ; u-boot@lists.denx.de; Peter Newton 
> 
> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> 
> 
> On 16.05.16 14:04, Bhupesh Sharma wrote:
> >
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Monday, May 16, 2016 1:09 PM
> >> To: Amit Tomer 
> >> Cc: Bhupesh Sharma ; york sun
> >> ; u-boot@lists.denx.de; Peter Newton
> >> 
> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>
> >>
> >>
> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer :
> >>>
> >>>> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> >>  wrote:
> >>>> Note that UEFI firmware support is already available on LS2080A-RDB
> >>>> and allows Booting distributions like CentOS on the same.
> >>>
> >>> Sorry to intervene here but it's about having the EFI support inside
> >>> u-boot itself that may *not* required to have separate UEFI firmware
> >>> to boot various distributions.
> >>>
> >>> Please correct, if it's not right ?
> >>
> >> It's correct. The idea is to allow everyone to boot using the uEFI
> >> entry point in Linux (or any other OS), regardless of whether they
> >> want to run U-Boot or a TianoCore based formware.
> >>
> >> This might seem useless today for embedded use cases, but some
> >> features are only available via an EFI entry, such as kASLR. You can
> >> also invoke Linux directly using the "bootefi" command, as Linux is
> >> an EFI binary itself. That way the boot path doesn't become much
> >> longer than with booti today.
> >>
> >
> > The default firmware being offered by NXP to boot distros on LS2080A and 
> > variants is UEFI.
> >
> > EFI application support in u-boot doesn't present a solution to things
> > like run-time variable/service support that is required by distros to
> > update firmware components on the go. And there are several other
> > services being offered by UEFI to help distro boot e.g. secure uefi boot 
> > through x.509 certifications compliant to UEFI specifications.
> 
> Don't get me wrong - I think it's great if there is a TianoCore based 
> firmware for LS2080A. But I didn't get the impression that there is a
> TianoCore based firmware for every NXP SoC out there, so enabling all of them 
> to use the U-Boot provided uEFI implementation is still
> a win.
> 
> That said, there's nothing that keeps us from implementing the bits you 
> mentioned in U-Boot either. There is support for RTS in U-
> Boot, we just didn't convert any drivers (RTC comes to mind first) yet.
> 
> There's also no support for uEFI environment variables, but mostly because 
> most systems I've used this code on so far just didn't have
> any storage to put them.
> 
> Certification checks also shouldn't be an issue if someone cared enough about 
> them.
> 
> But I don't think we need a discussion of TianoCore vs U-Boot. What everyone 
> really wants is to have things "just work". And some
> customers just prefer U-Boot for various reasons that are outside of my 
> control.
> If they can run the same boot path as everyone else, it makes life for me as 
> distribution vendor easier. And unlike other people in the
> community, I don't think being a TianoCore+ACPI messiah is any helpful for 
> that goal.

Agreed, this should not become a U-Boot vs UEFI thread.  And just to be sure it 
is clear to everyone, NXP currently offers both U-Boot and is starting to have 
UEFI firmware releases also.  We are not dropping U-Boot just because we begin 
to have UEFI.



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot