No subject

    Contributed code must be GPL'd (preferably 'GPLv2 or any later
    version', but 'GPLv2' is fine, too). At the very minimum the code
    must have a GPL-compatible license.

But yes, I image a lot of the code predates this preference, much like
a lot of U-Boot code does

>> Now the politics ;)
>> =A0- The U-Boot source 'must' be self contained - No external libraries.
>> =A0 =A0Incorporating license compatible source is OK
>
> Well ok.. (why though?)

Because that's the way Wolfgang likes it ;)

>> =A0- coreboot payloads should be in ELF (linked to libpayload)
>
> They do not neccessarily have to link to libpayload, but if they
> don't they have to replicate some of what libpayload does. That code
> duplication is pretty silly, so most payloads do use libpayload.

I think what will end up happening is porting enough of libpayload
across to U-Boot in order to get access to coreboot data structures.
Everything else either already exists in U-Boot (libc functionality) or
can be added using existing U-Boot architectural principals (USB keyboard,
VGA support etc)

>> =A0- There should be minimal intrusion into the core U-Boot build script=
s
>> =A0 =A0(Makefiles, mk.configs etc) - I would assume the same applies to
>> =A0 =A0coreboot build files as well. Hacking the U-Boot x86 specific bui=
ld
>> =A0 =A0files should be fine
>
> coreboot uses Kconfig for build time configuration and I think it
> would be no problem (maybe even desirable) to add a few special
> commands in order to grab a U-Boot from git, build it, and include it
> as payload in the output coreboot.rom. This is done for SeaBIOS
> already.

That's an issue for the coreboot team - sounds sensible enough

>> =A0- Everything should 'just work' with a recent GNU toolchain (gcc,
>> =A0 =A0binutils etc)
>
> coreboot has significant experiences from distribution toolchains
> being patched to the point where they are unable to correctly build
> coreboot itself and/or payloads. If the distribution toolchain works
> for you that's good, but most of the big name distributions have
> messed up their toolchains. The coreboot source includes a script to
> build known good versions of the toolchain, and the coreboot build
> system will automatically pick up such a toolchain if it is found
> during build.

I tend to use a pure breed toolchain (I build GCC and binutils from
scratch and don't use the disto's toolchain)

>> =A0- U-Boot relocates to 'Top of RAM' - This is a fundamental architectu=
ral
>> =A0 =A0design and not x86 specific. This feature should be retained for
>> =A0 =A0consistency with other U-Boot arches
>
> IMO this might be a little misguided. Retaining behavior, especially
> across architecture, shouldn't be an end in itself. If U-Boot was the
> primary bootloader in this situation it would matter less. In the
> context of coreboot however U-Boot would be much easier to integrate
> with if this policy was not enforced. Maybe U-Boot wants to stay
> resident however, then there's not much choice except top of memory.

As Wolfgang has commented on in another post in this thread, there are
some pretty solid reasons behind this rationale. These reasons may be
more applicable to ARM/PPC embedded environments and possibly irrelevant
in the x86/PC world. Although this 'feature' is currently implemented on a
per-CPU architecture basis, this may change in the future - It's worth
keeping in mind so nobody gets blindsided

>> =A0- Do we care about legacy BIOS support (SeaBIOS) for now (I think
>> =A0 =A0not)?
>
> IMO it is not relevant to the integration of coreboot and U-Boot. If
> a BIOS is needed by U-Boot itself or whatever it loads, then SeaBIOS
> must be used as payload for coreboot, and SeaBIOS will then start
> U-Boot after setting up the BIOS environment.

Or U-Boot could load a SeaBIOS image and initialise it if needed. So
in a U-Boot script:
  - If the target OS is GNU/Linux the load the Linux kernel image and go
  - If the target OS is Windows (or any other OS which needs a BIOS) then
    U-Boot first loads a SeaBIOS image and then loads the image for the
    target OS (this may even be a 'GRUB' image for example)

>> So, a few questions
>> =A0- How much of libpayload would we need to bring into U-Boot to provid=
e
>> =A0 =A0bare minimal payload delivery? U-Boot already contains it's own
>> =A0 =A0minimal libc routines.
>
> Not much at all. You basically just have to look up the coreboot
> table.

Thought so - So we just port this bit

>> =A0- How do we get VGA and USB keyboard support working?
>
> Write VGA and USB drivers. Or use the ones that are available in
> libpayload. Estimate 5-6 months of development effort to write from
> scratch. But you could also copy it all from libpayload of course.

U-Boot already has USB support framework - just a matter of writing device
drivers for the chipset hardware

>
> One thing to keep in mind here is that VGA will only be available if
> coreboot or SeaBIOS has set it up. coreboot only knows how to do this

Or if U-Boot does

> for two or three graphics chipsets. SeaBIOS can initialize any VGA
> option ROM, but then you need SeaBIOS in the loop.
> Option ROMs are ageold technology and stupid, but they are still
> firmly entrenched in PC hardware. A BIOS was always there so everyone
> assumes it will always stay there, not very many question if
> something better could be done.

Would be interesting to investigate implementing a stub in U-Boot to
initialise and use VGA option ROMs

>> =A0 =A0Do other U-Boot boards implement console on anything other than
>> =A0 =A0serial?
>
> U-Boot? Can't say.