Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Peter Robinson]

>> I am not aware of anyone using the U-Boot API for grub these days, so
>> I'm not sure it's an incredibly useful goal. The main pain point distros
>> seem to have is to make something that "just works" on all systems out
>> there. Moving into that direction should be our ultimate goal.
>
> Please note that with the generic distro framework U-Boot will grok
> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> over holiday so I can drop them in whatever board and boot up Linux as a
> sanity test.

This is certtainly Fedora's preferred method for u-boot based devices

> I certainly can see a usecase for kicking off an EFI binary as part of
> fitting into existing work-flows.  But we do already have a something
> for getting rid of that particular pain-point and it's working :)

It would certainly be a useful option to have.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Fri, Jan 15, 2016 at 04:00:21AM +0100, Alexander Graf wrote:
> 
> 
> On 25.12.15 17:50, Tom Rini wrote:
> > On Fri, Dec 25, 2015 at 09:53:22AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 25.12.15 04:29, Tom Rini wrote:
> >>> On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
> >>>
>  This is my Christmas present for my openSUSE friends :).
> 
>  U-Boot is a great project for embedded devices. However, convincing
>  everyone involved that only for "a few oddball ARM devices" we need to
>  support different configuration formats from grub2 when all other 
>  platforms
>  (PPC, System Z, x86) are standardized on a single format is a nightmare.
> 
>  So we started to explore alternatives. At first, people tried to get
>  grub2 running using the u-boot api interface. However, FWIW that one
>  doesn't support relocations, so you need to know where to link grub2 to
>  at compile time. It also seems to be broken more often than not. And on
>  top of it all, it's a one-off interface, so yet another thing to 
>  maintain.
> 
>  That led to a nifty idea. What if we can just implement the EFI 
>  application
>  protocol on top of U-Boot? Then we could compile a single grub2 binary 
>  for
>  uEFI based systems and U-Boot based systems and as soon as that one's 
>  loaded,
>  everything looks and feels (almost) the same.
> 
>  This patch set is the result of pursuing this endeavor.
> >>>
> >>> So, I owe the whole codebase a real review.  My very quick question
> >>> however is, aside from what you had to borrow from wine, can you license
> >>> everything else as GPL v2 or later rather than LGPL?
> >>
> >> I'm personally a pretty big fan of the LGPL, since it's a very
> >> reasonable compromise between closed and open source IMHO ;).
> >>
> >> Is there a particular reason you're asking for this? LGPL code is fully
> >> compatible with GPL code and the resulting binary would be GPL anyway
> >> because FWIW you can't compile U-Boot without GPL code inside.
> > 
> > The general rules for U-Boot code are to be GPL v2 or later.  U-Boot is
> > (and always will be) a GPL v2 only project as there's simply too much
> > Linux kernel code that we want to leverage.  We do make special
> > exceptions at times for very good reasons (like include/android_image.h
> > is the authorative BSD-2 clause copy of that information) and I've even
> > told some companies that for crypto-auth-sensitive stuff they can do GPL
> > v2 only in their submission (again, due to U-Boot always being a v2 only
> > project).
> > 
> > So, I'm not gonig to reject the EFI loader code if you say no, you won't
> > re-license it as GPL v2 (or v2 and later) but I'd really appreciate it.
> > Thanks!
> 
> I've just read up and apparently it's completely legal and allowed to
> simply remove the LGPL (2.1+) boilerplate from a file and instead put a
> GPL (2.0+) one on it, even if you didn't write the code.

Legal and good idea don't always match up :)

> So even if I had insisted to stick to LGPL v2.1+, you could've just
> written a patch to change it after the fact ;).
> 
> But since everyone seems to be far more happy with GPL rather than LGPL,
> I've spared you that patch and changed the headers myself now.

Thanks, I appreciate it!

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Alexander Graf]

On 25.12.15 17:50, Tom Rini wrote:
> On Fri, Dec 25, 2015 at 09:53:22AM +0100, Alexander Graf wrote:
>>
>>
>> On 25.12.15 04:29, Tom Rini wrote:
>>> On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
>>>
 This is my Christmas present for my openSUSE friends :).

 U-Boot is a great project for embedded devices. However, convincing
 everyone involved that only for "a few oddball ARM devices" we need to
 support different configuration formats from grub2 when all other platforms
 (PPC, System Z, x86) are standardized on a single format is a nightmare.

 So we started to explore alternatives. At first, people tried to get
 grub2 running using the u-boot api interface. However, FWIW that one
 doesn't support relocations, so you need to know where to link grub2 to
 at compile time. It also seems to be broken more often than not. And on
 top of it all, it's a one-off interface, so yet another thing to maintain.

 That led to a nifty idea. What if we can just implement the EFI application
 protocol on top of U-Boot? Then we could compile a single grub2 binary for
 uEFI based systems and U-Boot based systems and as soon as that one's 
 loaded,
 everything looks and feels (almost) the same.

 This patch set is the result of pursuing this endeavor.
>>>
>>> So, I owe the whole codebase a real review.  My very quick question
>>> however is, aside from what you had to borrow from wine, can you license
>>> everything else as GPL v2 or later rather than LGPL?
>>
>> I'm personally a pretty big fan of the LGPL, since it's a very
>> reasonable compromise between closed and open source IMHO ;).
>>
>> Is there a particular reason you're asking for this? LGPL code is fully
>> compatible with GPL code and the resulting binary would be GPL anyway
>> because FWIW you can't compile U-Boot without GPL code inside.
> 
> The general rules for U-Boot code are to be GPL v2 or later.  U-Boot is
> (and always will be) a GPL v2 only project as there's simply too much
> Linux kernel code that we want to leverage.  We do make special
> exceptions at times for very good reasons (like include/android_image.h
> is the authorative BSD-2 clause copy of that information) and I've even
> told some companies that for crypto-auth-sensitive stuff they can do GPL
> v2 only in their submission (again, due to U-Boot always being a v2 only
> project).
> 
> So, I'm not gonig to reject the EFI loader code if you say no, you won't
> re-license it as GPL v2 (or v2 and later) but I'd really appreciate it.
> Thanks!

I've just read up and apparently it's completely legal and allowed to
simply remove the LGPL (2.1+) boilerplate from a file and instead put a
GPL (2.0+) one on it, even if you didn't write the code.

So even if I had insisted to stick to LGPL v2.1+, you could've just
written a patch to change it after the fact ;).

But since everyone seems to be far more happy with GPL rather than LGPL,
I've spared you that patch and changed the headers myself now.


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Peter Robinson]

