Peter Stuge wrote:
On Sun, Feb 24, 2008 at 01:34:29PM -0500, Kevin O'Connor wrote:
I do wonder... if coreboot builds pirq, mptable, ACPI, and e820 tables. Why not have it also populate that other bios "table" - the 64K one at 0xf0000-0xfffff?
If by "table" you mean code the answer is that coreboot does not like callbacks by design.
Otherwise I guess we have to store legacy data struct wherever they can be found.
One thing though:
I do believe we should merge what we call ADLO as another loader into v3. Augusto Pedroza wrote a patch for that for GSoC iirc.
Just like we have ELF loading and lar segment loading and VSA loading now.
Maybe we could even use the VSA loader to run bochs bios, instead of ADLO? It's all 16bit lumber ;)
Then using BIOS compatibility would just mean putting a bochsbios.bin into the lar.
ADLO is so fragile because it was written in assembler (so no stack is needed?!?), reimplementing all the things we have in coreboot in C. So recognizing that it just another loader would simplify and stabilize things quite a bit.
Someone might say we can do this with libpayload or by adding a lot of chipset specific code to ADLO and rewrite it from scratch. Then we're at 2500 lines of code instead of 25 and we have a nasty multi-staging.
Stefan