Submitter | Stefan Reinauer |
---|---|
Date | 2010-06-09 07:45:28 |
Message ID | <4C0F4698.6000405@coresystems.de> |
Download | mbox | patch |
Permalink | /patch/1491/ |
State | Not Applicable |
Headers | show |
Comments
On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer <stefan.reinauer@coresystems.de> wrote: > SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks > This is awsome! Acked-by: Joseph Smith <joe@settoplinux.org> Any chance for a SMI Handler for SeaBIOS coming up?
On 6/9/10 7:54 PM, Joseph Smith wrote: > On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer > <stefan.reinauer@coresystems.de> wrote: > >> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks >> >> > This is awsome! > Acked-by: Joseph Smith <joe@settoplinux.org> > > Any chance for a SMI Handler for SeaBIOS coming up? > > No... What would that be good for?
On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer
<stefan.reinauer@coresystems.de> wrote:
> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
It seems surprising to want to make SeaBIOS have this much stuff
that's board-specific. It seems like a more generic way to set hooks
from CBFS would be nice.
I'm thinking something like seabios/hooks which has a list of
interrupts handlers and where they should be installed.
Thanks,
Myles
On Wed, 9 Jun 2010 12:00:41 -0600, Myles Watson <mylesgw@gmail.com> wrote: > On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer > <stefan.reinauer@coresystems.de> wrote: >> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks > > It seems surprising to want to make SeaBIOS have this much stuff > that's board-specific. It seems like a more generic way to set hooks > from CBFS would be nice. > > I'm thinking something like seabios/hooks which has a list of > interrupts handlers and where they should be installed. > True, probibly could be more generic, just about any Intel vbios is going to have the potential of INT15 5F hooks enabled. But I think we should get this in for now, and genericize it in the future as more things get added.
On Wed, 09 Jun 2010 19:55:36 +0200, Stefan Reinauer <stefan.reinauer@coresystems.de> wrote: > On 6/9/10 7:54 PM, Joseph Smith wrote: >> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer >> <stefan.reinauer@coresystems.de> wrote: >> >>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks >>> >>> >> This is awsome! >> Acked-by: Joseph Smith <joe@settoplinux.org> >> >> Any chance for a SMI Handler for SeaBIOS coming up? >> >> > No... What would that be good for? Uh, MBI?
On 6/9/10 8:00 PM, Myles Watson wrote: > On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer > <stefan.reinauer@coresystems.de> wrote: > >> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks >> > It seems surprising to want to make SeaBIOS have this much stuff > that's board-specific. int15 hooks are designed to be board specific. > It seems like a more generic way to set hooks > from CBFS would be nice. > Loading an int handler dynamically from CBFS and linking it at runtime? Sounds doable but complex. As long as it's only 2 intel and a number of VIA based boards that require a special int15 handler it might not be that bad. Generally it's also possible to locally patch the SeaBIOS source code. The runtime distinction is only required if you want to use the same SeaBIOS binary on several mainboards that require to have different int15 handlers. > I'm thinking something like seabios/hooks which has a list of > interrupts handlers and where they should be installed. > It would need to be 0xe0000 - 0xfffff unless we want to start cutting out more memory. Alternatively we could add an SMI "function call" to coreboot that does the deed. That would simplify the code in SeaBIOS significantly but add more requirements for SMM. Stefan
On 6/9/10 8:11 PM, Joseph Smith wrote: > > > On Wed, 09 Jun 2010 19:55:36 +0200, Stefan Reinauer > <stefan.reinauer@coresystems.de> wrote: > >> On 6/9/10 7:54 PM, Joseph Smith wrote: >> >>> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer >>> <stefan.reinauer@coresystems.de> wrote: >>> >>> >>>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks >>>> >>>> >>>> >>> This is awsome! >>> Acked-by: Joseph Smith <joe@settoplinux.org> >>> >>> Any chance for a SMI Handler for SeaBIOS coming up? >>> >>> >>> >> No... What would that be good for? >> > Uh, MBI? > The coreboot SMI handler already implements that. Remember SMI handlers stay active even when the OS is loaded. For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux kernel module or root process) couldn't just install a new handler. When experimenting that lock can of course be disabled in the coreboot source.
On Wed, Jun 9, 2010 at 12:34 PM, Stefan Reinauer <stefan.reinauer@coresystems.de> wrote: > On 6/9/10 8:00 PM, Myles Watson wrote: >> On Wed, Jun 9, 2010 at 1:45 AM, Stefan Reinauer >> <stefan.reinauer@coresystems.de> wrote: >> >>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks >>> >> It seems surprising to want to make SeaBIOS have this much stuff >> that's board-specific. > int15 hooks are designed to be board specific. > >> It seems like a more generic way to set hooks >> from CBFS would be nice. >> > Loading an int handler dynamically from CBFS and linking it at runtime? > Sounds doable but complex. It may not be worth the trouble. > As long as it's only 2 intel and a number of VIA based boards that > require a special int15 handler it might not be that bad. > > Generally it's also possible to locally patch the SeaBIOS source code. Sure. Harder for end users, but just as easy for developers. > The runtime distinction is only required if you want to use the same > SeaBIOS binary on several mainboards that require to have different > int15 handlers. > >> I'm thinking something like seabios/hooks which has a list of >> interrupts handlers and where they should be installed. >> > It would need to be 0xe0000 - 0xfffff unless we want to start cutting > out more memory. I meant where as in what interrupt to patch, not what address to run at. SeaBIOS should be able to use whatever address it wants to. > Alternatively we could add an SMI "function call" to coreboot that does > the deed. That would simplify the code in SeaBIOS significantly but add > more requirements for SMM. I'm not sure what's best. Maybe few enough boards will need their own handlers that it doesn't really matter. Thanks, Myles
On 6/9/10 8:48 PM, Myles Watson wrote: >> > It would need to be 0xe0000 - 0xfffff unless we want to start cutting >> > out more memory. >> > I meant where as in what interrupt to patch, not what address to run > at. SeaBIOS should be able to use whatever address it wants to. > If it contains a dynamic linker, or the code is position independent, yes. >> > Alternatively we could add an SMI "function call" to coreboot that does >> > the deed. That would simplify the code in SeaBIOS significantly but add >> > more requirements for SMM. >> > I'm not sure what's best. Maybe few enough boards will need their own > handlers that it doesn't really matter. > Kevin, any preference?
On 06/09/2010 02:38 PM, Stefan Reinauer wrote: > On 6/9/10 8:11 PM, Joseph Smith wrote: >> >> >> On Wed, 09 Jun 2010 19:55:36 +0200, Stefan Reinauer >> <stefan.reinauer@coresystems.de> wrote: >> >>> On 6/9/10 7:54 PM, Joseph Smith wrote: >>> >>>> On Wed, 09 Jun 2010 09:45:28 +0200, Stefan Reinauer >>>> <stefan.reinauer@coresystems.de> wrote: >>>> >>>> >>>>> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks >>>>> >>>>> >>>>> >>>> This is awsome! >>>> Acked-by: Joseph Smith<joe@settoplinux.org> >>>> >>>> Any chance for a SMI Handler for SeaBIOS coming up? >>>> >>>> >>>> >>> No... What would that be good for? >>> >> Uh, MBI? >> > The coreboot SMI handler already implements that. Remember SMI handlers > stay active even when the OS is loaded. > > For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux > kernel module or root process) couldn't just install a new handler. > When experimenting that lock can of course be disabled in the coreboot > source. > > Hmm, if the SMI handler is only implemented when using YABEL than how is one supposed to use SeaBIOS to load vga?
On 6/9/10 10:15 PM, Joseph Smith wrote: >> The coreboot SMI handler already implements that. Remember SMI handlers >> stay active even when the OS is loaded. >> >> For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux >> kernel module or root process) couldn't just install a new handler. >> When experimenting that lock can of course be disabled in the coreboot >> source. >> >> > Hmm, if the SMI handler is only implemented when using YABEL than how > is one supposed to use SeaBIOS to load vga? The i82830 SMI handler is implemented and enabled completely independent of any option rom initialization in coreboot itself. Stefan
On 06/09/2010 04:57 PM, Stefan Reinauer wrote: > On 6/9/10 10:15 PM, Joseph Smith wrote: >>> The coreboot SMI handler already implements that. Remember SMI handlers >>> stay active even when the OS is loaded. >>> >>> For security reasons coreboot even locks SMM so that SeaBIOS (or a Linux >>> kernel module or root process) couldn't just install a new handler. >>> When experimenting that lock can of course be disabled in the coreboot >>> source. >>> >>> >> Hmm, if the SMI handler is only implemented when using YABEL than how >> is one supposed to use SeaBIOS to load vga? > > The i82830 SMI handler is implemented and enabled completely independent > of any option rom initialization in coreboot itself. > Ok cool. Then I guess SeaBIOS just needs to be able to load vga bios and mbi rom. Correct?
On 6/9/10 11:03 PM, Joseph Smith wrote: >> > Ok cool. Then I guess SeaBIOS just needs to be able to load vga bios > and mbi rom. Correct? Not even that complicated. mbi is loaded by coreboot, so SeaBIOS has everything it needs. It might at some point need a mainboard specific int15 handler, if that is how you implement TV-out enable. Stefan
On Wed, Jun 09, 2010 at 09:26:20PM +0200, Stefan Reinauer wrote: > On 6/9/10 8:48 PM, Myles Watson wrote: > >> > It would need to be 0xe0000 - 0xfffff unless we want to start cutting > >> > out more memory. > >> > > I meant where as in what interrupt to patch, not what address to run > > at. SeaBIOS should be able to use whatever address it wants to. > > > If it contains a dynamic linker, or the code is position independent, yes. > > >> > Alternatively we could add an SMI "function call" to coreboot that does > >> > the deed. That would simplify the code in SeaBIOS significantly but add > >> > more requirements for SMM. > >> > > I'm not sure what's best. Maybe few enough boards will need their own > > handlers that it doesn't really matter. > > > Kevin, any preference? I think vgahooks.c is simple enough that extending it for the handful of boards that need it is okay. If it becomes too unwieldy, then I'm sure we can come up with a new system at that time. If an alternate solution is needed, I'd guess it would be simplest to deploy an option rom that hooked 155f. Writing an option rom that hooks 155f is straight forward. However, there would be some complexity in deployment because the option rom would need to run before the vga bios and it would need to be loaded to an address other than 0xc0000. (Normally the vgabios is the first option rom to be executed, and option roms are normally loaded in ascending order starting at 0xc0000.) So, I'd say it is definitely possible, but probably not worth it right now. -Kevin
On Wed, Jun 09, 2010 at 09:45:28AM +0200, Stefan Reinauer wrote:
> SeaBIOS VGA hooks for Getac P470 and Roda RK886EX notebooks
Thanks. Commit 8cb8ba52.
-Kevin
Patch
--- src/vgahooks.c +++ src/vgahooks.c @@ -17,6 +17,23 @@ // Coreboot board detected. int CBmainboard VAR16VISIBLE; +#define MAINBOARD_DEFAULT 0 +#define KONTRON_986LCD_M 1 +#define GETAC_P470 2 +#define RODA_RK886EX 3 + +struct mainboards { + char *vendor; + char *device; + int type; +}; + +struct mainboards mainboard_list[] = { + { "KONTRON", "986LCD-M", KONTRON_986LCD_M }, + { "GETAC", "P470", GETAC_P470 }, + { "RODA", "RK886EX", RODA_RK886EX }, +}; + static void handle_155fXX(struct bregs *regs) { @@ -154,7 +171,90 @@ } } +/**************************************************************** + * Intel VGA hooks + ****************************************************************/ +#define BOOT_DISPLAY_DEFAULT (0) +#define BOOT_DISPLAY_CRT (1 << 0) +#define BOOT_DISPLAY_TV (1 << 1) +#define BOOT_DISPLAY_EFP (1 << 2) +#define BOOT_DISPLAY_LCD (1 << 3) +#define BOOT_DISPLAY_CRT2 (1 << 4) +#define BOOT_DISPLAY_TV2 (1 << 5) +#define BOOT_DISPLAY_EFP2 (1 << 6) +#define BOOT_DISPLAY_LCD2 (1 << 7) + +static void +roda_155f35(struct bregs *regs) +{ + regs->ax = 0x005f; + // regs->cl = BOOT_DISPLAY_DEFAULT; + regs->cl = BOOT_DISPLAY_LCD; + set_success(regs); +} +static void +roda_155f40(struct bregs *regs) +{ + u8 display_id; + //display_id = inb(0x60f) & 0x0f; // Correct according to Crete + display_id = 3; // Correct according to empirical studies + + regs->ax = 0x005f; + regs->cl = display_id; + set_success(regs); +} + +static void +roda_155f(struct bregs *regs) +{ + dprintf(1, "Executing RODA specific interrupt %02x.\n", regs->al); + switch (regs->al) { + case 0x35: roda_155f35(regs); break; + case 0x40: roda_155f40(regs); break; + default: handle_155fXX(regs); break; + } +} + +static void +kontron_155f35(struct bregs *regs) +{ + regs->ax = 0x005f; + regs->cl = BOOT_DISPLAY_CRT; + set_success(regs); +} + +static void +kontron_155f40(struct bregs *regs) +{ + u8 display_id; + display_id = 3; + + regs->ax = 0x005f; + regs->cl = display_id; + set_success(regs); +} + +static void +kontron_155f(struct bregs *regs) +{ + dprintf(1, "Executing Kontron specific interrupt %02x.\n", regs->al); + switch (regs->al) { + case 0x35: kontron_155f35(regs); break; + case 0x40: kontron_155f40(regs); break; + default: handle_155fXX(regs); break; + } +} + +static void +getac_155f(struct bregs *regs) +{ + dprintf(1, "Executing Getac specific interrupt %02x.\n", regs->al); + switch (regs->al) { + default: handle_155fXX(regs); break; + } +} + /**************************************************************** * Entry and setup ****************************************************************/ @@ -163,19 +263,33 @@ void handle_155f(struct bregs *regs) { + int bdf, cbmb; + if (! CONFIG_VGAHOOKS) goto fail; - // XXX - Use this value later. - //int cbmb = GET_GLOBAL(CBmainboard); + cbmb = GET_GLOBAL(CBmainboard); - int bdf = GET_GLOBAL(VGAbdf); - if (bdf < 0) - goto fail; - u16 vendor = pci_config_readw(bdf, PCI_VENDOR_ID); - if (vendor == PCI_VENDOR_ID_VIA) { - via_155f(regs); - return; + switch (cbmb) { + case KONTRON_986LCD_M: + kontron_155f(regs); + return; + case RODA_RK886EX: + roda_155f(regs); + return; + case GETAC_P470: + getac_155f(regs); + return; + case MAINBOARD_DEFAULT: + bdf = GET_GLOBAL(VGAbdf); + if (bdf < 0) + goto fail; + + u16 vendor = pci_config_readw(bdf, PCI_VENDOR_ID); + if (vendor == PCI_VENDOR_ID_VIA) { + via_155f(regs); + return; + } } fail: @@ -186,8 +300,18 @@ void vgahook_setup(const char *vendor, const char *part) { + int i; + if (! CONFIG_VGAHOOKS) return; - // XXX - add support later. + CBmainboard = 0; + for (i=0; i<(sizeof(mainboard_list) / sizeof(mainboard_list[0])); i++) { + if (!strcmp(vendor, mainboard_list[i].vendor) && + !strcmp(part, mainboard_list[i].device)) { + printf("Found mainboard %s %s\n", vendor, part); + CBmainboard = mainboard_list[i].type; + break; + } + } }