On Mon, Jan 4, 2016 at 6:03 PM, Andreas Färber  wrote:
> Am 04.01.2016 um 17:56 schrieb Tom Rini:
>> Please note that with the generic distro framework U-Boot will grok
>> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
>> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
>> over holiday so I can drop them in whatever board and boot up Linux as a
>> sanity test.
>>
>> I certainly can see a usecase for kicking off an EFI binary as part of
>> fitting into existing work-flows.  But we do already have a something
>> for getting rid of that particular pain-point and it's working :)
>
> No, as I explained before, you are not addressing that particular
> pain-point: extlinux is still something new to implement for us as
> distro, you provide no tools to help us, while on x86, ppc, s390 and
> some aarch64 we have converged on grub2 as a standard, and just recently
> the YaST devs decided to only support grub2 going forward.
>
> For extlinux (which BTW to my eye looked slightly different from the
> freedesktop.org spec that you guys keep referencing?!), distro-specific
> code needs to be written [1] so that on kernel installation the
> /boot/extlinux/extlinux.conf file is regenerated - for grub2 such tools
> simply exist as part of GRUB and this proposed EFI interface for U-Boot
> will avoid having to implement any new, e.g., perl-Bootloader code.

Yes, that is true, but it only has to be done once.

> So the open conflict is that you tell us that extlinux.conf is your
> "distro" mechanism that we should be using, and our distro people are
> telling us that grub2 is their preferred solution after having
> accumulated bootloader code for some two decades and just got rid of it.
>
> Standards are not created through publishing some spec, they are created
> through adoption, and today I don't see anyone at SUSE moving an inch
> towards adopting extlinux.conf as a generic boot mechanism for all
> architectures. That leaves our ARM community at a loss, booting a single
> kernel through a symlink.

It's certainly not ideal but in Fedora (and I believe in Debian too)
we use the distro support in u-boot to boot dozens of devices with
multiple kernels and roll backs.

> No one has suggested to dump extlinux.conf or boot.scr, they can all
> simply co-exist, with the difference that, from the looks of it, Alex'
> EFI code could get enabled by default to allow users to choose using it,
> unlike the disabled CONFIG_API code that I reported got broken by DM
> migration and for many other boards was lacking defines and is in need
> of a board-specific rather than generic second bootloader on the distro
> side.
>
> This patchset is a cute middle ground where for U-Boot it's mostly just
> an additional command, our distro people will be content, and our ARM
> users will be happy too, not having to handcraft extlinux.conf files and
> benefiting from the vibrant U-Boot community as opposed to the much more
> fragmented Tianocore forks out there. Thus I'm hoping we can sort out
> some of the technical issues Leif pointed out and stop circling back to
> this unhelpful oh-but-extlinux.conf-is-the-mechanism point.

Yes, I think it's definitely good value, especially for aarch64
devices where uEFI is currently a much wider tested option due to the
current available devices.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Sun, Dec 27, 2015 at 06:39:16PM +, Leif Lindholm wrote:
> On Sun, Dec 27, 2015 at 01:10:39PM -0500, Tom Rini wrote:
> > So, my only "big" concern here is, are we as a community able to view
> > and implement the relevant parts of the UEFI spec (without having to
> > agree to a potentially complicated enough license to have to bug a
> > lawyer)?  It's been a while since I tried to view a copy so I'm hoping
> > the answer is now yes.  Thanks!
> 
> So:
> 1) You can certainly read the specification without agreeing to
>anything (click-through is now gone - docs accessible straight from
>http://uefi.org/specifications/).
> 2) The potential complication would be with regards to implementing
>and distributing - which requires signing the Adopters Agreement:
>
> http://uefi.org/sites/default/files/resources/UEFI_Adopters_Agreement_100907.pdf
> 
> I actually think the implications of 2) for a project like U-Boot
> would be a useful thing to bring up for discussion on the FW/OS forum
> mailing list at http://uefi.org/FWOSForum.

The answer I got back is
http://lists.mailman.uefi.org/pipermail/fw_os_forum/20160105/04.html
and in short, individuals are welcome to (and apparently many have) sign
and execute the agreement.  People that work for companies that have
already signed the agreement are good to go.  To me, this is reasonable
for the goals U-Boot has with respect to UEFI implementation.

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Andreas Färber]

Am 04.01.2016 um 19:03 schrieb Andreas Färber:
> Am 04.01.2016 um 17:56 schrieb Tom Rini:
>> Please note that with the generic distro framework U-Boot will grok
>> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
>> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
>> over holiday so I can drop them in whatever board and boot up Linux as a
>> sanity test.
>>
>> I certainly can see a usecase for kicking off an EFI binary as part of
>> fitting into existing work-flows.  But we do already have a something
>> for getting rid of that particular pain-point and it's working :)
> 
[snip]

Executive summary: https://xkcd.com/927/

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Mon, Jan 04, 2016 at 07:41:42PM +0100, Andreas Färber wrote:
> Am 04.01.2016 um 19:03 schrieb Andreas Färber:
> > Am 04.01.2016 um 17:56 schrieb Tom Rini:
> >> Please note that with the generic distro framework U-Boot will grok
> >> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
> >> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> >> over holiday so I can drop them in whatever board and boot up Linux as a
> >> sanity test.
> >>
> >> I certainly can see a usecase for kicking off an EFI binary as part of
> >> fitting into existing work-flows.  But we do already have a something
> >> for getting rid of that particular pain-point and it's working :)
> > 
> [snip]
> 
> Executive summary: https://xkcd.com/927/

Oh pretty much.  I guess the point I am driving at here is that EFI
loading (to kick off GRUB2) needs to fit in with the framework that
other distros have already adapted to.  Or heck, maybe you can convince
them to switch over to this instead?  Hans or Dennis, what do you think?

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Matwey V. Kornilov]

2016-01-04 19:56 GMT+03:00 Tom Rini :
> On Mon, Jan 04, 2016 at 05:25:44PM +0100, Alexander Graf wrote:
>
> [snip]
>> I am not aware of anyone using the U-Boot API for grub these days, so
>> I'm not sure it's an incredibly useful goal. The main pain point distros
>> seem to have is to make something that "just works" on all systems out
>> there. Moving into that direction should be our ultimate goal.
>
> Please note that with the generic distro framework U-Boot will grok
> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and

I would say this is pretty alpha spec. How should I specify fallback
booting with it?
Not to mention that currently grub2 perfectly boots from LVM and MD
partitions in my installations and this is not supported in spec (from
what I see).

p.s. > Currently there's little cooperation between multiple
distributions in dual-boot (or triple, ... multi-boot) setups

Have you ever seen anybody really needed it?


> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> over holiday so I can drop them in whatever board and boot up Linux as a
> sanity test.
>
> I certainly can see a usecase for kicking off an EFI binary as part of
> fitting into existing work-flows.  But we do already have a something
> for getting rid of that particular pain-point and it's working :)
>
> --
> Tom



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Alexander Graf]

On 04.01.16 23:37, Dennis Gilmore wrote:
> On Monday, January 04, 2016 02:54:40 PM Tom Rini wrote:
>> On Mon, Jan 04, 2016 at 07:41:42PM +0100, Andreas Färber wrote:
>>> Am 04.01.2016 um 19:03 schrieb Andreas Färber:
 Am 04.01.2016 um 17:56 schrieb Tom Rini:
