[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Seeking permission to use GRUB derived code in GPLv2 software (U-Boo

From: Graeme Russ
Subject: Re: Seeking permission to use GRUB derived code in GPLv2 software (U-Boot)
Date: Fri, 11 Feb 2011 09:24:55 +1100

2011/2/11 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> On 02/10/2011 02:35 PM, Graeme Russ wrote:
>> Hello,
>> I am the current maintainer of the x86 port of U-Boot
>> ( I have done a lot of work getting
>> the x86 port up and running after a very long period of neglect and am now
>> getting stuck into some rather 'interesting' areas. One of which is the
>> Real/Protected mode switching.
>> I came across grub-core/kern/i386/realmode.S which has a really nice
>> Real/Protected mode switching code that fits my needs perfectly. Only
>> problem is, GRUB is GPLv3 and U-Boot is GPLv2 (most is GPLv2+). There are
>> plans to move U-Boot to GPLv3 so I have two options:
>> 1) Wait on (and work towards) U-Boot becoming GPLv3
>> 2) Humbly ask permission to use the core of the GRUB realmode.S
> <responding quickly>
> Such a permission can be only given by either FSF or by combined
> agreement of all involved authors.

I assumed that would be the case

> In this particular case you can grab r466 from GRUB bzr. It was before
> the migration to 3+. The relevant code is in startup.S. And once you
> migrate U-boot to 3(+) you ill be able to upgrade to current realmode.S
> if necessary.

OK, I'll look into that

> Also I would be interested in better U-Boot and GRUB2 integration on
> platforms supported by both (x86, ppc. Perhaps sparc64 too). As I
> understand U-Boot is a firmware, mostly for embedded devices. In
> particular I think 5 following goals should be reasonable:
> a) Load GRUB2 by U-Boot when GRUB is on HDD
> b) Flash U-Boot+GRUB2 together. Basically a variation on (a) with GRUB
> residing on flash.
> c) Load U-Boot from GRUB2 (I suppose you can make a test version of
> U-boot loadable from disk)
> d) support U-Boot protocols in GRUB2, meaning loading the kernels
> loadable by U-Boot
> e) Look into possibilities of multiboot2, especially adding tags for
> info currently absent from it and allow in this way to reduce number of
> booting formats present around.
> So how would you recommend to proceed and which system would you
> consider as typical for U-Boot? Beagleboard?
> Thanks in advance.

For x86, there is already Coreboot which I assume can load GRUB

a) would be fairly easy - U-Boot already has read-only support for a number
of filesystems, so I would assume it would be fairly trivial to have U-Boot
load GRUB from a filesystem (either in Flash, HDD or even USB)

b) As you say, similar to a) but have GRUB as a raw image in Flash

Note: For both a) and b), GRUB could be compressed to save space (U-Boot
has a compressed image format)

c) I've already thought of this as a way to enabled testing U-Boot on
boards which have a BIOS you want to replace before you burn a permanent
U-Boot onto the boards BIOS chip

d) Not sure what you mean

e) Not familiat with Multiboot2

Two more:

f) Merge GRUB's 'jump straight into Linux kernel's protected mode entry
point' into U-Boot (U-Boot currently does a pointless switch back into
real mode for the kernel's decompression stub to do its work)

g) Have U-Boot setup a data structure representing the hardware (Device
Tree?) and pass this to GRUB - Removes the requirement for GRUB to probe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]