Dear Graeme Russ,
In message 4DC94CD4.2050904@gmail.com you wrote:
So coreboot and U-Boot are a good complement to each other so bringing U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the politics ;)
- The U-Boot source 'must' be self contained - No external libraries. Incorporating license compatible source is OK
The same is probably true for coreboot.
- coreboot payloads should be in ELF (linked to libpayload)
Is this really necessary, assuming we have a self-contained payload that does not request any services from the tool that was used to start it?
- How much of libpayload would we need to bring into U-Boot to provide bare minimal payload delivery? U-Boot already contains it's own minimal libc routines.
Right. See above - eventually such linking is not really necessary if the U-Boot ELF image is really self-contained.
- How do we get VGA and USB keyboard support working? Do other U-Boot boards implement console on anything other than serial?
Yes, we do support output on LCD and other video adapters, and we support input from USB keyboard (not to mentione netconsole, or netconsole over ethernet over USB and similar fancy stuff).
- Can we add relocation support to the coreboot ELF loader?
Do we have to?
- Does coreboot relocate into RAM? If so, what is the target address? What guarantee is there that the target address is valid?
Do we have to care? I would expect that we consider both coreboot and U-Boot as isolated entities, each performing it's own task. Coreboot will initialize the RAM and load and start U-Boot, similar to what a first stage loader does on systems that boot from NAND. Once U-Bootis running, it does so completely on its own.
- Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
Is there any need for this? Don't make things more complex than needed.
- Is it worth playing around with segment registers to 'relocate' U-Boot
That's a U-Boot question, right? Let's solve this independently.
- What hardware should be initialised in coreboot and what should be initialised in U-Boot? (political question ;)
No, that's a very practical; question. Coreboot should do as many of the x86 specific stuff as it can, and as it already does to load and start other payloads. And probably not more, at least not for now.
I think the best way to make this undertaking a success is to make it as unintrusive to both involved projects as possible.
I think a good start would be to create a new U-Boot target which includes a stripped down libpayload in the U-Boot source. This target can exclude
Why would we need that? I can understand that this may make initial porting and debugging easier ("early console output" etc.), but we should try to do without this.
We can start with U-Boot linked to a fixed location in RAM and skip relocations then work on either extending coreboot to perform relocation fixups or have U-Boot perform the fixups based on RAM information read from cbtable
I strongly recommend not to request changes to coreboot, and not to deviate from standard U-Boot methods.
We are not re-inventing the wheel here. We have many similar situations where some ROM boot loader or xload or nand_spl code or onenand_ipl code is loading an U-Boot image into a halfway initialized system, and U-Boot starts there. I see no need to make coreboot use a different method.
P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you are not on the coreboot ml, you emails will get bounced to a moderator :(
I hope he is tolerant enough...
Best regards,
Wolfgang Denk