> Please note that with the generic distro framework U-Boot will grok
> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> over holiday so I can drop them in whatever board and boot up Linux as
> a
> sanity test.
> We do not fully support bootloader spec in u-boot today. but I know that we 
> want to one day 
> 
> I certainly can see a usecase for kicking off an EFI binary as part of
> fitting into existing work-flows.  But we do already have a something
> for getting rid of that particular pain-point and it's working :)
>>>
>>> [snip]
>>>
>>> Executive summary: https://xkcd.com/927/
>>
>> Oh pretty much.  I guess the point I am driving at here is that EFI
>> loading (to kick off GRUB2) needs to fit in with the framework that
>> other distros have already adapted to.  Or heck, maybe you can convince
>> them to switch over to this instead?  Hans or Dennis, what do you think?
> 
> not opposed to it, but it is not something that we have evaluated, I know 
> debian have done a lot of work to ensure that their systems support 
> extlinux.conf also. which is the same syslinux format as used by 
> extlinux/syslinux/isolinux on x86, the user experience is somewhat similiar 
> to 
> that of grub on other arches.  Long term I have planed to wire up menu 
> support 
> so you get a menu to interact with rather than a list of boot options, as 
> well 
> as the ability to edit the commandline arguments. I would not say we have 
> perfect support today for extlinux. so far SuSE is the only one saying no to 
> what has been proposed. It was brought up on both the u-boot and linaro cross 
> distro list back in 2013[1][2] with no one saying it was not a good 
> idea.while 
> there was less feedback than I would have liked it was positive.
> 
> Anyway my main question is how dtb support would work. As that really is the 

Ideally the same way as on existing uEFI based AArch64 machines:
Firmware passes it to grub, grub reformats it and passes it on to Linux.

However, as people keep pointing out, we don't live in an ideal device
tree world - especially when thinking about boards that are running
U-Boot today. Chances are pretty good that a device tree that works for
your kernel from today won't run on tomorrow's kernel - or will lack
features.

So we still need to support the devicetree option in grub2 - and it does
work today. The only convenience missing from this patch set (and I'll
look into it once I have runtime service relocation working on 32bit) is
variable export. That way you'd be able to write

  devicetree (hd0,1)/dtb-4.10.2/$fdtfile

in your grub config and u-boot would magically tell you which dtb file
to load. Then - in theory - you wouldn't need any platform specific
logic in your bootloader configuration generation anymore.

> trickiest part that I can think of.  Something that is gracefully dealt with 
> in the extlinux support, regardless of distro.  Going this approach to me 
> feels like trying to put a Ford engine in a GM car by adding a volkswagon 
> gearbox. can we make grub a u-boot application? that is not using CONFIG_API 
> or does not need to have hard coded memory locations in it?  we looked at 

That's what this patch set is about, yes. It'd be the exact same grub2
binary that runs on all other EFI enabled systems. So if you run on
HIP04D01 or AMD Seattle today, chances are pretty good you have
everything in place already.

> grub2 support years ago as we felt that it would be the way to go as it 
> seemed 
> people were standardising on it. and decided that there were too many issues 
> with the implementation for it to be viable.  so we went the route of 
> proposing the extlinux.conf file option. 

I'm no evangelist - if the extlinux.conf solution works for people, I'm
happy if they stick with it. It just simply doesn't work well for us ;).


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Mon, Jan 04, 2016 at 05:25:44PM +0100, Alexander Graf wrote:

[snip]
> I am not aware of anyone using the U-Boot API for grub these days, so
> I'm not sure it's an incredibly useful goal. The main pain point distros
> seem to have is to make something that "just works" on all systems out
> there. Moving into that direction should be our ultimate goal.

Please note that with the generic distro framework U-Boot will grok
https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
things Just Work.  I setup a bunch of SD cards with Debian and Fedora
over holiday so I can drop them in whatever board and boot up Linux as a
sanity test.

I certainly can see a usecase for kicking off an EFI binary as part of
fitting into existing work-flows.  But we do already have a something
for getting rid of that particular pain-point and it's working :)

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Dennis Gilmore]

On Monday, January 04, 2016 02:54:40 PM Tom Rini wrote:
> On Mon, Jan 04, 2016 at 07:41:42PM +0100, Andreas Färber wrote:
> > Am 04.01.2016 um 19:03 schrieb Andreas Färber:
> > > Am 04.01.2016 um 17:56 schrieb Tom Rini:
> > >> Please note that with the generic distro framework U-Boot will grok
> > >> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
> > >> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> > >> over holiday so I can drop them in whatever board and boot up Linux as
> > >> a
> > >> sanity test.
We do not fully support bootloader spec in u-boot today. but I know that we 
want to one day 

> > >> I certainly can see a usecase for kicking off an EFI binary as part of
> > >> fitting into existing work-flows.  But we do already have a something
> > >> for getting rid of that particular pain-point and it's working :)
> > 
> > [snip]
> > 
> > Executive summary: https://xkcd.com/927/
> 
> Oh pretty much.  I guess the point I am driving at here is that EFI
> loading (to kick off GRUB2) needs to fit in with the framework that
> other distros have already adapted to.  Or heck, maybe you can convince
> them to switch over to this instead?  Hans or Dennis, what do you think?

not opposed to it, but it is not something that we have evaluated, I know 
debian have done a lot of work to ensure that their systems support 
extlinux.conf also. which is the same syslinux format as used by 
extlinux/syslinux/isolinux on x86, the user experience is somewhat similiar to 
that of grub on other arches.  Long term I have planed to wire up menu support 
so you get a menu to interact with rather than a list of boot options, as well 
as the ability to edit the commandline arguments. I would not say we have 
perfect support today for extlinux. so far SuSE is the only one saying no to 
what has been proposed. It was brought up on both the u-boot and linaro cross 
distro list back in 2013[1][2] with no one saying it was not a good idea.while 
there was less feedback than I would have liked it was positive.

Anyway my main question is how dtb support would work. As that really is the 
trickiest part that I can think of.  Something that is gracefully dealt with 
in the extlinux support, regardless of distro.  Going this approach to me 
feels like trying to put a Ford engine in a GM car by adding a volkswagon 
gearbox. can we make grub a u-boot application? that is not using CONFIG_API 
or does not need to have hard coded memory locations in it?  we looked at 
grub2 support years ago as we felt that it would be the way to go as it seemed 
people were standardising on it. and decided that there were too many issues 
with the implementation for it to be viable.  so we went the route of 
proposing the extlinux.conf file option. 

Dennis 


[1] https://lists.linaro.org/pipermail/cross-distro/2013-August/000439.html
[2] http://lists.denx.de/pipermail/u-boot/2013-August/160080.html


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Andreas Färber]

Am 04.01.2016 um 17:56 schrieb Tom Rini:
> Please note that with the generic distro framework U-Boot will grok
> https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/ and
> things Just Work.  I setup a bunch of SD cards with Debian and Fedora
> over holiday so I can drop them in whatever board and boot up Linux as a
> sanity test.
> 
> I certainly can see a usecase for kicking off an EFI binary as part of
> fitting into existing work-flows.  But we do already have a something
> for getting rid of that particular pain-point and it's working :)

No, as I explained before, you are not addressing that particular
pain-point: extlinux is still something new to implement for us as
distro, you provide no tools to help us, while on x86, ppc, s390 and
some aarch64 we have converged on grub2 as a standard, and just recently
the YaST devs decided to only support grub2 going forward.

