RFC: barebox-x86 as a coreboot payload

[Michel Stam]

Hello Sascha,
> I think there is interest in EFI support. It's a good thing to implement
> a standard boot concept. It could be used on ARM aswell.
> The really bad thing about EFI is that it requires runtime services to
> access the EFI variables from the kernel. For this the kernel calls back
> into bootloader code. This concept stinks. The kernel should access the
> variables natively (With some data structure kernel and bootloader agree
> about). I recently heard someone going into that direction, just can't
> remember who it was.
I took a small look at it, apparently there's attempts at a gcc 
toolchain necessary for compiling this. And yes it has its own 
development environment.

http://wiki.osdev.org/UEFI
http://sourceforge.net/projects/gnu-efi/

I might get to that some day, its not on my immediate list as yet.

> I don't know either. Do you want to do framebuffer console support
> aswell? That might be difficult.
I was thinking using VESA VBE for this. Maybe looking at the linux 
kernel code may help here, as VESA VBE seems to have graphical/text 
modes, having a framebuffer driver on barebox/x86 would be nice.

This will be next after the keyboard driver.


Michel
On 04/10/2014 07:52 AM, Sascha Hauer wrote:
> On Sun, Apr 06, 2014 at 04:32:19PM +0200, Michel Stam wrote:
>> Hello Antony,
>>
>> Interesting idea- I wonder if its difficult given that U-boot is
>> already supported?
>>
>> Personally I have no experience with coreboot, the systems I test on
>> are industrial x86 SBCs with their own BIOS. I suppose it is oossible,
>> maybe we can borrow code from u-boot.
>>
>> Another thing along the sane lines that crossed my mind is EFI support
>> for barebox, I wonder if theres interest in that?
> I think there is interest in EFI support. It's a good thing to implement
> a standard boot concept. It could be used on ARM aswell.
> The really bad thing about EFI is that it requires runtime services to
> access the EFI variables from the kernel. For this the kernel calls back
> into bootloader code. This concept stinks. The kernel should access the
> variables natively (With some data structure kernel and bootloader agree
> about). I recently heard someone going into that direction, just can't
> remember who it was.
>
>> Next on my list is keyboard/VGA, maybe VESA support if I have the
>> time. I would like to see a console, possibly a framebuffer driver. No
>> idea how difficult that will be.
> I don't know either. Do you want to do framebuffer console support
> aswell? That might be difficult.
>
> Sascha
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20140410/b8458ae2/attachment-0001.p7s>