This patch cleans up the option rom code in coreboot significantly by dropping all extra copies of vgabios.c and instead changing the code to use oprom/x86.c with custom per-board int15 handlers.
Corey, I can't test this on cn400/cn700 ... Can you? The code should go in as is, but it might require some extra fixing, as (like with vgabios.c before) the int15 handlers are all copies of the age-old epia-m code. (except vx800)
Stefan
Sorry, my cn700 system died, and I've been too busy with other projects to replace it. I haven't been following the list for a while, so I don't know what the current state of vga bios loaders can do, and when I do get back to working on my carpc, I'll most likely be working on an intel board, thanks to all the support via has given me in the past.
On Fri, Apr 23, 2010 at 5:01 PM, Stefan Reinauer stepan@coresystems.de wrote:
This patch cleans up the option rom code in coreboot significantly by dropping all extra copies of vgabios.c and instead changing the code to use oprom/x86.c with custom per-board int15 handlers.
Corey, I can't test this on cn400/cn700 ... Can you? The code should go in as is, but it might require some extra fixing, as (like with vgabios.c before) the int15 handlers are all copies of the age-old epia-m code. (except vx800)
Stefan
On Fri, Apr 23, 2010 at 11:01:34PM +0200, Stefan Reinauer wrote:
This patch cleans up the option rom code in coreboot significantly by dropping all extra copies of vgabios.c and instead changing the code to use oprom/x86.c with custom per-board int15 handlers.
Corey, I can't test this on cn400/cn700 ... Can you? The code should go in as is, but it might require some extra fixing, as (like with vgabios.c before) the int15 handlers are all copies of the age-old epia-m code. (except vx800)
Nice!
If I don't enable CONFIG_VGA_ROM_RUN I get:
build/coreboot_ram.o: In function `vga_init': vga.c:(.text+0x178d): undefined reference to `mainboard_interrupt_handlers'
If I do enable that option it will compile. I tested it on a flash image that did not contain a valid vga rom in cbfs - it did boot, but took much longer:
00.497: Stage: loading fallback/coreboot_ram @ 0x100000 (180224 bytes), entry @ 0x100000 01.619: coreboot-4.0-r5486M Sat Apr 24 11:13:13 EDT 2010 booting...
vs:
00.501: Stage: loading fallback/coreboot_ram @ 0x4000 (163840 bytes), entry @ 0x4000 00.547: coreboot-4.0-r5486M Sat Apr 24 10:45:34 EDT 2010 rebooting...
I'm not sure if the delay is because RAMBASE moved or because of something related to the vga code.
It's been a while since I've used coreboot's vga init code - what's the best way to test that - filo?
-Kevin
On 4/24/10 5:28 PM, Kevin O'Connor wrote:
On Fri, Apr 23, 2010 at 11:01:34PM +0200, Stefan Reinauer wrote:
This patch cleans up the option rom code in coreboot significantly by dropping all extra copies of vgabios.c and instead changing the code to use oprom/x86.c with custom per-board int15 handlers.
Corey, I can't test this on cn400/cn700 ... Can you? The code should go in as is, but it might require some extra fixing, as (like with vgabios.c before) the int15 handlers are all copies of the age-old epia-m code. (except vx800)
Nice!
If I don't enable CONFIG_VGA_ROM_RUN I get:
build/coreboot_ram.o: In function `vga_init': vga.c:(.text+0x178d): undefined reference to `mainboard_interrupt_handlers'
If I do enable that option it will compile. I tested it on a flash image that did not contain a valid vga rom in cbfs - it did boot, but took much longer:
00.497: Stage: loading fallback/coreboot_ram @ 0x100000 (180224 bytes), entry @ 0x100000 01.619: coreboot-4.0-r5486M Sat Apr 24 11:13:13 EDT 2010 booting...
vs:
00.501: Stage: loading fallback/coreboot_ram @ 0x4000 (163840 bytes), entry @ 0x4000 00.547: coreboot-4.0-r5486M Sat Apr 24 10:45:34 EDT 2010 rebooting...
I'm not sure if the delay is because RAMBASE moved or because of something related to the vga code.
Oh, can you just add the rambase at 0x4000 again and try that? This sounds like a caching issue and it should be investigated (we have such issues on AMD platforms, too) And tripling boot time is definitely a regression we need to fight as it comes :-)
It's been a while since I've used coreboot's vga init code - what's the best way to test that - filo?
I think so, yes.
On Sat, Apr 24, 2010 at 07:13:11PM +0200, Stefan Reinauer wrote:
On 4/24/10 5:28 PM, Kevin O'Connor wrote:
If I don't enable CONFIG_VGA_ROM_RUN I get:
build/coreboot_ram.o: In function `vga_init': vga.c:(.text+0x178d): undefined reference to `mainboard_interrupt_handlers'
[...]
I'm not sure if the delay is because RAMBASE moved or because of something related to the vga code.
Oh, can you just add the rambase at 0x4000 again and try that? This sounds like a caching issue and it should be investigated (we have such issues on AMD platforms, too)
Reverting the RAMBASE part of the patch fixes the timing.
It's been a while since I've used coreboot's vga init code - what's the best way to test that - filo?
I think so, yes.
I ran a test with filo and a coreboot executed vga optionrom - it works fine on my epia-cn. (As an aside, filo takes several seconds longer than seabios to init.)
So, the patch works for me with the exception of RAMBASE and CONFIG_VGA_ROM_RUN.
-Kevin
-
Corey Osgood -
Kevin O'Connor -
Stefan Reinauer