For extlinux (which BTW to my eye looked slightly different from the
freedesktop.org spec that you guys keep referencing?!), distro-specific
code needs to be written [1] so that on kernel installation the
/boot/extlinux/extlinux.conf file is regenerated - for grub2 such tools
simply exist as part of GRUB and this proposed EFI interface for U-Boot
will avoid having to implement any new, e.g., perl-Bootloader code.

So the open conflict is that you tell us that extlinux.conf is your
"distro" mechanism that we should be using, and our distro people are
telling us that grub2 is their preferred solution after having
accumulated bootloader code for some two decades and just got rid of it.

Standards are not created through publishing some spec, they are created
through adoption, and today I don't see anyone at SUSE moving an inch
towards adopting extlinux.conf as a generic boot mechanism for all
architectures. That leaves our ARM community at a loss, booting a single
kernel through a symlink.

No one has suggested to dump extlinux.conf or boot.scr, they can all
simply co-exist, with the difference that, from the looks of it, Alex'
EFI code could get enabled by default to allow users to choose using it,
unlike the disabled CONFIG_API code that I reported got broken by DM
migration and for many other boards was lacking defines and is in need
of a board-specific rather than generic second bootloader on the distro
side.

This patchset is a cute middle ground where for U-Boot it's mostly just
an additional command, our distro people will be content, and our ARM
users will be happy too, not having to handcraft extlinux.conf files and
benefiting from the vibrant U-Boot community as opposed to the much more
fragmented Tianocore forks out there. Thus I'm hoping we can sort out
some of the technical issues Leif pointed out and stop circling back to
this unhelpful oh-but-extlinux.conf-is-the-mechanism point.

Regards,
Andreas

[1] https://github.com/openSUSE/perl-bootloader/pull/81

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Alexander Graf]

On 26.12.15 20:34, Leif Lindholm wrote:
> On Sat, Dec 26, 2015 at 05:27:48PM +0100, Alexander Graf wrote:
 This patch set is the result of pursuing this endeavor.
>>>
>>> Thanks, this is a very cool thing.
>>> I meant to reply sooner, but Christmas got in the way.
>>>
   - I am successfully able to run grub2 and Linux EFI binaries with this 
 code.
   - When enabled, the resulting U-Boot binary only grows by ~10kb,
 so it's very light weight.
   - It works on 32bit ARM and AArch64. 
   - All storage devices are directly accessible
   - No runtime services (all calls return unimplemented)
>>>
>>> Yeah, this is a bit of a pain point. The time services, virtual memory
>>> services and reset being the key ones.
>>
>> I guess reset should be pretty well doable. What are virtual memory
>> services? The bits that translate RTS code to run in virtual address
>> space somewhere else?
> 
> Yup.

Can you point me to code that uses the time services?

> 
>>>
   - No EFI variables
>>>
>>> This would obviously (from my point of view) be desirable, but at
>>> least initially, we can do most things without persistent variables.
>>
>> Doing EFI variables before exiting boot services is easy - we could even
>> just map U-Boot variables to EFI variables. That could come in handy for
>> cases where you want U-Boot to tell you which board you're on so you can
>> refer to different dtb files in your grub.cfg (if you need to override
>> the dtb).
>>
>> Making them persistent is another difficult question - U-Boot usually
>> splits "modify variable" from "store variable pool to nvram".
> 
> Indeed.
> UEFI might as well, but in more convoluted ways.
> 
>> And the hardest part would obviously be to make all of this work while
>> Linux is running ;). I'd definitely prefer to defer that bit to later.
> 
> Of course.
> 
> And again - depending on ambition levels, implementing a version of
> efibootmgr that ended up simply tweaking a /boot/uEnv.txt (or similar)
> if U-Boot boot environment was detected would be entirely achievable.
> 
 Of course, there are still a few things one could do on top:

   - Implement removable media booting (search for 
 /efi/boot/boota{a64,rm}.efi)
>>>
>>> Yeah, that would be top of my wishlist.
>>
>> That should be pretty simple to do - maybe we can even get away without
>> any C code for it.
> 
> Should be possible.
> 
>>>
   - Improve disk media detection (don't scan, use what information we have)
   - Add EFI variable support using NVRAM
   - Add GFX support
>>>
>>> GFX support was actually never implemented for U-Boot GRUB, so from
>>> this p.o.v. it is not a shortcoming over the existing impementation.
>>
>> Heh ;). My goal here really is to make U-Boot based systems be en par
>> with TianoCore based ones in terms of usability.
> 
> Sure. Just setting the nearer goal post of "where can we replace
> U-Boot API in GRUB".

I am not aware of anyone using the U-Boot API for grub these days, so
I'm not sure it's an incredibly useful goal. The main pain point distros
seem to have is to make something that "just works" on all systems out
there. Moving into that direction should be our ultimate goal.


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Sat, Dec 26, 2015 at 03:31:03PM +, Leif Lindholm wrote:
> On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
> > This is my Christmas present for my openSUSE friends :).
> > 
> > U-Boot is a great project for embedded devices. However, convincing
> > everyone involved that only for "a few oddball ARM devices" we need to
> > support different configuration formats from grub2 when all other platforms
> > (PPC, System Z, x86) are standardized on a single format is a nightmare.
> > 
> > So we started to explore alternatives. At first, people tried to get
> > grub2 running using the u-boot api interface. However, FWIW that one
> > doesn't support relocations, so you need to know where to link grub2 to
> > at compile time. It also seems to be broken more often than not. And on
> > top of it all, it's a one-off interface, so yet another thing to maintain.
> > 
> > That led to a nifty idea. What if we can just implement the EFI application
> > protocol on top of U-Boot? Then we could compile a single grub2 binary for
> > uEFI based systems and U-Boot based systems and as soon as that one's 
> > loaded,
> > everything looks and feels (almost) the same.
> > 
> > This patch set is the result of pursuing this endeavor.
> 
> Thanks, this is a very cool thing.
> I meant to reply sooner, but Christmas got in the way.
> 
> >   - I am successfully able to run grub2 and Linux EFI binaries with this 
> > code.
> >   - When enabled, the resulting U-Boot binary only grows by ~10kb,
> > so it's very light weight.
> >   - It works on 32bit ARM and AArch64. 
> >   - All storage devices are directly accessible
> >   - No runtime services (all calls return unimplemented)
> 
> Yeah, this is a bit of a pain point. The time services, virtual memory
> services and reset being the key ones.
> 
> >   - No EFI variables
> 
> This would obviously (from my point of view) be desirable, but at
> least initially, we can do most things without persistent variables.
> 
> > Of course, there are still a few things one could do on top:
> > 
> >   - Implement removable media booting (search for 
> > /efi/boot/boota{a64,rm}.efi)
> 
> Yeah, that would be top of my wishlist.
> 
> >   - Improve disk media detection (don't scan, use what information we have)
> >   - Add EFI variable support using NVRAM
> >   - Add GFX support
> 
> GFX support was actually never implemented for U-Boot GRUB, so from
> this p.o.v. it is not a shortcoming over the existing impementation.
> 
> >   - Make EFI Shell work ;)
> 
> - Network device support.
> 
> I also spotted a couple of minor things while playing around (things
> like image exit being missing), but these will be easy to flush out.
> 
> 
> I'll leave reviewing of the u-boot side of things to people who know
> the codebase better, and restrict myself to commenting on the
> UEFIness.

