From: Michel Stam <michel@reverze.net>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: RFC: barebox-x86 as a coreboot payload
Date: Thu, 10 Apr 2014 13:30:32 +0200 [thread overview]
Message-ID: <534680D8.3040409@reverze.net> (raw)
In-Reply-To: <20140410055200.GJ27055@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 2618 bytes --]
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
>
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4278 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2014-04-10 11:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-05 19:00 Antony Pavlov
2014-04-05 19:02 ` Alexander Shiyan
2014-04-05 19:27 ` Alexander Aring
2021-04-01 13:52 ` Ahmad Fatoum
2021-04-02 5:23 ` Antony Pavlov
2014-04-08 6:48 ` Jean-Christophe PLAGNIOL-VILLARD
2014-04-08 21:45 ` Marc Kleine-Budde
2014-04-08 21:50 ` [PATCH] 2048: port to barebox Marc Kleine-Budde
2014-04-09 3:27 ` Alexander Aring
2014-04-09 7:20 ` RFC: barebox-x86 as a coreboot payload Sascha Hauer
2014-04-06 14:32 ` Michel Stam
2014-04-08 6:47 ` Jean-Christophe PLAGNIOL-VILLARD
2014-04-10 5:52 ` Sascha Hauer
2014-04-10 11:30 ` Michel Stam [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=534680D8.3040409@reverze.net \
--to=michel@reverze.net \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox