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.