So, my only "big" concern here is, are we as a community able to view
and implement the relevant parts of the UEFI spec (without having to
agree to a potentially complicated enough license to have to bug a
lawyer)?  It's been a while since I tried to view a copy so I'm hoping
the answer is now yes.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Leif Lindholm]

On Sun, Dec 27, 2015 at 01:10:39PM -0500, Tom Rini wrote:
> So, my only "big" concern here is, are we as a community able to view
> and implement the relevant parts of the UEFI spec (without having to
> agree to a potentially complicated enough license to have to bug a
> lawyer)?  It's been a while since I tried to view a copy so I'm hoping
> the answer is now yes.  Thanks!

So:
1) You can certainly read the specification without agreeing to
   anything (click-through is now gone - docs accessible straight from
   http://uefi.org/specifications/).
2) The potential complication would be with regards to implementing
   and distributing - which requires signing the Adopters Agreement:
   
http://uefi.org/sites/default/files/resources/UEFI_Adopters_Agreement_100907.pdf

I actually think the implications of 2) for a project like U-Boot
would be a useful thing to bring up for discussion on the FW/OS forum
mailing list at http://uefi.org/FWOSForum.

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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Sun, Dec 27, 2015 at 06:39:16PM +, Leif Lindholm wrote:
> On Sun, Dec 27, 2015 at 01:10:39PM -0500, Tom Rini wrote:
> > So, my only "big" concern here is, are we as a community able to view
> > and implement the relevant parts of the UEFI spec (without having to
> > agree to a potentially complicated enough license to have to bug a
> > lawyer)?  It's been a while since I tried to view a copy so I'm hoping
> > the answer is now yes.  Thanks!
> 
> So:
> 1) You can certainly read the specification without agreeing to
>anything (click-through is now gone - docs accessible straight from
>http://uefi.org/specifications/).

Thats good.

> 2) The potential complication would be with regards to implementing
>and distributing - which requires signing the Adopters Agreement:
>
> http://uefi.org/sites/default/files/resources/UEFI_Adopters_Agreement_100907.pdf
> 
> I actually think the implications of 2) for a project like U-Boot
> would be a useful thing to bring up for discussion on the FW/OS forum
> mailing list at http://uefi.org/FWOSForum.

OK, I'll bring it up over there, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Leif Lindholm]

On Sat, Dec 26, 2015 at 05:27:48PM +0100, Alexander Graf wrote:
> >> This patch set is the result of pursuing this endeavor.
> > 
> > Thanks, this is a very cool thing.
> > I meant to reply sooner, but Christmas got in the way.
> > 
> >>   - I am successfully able to run grub2 and Linux EFI binaries with this 
> >> code.
> >>   - When enabled, the resulting U-Boot binary only grows by ~10kb,
> >> so it's very light weight.
> >>   - It works on 32bit ARM and AArch64. 
> >>   - All storage devices are directly accessible
> >>   - No runtime services (all calls return unimplemented)
> > 
> > Yeah, this is a bit of a pain point. The time services, virtual memory
> > services and reset being the key ones.
> 
> I guess reset should be pretty well doable. What are virtual memory
> services? The bits that translate RTS code to run in virtual address
> space somewhere else?

Yup.

> > 
> >>   - No EFI variables
> > 
> > This would obviously (from my point of view) be desirable, but at
> > least initially, we can do most things without persistent variables.
> 
> Doing EFI variables before exiting boot services is easy - we could even
> just map U-Boot variables to EFI variables. That could come in handy for
> cases where you want U-Boot to tell you which board you're on so you can
> refer to different dtb files in your grub.cfg (if you need to override
> the dtb).
> 
> Making them persistent is another difficult question - U-Boot usually
> splits "modify variable" from "store variable pool to nvram".

Indeed.
UEFI might as well, but in more convoluted ways.

> And the hardest part would obviously be to make all of this work while
> Linux is running ;). I'd definitely prefer to defer that bit to later.

Of course.

And again - depending on ambition levels, implementing a version of
efibootmgr that ended up simply tweaking a /boot/uEnv.txt (or similar)
if U-Boot boot environment was detected would be entirely achievable.

> >> Of course, there are still a few things one could do on top:
> >>
> >>   - Implement removable media booting (search for 
> >> /efi/boot/boota{a64,rm}.efi)
> > 
> > Yeah, that would be top of my wishlist.
> 
> That should be pretty simple to do - maybe we can even get away without
> any C code for it.

Should be possible.

> > 
> >>   - Improve disk media detection (don't scan, use what information we have)
> >>   - Add EFI variable support using NVRAM
> >>   - Add GFX support
> > 
> > GFX support was actually never implemented for U-Boot GRUB, so from
> > this p.o.v. it is not a shortcoming over the existing impementation.
> 
> Heh ;). My goal here really is to make U-Boot based systems be en par
> with TianoCore based ones in terms of usability.

Sure. Just setting the nearer goal post of "where can we replace
U-Boot API in GRUB".

> > 
> >>   - Make EFI Shell work ;)
> > 
> > - Network device support.
> 
> Oh, good point. I forgot about that one.
> 
> > I also spotted a couple of minor things while playing around (things
> > like image exit being missing), but these will be easy to flush out.
> 
> Awesome, looking forward to the review! :)
> 
> Thanks a lot for taking the time to look at this patch set.

Sure, this is a very useful thing.

Even at the most cynical possible position (which isn't where I am),
this means additional interface testing using a completely separate
codebase.

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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Leif Lindholm]

On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
> This is my Christmas present for my openSUSE friends :).
> 
> U-Boot is a great project for embedded devices. However, convincing
> everyone involved that only for "a few oddball ARM devices" we need to
> support different configuration formats from grub2 when all other platforms
> (PPC, System Z, x86) are standardized on a single format is a nightmare.
> 
> So we started to explore alternatives. At first, people tried to get
> grub2 running using the u-boot api interface. However, FWIW that one
> doesn't support relocations, so you need to know where to link grub2 to
> at compile time. It also seems to be broken more often than not. And on
> top of it all, it's a one-off interface, so yet another thing to maintain.
> 
> That led to a nifty idea. What if we can just implement the EFI application
> protocol on top of U-Boot? Then we could compile a single grub2 binary for
> uEFI based systems and U-Boot based systems and as soon as that one's loaded,
> everything looks and feels (almost) the same.
> 
> This patch set is the result of pursuing this endeavor.

Thanks, this is a very cool thing.
I meant to reply sooner, but Christmas got in the way.

>   - I am successfully able to run grub2 and Linux EFI binaries with this code.
>   - When enabled, the resulting U-Boot binary only grows by ~10kb,
> so it's very light weight.
>   - It works on 32bit ARM and AArch64. 
>   - All storage devices are directly accessible
>   - No runtime services (all calls return unimplemented)

Yeah, this is a bit of a pain point. The time services, virtual memory
services and reset being the key ones.

>   - No EFI variables

This would obviously (from my point of view) be desirable, but at
least initially, we can do most things without persistent variables.

> Of course, there are still a few things one could do on top:
> 
>   - Implement removable media booting (search for /efi/boot/boota{a64,rm}.efi)

Yeah, that would be top of my wishlist.

>   - Improve disk media detection (don't scan, use what information we have)
>   - Add EFI variable support using NVRAM
>   - Add GFX support

GFX support was actually never implemented for U-Boot GRUB, so from
this p.o.v. it is not a shortcoming over the existing impementation.

>   - Make EFI Shell work ;)

- Network device support.

I also spotted a couple of minor things while playing around (things
like image exit being missing), but these will be easy to flush out.


I'll leave reviewing of the u-boot side of things to people who know
the codebase better, and restrict myself to commenting on the
UEFIness.

/
Leif

> But so far, I'm very happy with the state of the patches. They completely
> eliminate potential arguments against U-Boot internally and give users the
> chance to run with the same level of comfort on all firmware types.
> 
> 
> Alex
> 
> Alexander Graf (9):
>   disk/part.c: Expose a list of available block drivers
>   include/efi_api.h: Add more detailed API definitions
>   efi_loader: Add PE image loader
>   efi_loader: Add boot time services
>   efi_loader: Add console interface
>   efi_loader: Add runtime services
>   efi_loader: Add disk interfaces
>   efi_loader: Add "bootefi" command
>   efi_loader: hook up in build environment
> 
>  arch/arm/cpu/armv8/u-boot.lds |   8 +
>  arch/arm/cpu/u-boot.lds   |  13 +
>  arch/arm/lib/sections.c   |   2 +
>  common/Makefile   |   1 +
>  common/cmd_bootefi.c  | 168 
>  disk/part.c   |  25 ++
>  include/efi_api.h | 197 +++--
>  include/efi_loader.h  |  87 
>  include/part.h|   2 +
>  include/pe.h  | 277 +
>  lib/Kconfig   |   1 +
>  lib/Makefile  |   1 +
>  lib/efi_loader/Kconfig|   8 +
>  lib/efi_loader/Makefile   |  11 +
>  lib/efi_loader/efi_boottime.c | 838 
> ++
>  lib/efi_loader/efi_console.c  | 371 +
>  lib/efi_loader/efi_disk.c | 227 +++
>  lib/efi_loader/efi_image_loader.c | 203 +
>  lib/efi_loader/efi_runtime.c  |  59 +++
>  19 files changed, 2462 insertions(+), 37 deletions(-)
>  create mode 100644 common/cmd_bootefi.c
>  create mode 100644 include/efi_loader.h
>  create mode 100644 include/pe.h
>  create mode 100644 lib/efi_loader/Kconfig
>  create mode 100644 lib/efi_loader/Makefile
>  create mode 100644 lib/efi_loader/efi_boottime.c
>  create mode 100644 lib/efi_loader/efi_console.c
>  create mode 100644 lib/efi_loader/efi_disk.c
>  create mode 100644 lib/efi_loader/efi_image_loader.c
>  create mode 100644 lib/efi_loader/efi_runtime.c
> 
> -- 
> 2.1.4
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Alexander Graf]

On 26.12.15 16:31, Leif Lindholm wrote:
> On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
>> This is my Christmas present for my openSUSE friends :).
>>
>> U-Boot is a great project for embedded devices. However, convincing
>> everyone involved that only for "a few oddball ARM devices" we need to
>> support different configuration formats from grub2 when all other platforms
>> (PPC, System Z, x86) are standardized on a single format is a nightmare.
>>
>> So we started to explore alternatives. At first, people tried to get
>> grub2 running using the u-boot api interface. However, FWIW that one
>> doesn't support relocations, so you need to know where to link grub2 to
>> at compile time. It also seems to be broken more often than not. And on
>> top of it all, it's a one-off interface, so yet another thing to maintain.
>>
>> That led to a nifty idea. What if we can just implement the EFI application
>> protocol on top of U-Boot? Then we could compile a single grub2 binary for
>> uEFI based systems and U-Boot based systems and as soon as that one's loaded,
>> everything looks and feels (almost) the same.
>>
>> This patch set is the result of pursuing this endeavor.
> 
> Thanks, this is a very cool thing.
> I meant to reply sooner, but Christmas got in the way.
> 
>>   - I am successfully able to run grub2 and Linux EFI binaries with this 
>> code.
>>   - When enabled, the resulting U-Boot binary only grows by ~10kb,
>> so it's very light weight.
>>   - It works on 32bit ARM and AArch64. 
>>   - All storage devices are directly accessible
>>   - No runtime services (all calls return unimplemented)
> 
> Yeah, this is a bit of a pain point. The time services, virtual memory
> services and reset being the key ones.

I guess reset should be pretty well doable. What are virtual memory
services? The bits that translate RTS code to run in virtual address
space somewhere else?

> 
>>   - No EFI variables
> 
> This would obviously (from my point of view) be desirable, but at
> least initially, we can do most things without persistent variables.

Doing EFI variables before exiting boot services is easy - we could even
just map U-Boot variables to EFI variables. That could come in handy for
cases where you want U-Boot to tell you which board you're on so you can
refer to different dtb files in your grub.cfg (if you need to override
the dtb).

Making them persistent is another difficult question - U-Boot usually
splits "modify variable" from "store variable pool to nvram".

And the hardest part would obviously be to make all of this work while
Linux is running ;). I'd definitely prefer to defer that bit to later.

> 
>> Of course, there are still a few things one could do on top:
>>
>>   - Implement removable media booting (search for 
>> /efi/boot/boota{a64,rm}.efi)
> 
> Yeah, that would be top of my wishlist.

That should be pretty simple to do - maybe we can even get away without
any C code for it.

> 
>>   - Improve disk media detection (don't scan, use what information we have)
>>   - Add EFI variable support using NVRAM
>>   - Add GFX support
> 
> GFX support was actually never implemented for U-Boot GRUB, so from
> this p.o.v. it is not a shortcoming over the existing impementation.

Heh ;). My goal here really is to make U-Boot based systems be en par
with TianoCore based ones in terms of usability.

> 
>>   - Make EFI Shell work ;)
> 
> - Network device support.

Oh, good point. I forgot about that one.

> I also spotted a couple of minor things while playing around (things
> like image exit being missing), but these will be easy to flush out.

Awesome, looking forward to the review! :)

Thanks a lot for taking the time to look at this patch set.


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Matwey V. Kornilov]

2015-12-25 19:50 GMT+03:00 Tom Rini :
> On Fri, Dec 25, 2015 at 09:53:22AM +0100, Alexander Graf wrote:
>>
>>
>> On 25.12.15 04:29, Tom Rini wrote:
>> > On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
>> >
>> >> This is my Christmas present for my openSUSE friends :).
>> >>
>> >> U-Boot is a great project for embedded devices. However, convincing
>> >> everyone involved that only for "a few oddball ARM devices" we need to
>> >> support different configuration formats from grub2 when all other 
>> >> platforms
>> >> (PPC, System Z, x86) are standardized on a single format is a nightmare.
>> >>
>> >> So we started to explore alternatives. At first, people tried to get
>> >> grub2 running using the u-boot api interface. However, FWIW that one
>> >> doesn't support relocations, so you need to know where to link grub2 to
>> >> at compile time. It also seems to be broken more often than not. And on
>> >> top of it all, it's a one-off interface, so yet another thing to maintain.
>> >>
>> >> That led to a nifty idea. What if we can just implement the EFI 
>> >> application
>> >> protocol on top of U-Boot? Then we could compile a single grub2 binary for
>> >> uEFI based systems and U-Boot based systems and as soon as that one's 
>> >> loaded,
>> >> everything looks and feels (almost) the same.
>> >>
>> >> This patch set is the result of pursuing this endeavor.
>> >
>> > So, I owe the whole codebase a real review.  My very quick question
>> > however is, aside from what you had to borrow from wine, can you license
>> > everything else as GPL v2 or later rather than LGPL?
>>
>> I'm personally a pretty big fan of the LGPL, since it's a very
>> reasonable compromise between closed and open source IMHO ;).
>>
>> Is there a particular reason you're asking for this? LGPL code is fully
>> compatible with GPL code and the resulting binary would be GPL anyway
>> because FWIW you can't compile U-Boot without GPL code inside.
>
> The general rules for U-Boot code are to be GPL v2 or later.  U-Boot is
> (and always will be) a GPL v2 only project as there's simply too much
> Linux kernel code that we want to leverage.  We do make special
> exceptions at times for very good reasons (like include/android_image.h
> is the authorative BSD-2 clause copy of that information) and I've even
> told some companies that for crypto-auth-sensitive stuff they can do GPL
> v2 only in their submission (again, due to U-Boot always being a v2 only
> project).
>
> So, I'm not gonig to reject the EFI loader code if you say no, you won't
> re-license it as GPL v2 (or v2 and later) but I'd really appreciate it.
> Thanks!

If EFI loader is GPLed, then is it possible to use it to run non-GPLed
(proprietary) EFI applications?

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Fri, Dec 25, 2015 at 09:53:22AM +0100, Alexander Graf wrote:
> 
> 
> On 25.12.15 04:29, Tom Rini wrote:
> > On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
> > 
> >> This is my Christmas present for my openSUSE friends :).
> >>
> >> U-Boot is a great project for embedded devices. However, convincing
> >> everyone involved that only for "a few oddball ARM devices" we need to
> >> support different configuration formats from grub2 when all other platforms
> >> (PPC, System Z, x86) are standardized on a single format is a nightmare.
> >>
> >> So we started to explore alternatives. At first, people tried to get
> >> grub2 running using the u-boot api interface. However, FWIW that one
> >> doesn't support relocations, so you need to know where to link grub2 to
> >> at compile time. It also seems to be broken more often than not. And on
> >> top of it all, it's a one-off interface, so yet another thing to maintain.
> >>
> >> That led to a nifty idea. What if we can just implement the EFI application
> >> protocol on top of U-Boot? Then we could compile a single grub2 binary for
> >> uEFI based systems and U-Boot based systems and as soon as that one's 
> >> loaded,
> >> everything looks and feels (almost) the same.
> >>
> >> This patch set is the result of pursuing this endeavor.
> > 
> > So, I owe the whole codebase a real review.  My very quick question
> > however is, aside from what you had to borrow from wine, can you license
> > everything else as GPL v2 or later rather than LGPL?
> 
> I'm personally a pretty big fan of the LGPL, since it's a very
> reasonable compromise between closed and open source IMHO ;).
> 
> Is there a particular reason you're asking for this? LGPL code is fully
> compatible with GPL code and the resulting binary would be GPL anyway
> because FWIW you can't compile U-Boot without GPL code inside.

The general rules for U-Boot code are to be GPL v2 or later.  U-Boot is
(and always will be) a GPL v2 only project as there's simply too much
Linux kernel code that we want to leverage.  We do make special
exceptions at times for very good reasons (like include/android_image.h
is the authorative BSD-2 clause copy of that information) and I've even
told some companies that for crypto-auth-sensitive stuff they can do GPL
v2 only in their submission (again, due to U-Boot always being a v2 only
project).

So, I'm not gonig to reject the EFI loader code if you say no, you won't
re-license it as GPL v2 (or v2 and later) but I'd really appreciate it.
Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Fri, Dec 25, 2015 at 07:53:24PM +0300, Matwey V. Kornilov wrote:
> 2015-12-25 19:50 GMT+03:00 Tom Rini :
> > On Fri, Dec 25, 2015 at 09:53:22AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 25.12.15 04:29, Tom Rini wrote:
> >> > On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
> >> >
> >> >> This is my Christmas present for my openSUSE friends :).
> >> >>
> >> >> U-Boot is a great project for embedded devices. However, convincing
> >> >> everyone involved that only for "a few oddball ARM devices" we need to
> >> >> support different configuration formats from grub2 when all other 
> >> >> platforms
> >> >> (PPC, System Z, x86) are standardized on a single format is a nightmare.
> >> >>
> >> >> So we started to explore alternatives. At first, people tried to get
> >> >> grub2 running using the u-boot api interface. However, FWIW that one
> >> >> doesn't support relocations, so you need to know where to link grub2 to
> >> >> at compile time. It also seems to be broken more often than not. And on
> >> >> top of it all, it's a one-off interface, so yet another thing to 
> >> >> maintain.
> >> >>
> >> >> That led to a nifty idea. What if we can just implement the EFI 
> >> >> application
> >> >> protocol on top of U-Boot? Then we could compile a single grub2 binary 
> >> >> for
> >> >> uEFI based systems and U-Boot based systems and as soon as that one's 
> >> >> loaded,
> >> >> everything looks and feels (almost) the same.
> >> >>
> >> >> This patch set is the result of pursuing this endeavor.
> >> >
> >> > So, I owe the whole codebase a real review.  My very quick question
> >> > however is, aside from what you had to borrow from wine, can you license
> >> > everything else as GPL v2 or later rather than LGPL?
> >>
> >> I'm personally a pretty big fan of the LGPL, since it's a very
> >> reasonable compromise between closed and open source IMHO ;).
> >>
> >> Is there a particular reason you're asking for this? LGPL code is fully
> >> compatible with GPL code and the resulting binary would be GPL anyway
> >> because FWIW you can't compile U-Boot without GPL code inside.
> >
> > The general rules for U-Boot code are to be GPL v2 or later.  U-Boot is
> > (and always will be) a GPL v2 only project as there's simply too much
> > Linux kernel code that we want to leverage.  We do make special
> > exceptions at times for very good reasons (like include/android_image.h
> > is the authorative BSD-2 clause copy of that information) and I've even
> > told some companies that for crypto-auth-sensitive stuff they can do GPL
> > v2 only in their submission (again, due to U-Boot always being a v2 only
> > project).
> >
> > So, I'm not gonig to reject the EFI loader code if you say no, you won't
> > re-license it as GPL v2 (or v2 and later) but I'd really appreciate it.
> > Thanks!
> 
> If EFI loader is GPLed, then is it possible to use it to run non-GPLed
> (proprietary) EFI applications?

Yes.  Absolutely.  We've (pratically) always supported running non-GPL
payloads.  VxWorks has been supported for ages and ages and ages for
example.  There may be a thought experiment or two required about
callbacks but that's part of why we've had CONFIG_API, iirc.

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Blibbet]

On 12/22/2015 05:57 AM, Alexander Graf wrote:
> This is my Christmas present for my openSUSE friends :).
>
> U-Boot is a great project for embedded devices. However, convincing
> everyone involved that only for "a few oddball ARM devices" we need to
> support different configuration formats from grub2 when all other
platforms
> (PPC, System Z, x86) are standardized on a single format is a nightmare.

This is a very exciting patch!

The potential to one day run CHIPSEC on U-Boot systems is VERY EXCITING!
https://github.com/chipsec/chipsec
CHIPSEC is a UEFI-centric. Though I've heard someone got it to work on
coreboot-based Intel-based Android system, not sure how.

After UEFI Shell works, I hope a goal is to get UEFI port of CPython
2.7x working, and Intel CHIPSEC running. CHIPSEC is a hardware/firmware
vulnerability detection tool, GPL open source. As I've heard them say,
the Intel CHIPSEC team is open to patches from all architectures for all
firmware targets, not just Intel x86/x64.

Linaro has started to investigate port of CHIPSEC from x86/x64 to
AArch64, as part of port of LUV (Linux UEFI Validation) project. Once
CPython and CHIPSEC run on U-Boot, this enables a whole new level of
hardware/firmware security detection! Once ported to AArch64, the ARM
security teams needs to add some AArch64-centric security test modules
to CHIPSEC, as it'll do little good on ARM, except for a few portable
UEFI variable and SPI tests, otherwise.
https://wiki.linaro.org/LEG/Engineering/luvOS
Hopefully ARM can fund Linaro to also port LUV/CHIPSEC to AArch32, all
of their products need hardware/firmware vulnerability detection
software, not just the latest 64-bit ones.

For U-Boot on MIPS, there is an unofficial UEFI MIPS port, but nobody
has touched it in a while, and CHIPSEC hasn't yet been ported there.
https://github.com/kontais/EFI-MIPS

I didn't think U-Boot ran on OpenPOWER, if it does, I missed that,
sorry. If so, there are two ports of UEFI to OpenPOWER by different
developers at IBM, but (AFAIK) no official OpenPOWER interest in UEFI,
and no CHIPSEC port to OpenPOWER yet. And no OpenPOWER-centric security
modules.
http://firmwaresecurity.com/2015/10/12/tianocore-for-openpower/
http://firmwaresecurity.com/2015/10/12/second-port-of-tianocore-to-openpower/

For other architectures that U-Boot runs on, I'm afraid porting UEFI
will be necessary before CHIPSEC can be attempted. :-( Is there any
marketshare data that shows which architectures coverage by U-Boot?

Dumb question: it appears Intel is not involved in U-Boot's x86/x64
port, or maybe I've just missed their involvement. I see Intel very
involved with coreboot and UEFI, but not U-Boot, even though U-Boot is
targetting Intel platforms. Can someone explain that to me? :-)

Thanks,
Lee Fisher
RSS: http://firmwaresecurity.com/feed

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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Alexander Graf]

On 25.12.15 04:29, Tom Rini wrote:
> On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:
> 
>> This is my Christmas present for my openSUSE friends :).
>>
>> U-Boot is a great project for embedded devices. However, convincing
>> everyone involved that only for "a few oddball ARM devices" we need to
>> support different configuration formats from grub2 when all other platforms
>> (PPC, System Z, x86) are standardized on a single format is a nightmare.
>>
>> So we started to explore alternatives. At first, people tried to get
>> grub2 running using the u-boot api interface. However, FWIW that one
>> doesn't support relocations, so you need to know where to link grub2 to
>> at compile time. It also seems to be broken more often than not. And on
>> top of it all, it's a one-off interface, so yet another thing to maintain.
>>
>> That led to a nifty idea. What if we can just implement the EFI application
>> protocol on top of U-Boot? Then we could compile a single grub2 binary for
>> uEFI based systems and U-Boot based systems and as soon as that one's loaded,
>> everything looks and feels (almost) the same.
>>
>> This patch set is the result of pursuing this endeavor.
> 
> So, I owe the whole codebase a real review.  My very quick question
> however is, aside from what you had to borrow from wine, can you license
> everything else as GPL v2 or later rather than LGPL?

I'm personally a pretty big fan of the LGPL, since it's a very
reasonable compromise between closed and open source IMHO ;).

Is there a particular reason you're asking for this? LGPL code is fully
compatible with GPL code and the resulting binary would be GPL anyway
because FWIW you can't compile U-Boot without GPL code inside.


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Tom Rini]

On Tue, Dec 22, 2015 at 02:57:47PM +0100, Alexander Graf wrote:

> This is my Christmas present for my openSUSE friends :).
> 
> U-Boot is a great project for embedded devices. However, convincing
> everyone involved that only for "a few oddball ARM devices" we need to
> support different configuration formats from grub2 when all other platforms
> (PPC, System Z, x86) are standardized on a single format is a nightmare.
> 
> So we started to explore alternatives. At first, people tried to get
> grub2 running using the u-boot api interface. However, FWIW that one
> doesn't support relocations, so you need to know where to link grub2 to
> at compile time. It also seems to be broken more often than not. And on
> top of it all, it's a one-off interface, so yet another thing to maintain.
> 
> That led to a nifty idea. What if we can just implement the EFI application
> protocol on top of U-Boot? Then we could compile a single grub2 binary for
> uEFI based systems and U-Boot based systems and as soon as that one's loaded,
> everything looks and feels (almost) the same.
> 
> This patch set is the result of pursuing this endeavor.

So, I owe the whole codebase a real review.  My very quick question
however is, aside from what you had to borrow from wine, can you license
everything else as GPL v2 or later rather than LGPL?

-- 
Tom


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

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Matwey V. Kornilov]

2015-12-22 16:57 GMT+03:00 Alexander Graf :
> This is my Christmas present for my openSUSE friends :).
>

Santa, do you have u-boot rpm packed with the patches to test?

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/9] EFI payload / application support

[Alexander Graf]

On 22.12.15 19:28, Matwey V. Kornilov wrote:
> 2015-12-22 16:57 GMT+03:00 Alexander Graf :
>> This is my Christmas present for my openSUSE friends :).
>>
> 
> Santa, do you have u-boot rpm packed with the patches to test?

Once OBS has finished compiling, they should be available here:

  https://build.opensuse.org/project/show/home:algraf:branches:Base:System

If you also want a 32bit ARM grub2 binary, check out

  https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:HIP04D01


Merry Christmas ;)

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