On Mon, Dec 14, 2009 at 10:25:14AM +0100, Magnus Christensson wrote:
>>> --- a/src/acpi.c
>>> +++ b/src/acpi.c
>>> @@ -464,10 +464,12 @@ build_ssdt(void)
>>> // build processor scope header
>>> *(ssdt_ptr++) = 0x10; // ScopeOp
>>> if (cpu_length<= 0x3e) {
>>> + /* Handle 1-4 CPUs with one byte encoding */
>>> *(ssdt_ptr++) = cpu_length + 1;
>>> } else {
>>> - *(ssdt_ptr++) = 0x7F;
>>> - *(ssdt_ptr++) = (cpu_length + 2)>> 6;
>>> + /* Handle 5-314 CPUs with two byte encoding */
>>> + *(ssdt_ptr++) = 0x40 | ((cpu_length + 1)& 0xf);
>>> + *(ssdt_ptr++) = (cpu_length + 1)>> 4;
>>>
>> Should be cpu_length + 2 as far as I can tell. The current code is
>> definitely broken.
>>
> Right. That should be cpu_length +2 in the else-part.
Can you resend the patch with the change?
Thanks,
-Kevin
This patch series adds support for 32bit PCI BIOS calls to SeaBIOS.
Currently, the SeaBIOS binary is composed of two big chunks of data -
the 16bit code (irq handlers) and the 32bit "flat mode" code (post and
boot). This patch adds a third chunk for 32bit segmented code. This
new code chunk uses explicit segment memory accesses like the 16bit
code does, but is compiled in 32bit mode.
I ran into one unexpected complication with this support - the PCI
BIOS functions need to support position independent code, as the code
and data segment base can vary. Unfortunately, using GCC's -fpic
option doesn't work, because that also implies building a GOT/PLT
which isn't desired and conflicts with segment accesses. To work
around the issue, I reserve %ebx in the 32bit segmented code as a base
offset and make sure all global variable accesses are relative to it.
There are three patches - much of it is just renames to support the
new code chunk.
-Kevin
Here are my thoughts on upcoming enhancements that should go into
SeaBIOS:
* Merge recent patches. Most are simple fixes. The only big change
is the ATA DMA support.
* Add 32bit PCI BIOS support. SeaBIOS has lots of 32bit code, but the
32bit PCI BIOS support requires use of segmented 32bit mode - so,
it's a bit of a pain to add. Right now, there are two main parts of
seabios that are linked together in the final compile stage - the
16bit code and 32bit flat mode code. To support 32bit PCI, there
will need to be three parts (16bit, 32bit flat, and 32bit
segmented). This will also involve changing a bunch of "#if MODE16"
tests to a new "#if MODESEGMENTS". This will make the final binary
a bit bigger (eg, there will be another copy of dprintf). While
doing this, it makes sense to convert the 32bit APM code to work the
same way (right now 32bit APM just transitions to 16bit mode and
calls the 16bit APM code).
* Make CONFIG_THREAD_OPTIONROMS the default. This experimental
feature allows SeaBIOS hardware init (eg, usb, ata, ps2) to run in
parallel with option rom execution. It can speed boot time on real
hardware. It's probably not much use for qemu, but I think it makes
sense to run as much of the same code on coreboot and qemu as
possible. There is a risk here of third-party option roms being
confused by the preemption code - however, that should be a small
risk and only testing will determine it.
* Add int1589 support. This call facilitates entering 32bit mode via
the bios. Bochs BIOS recently added support for it. It should be
straight forward to add to SeaBIOS - the 'struct bregs' should have
everything needed to restore state and directly return to the caller
in 32bit mode.
* Finish USB keyboard support - add auto-repeat, add LED support, add
support for usb hubs. USB keyboard works today (at least on qemu
and my Via hardware), but it's not fully fleshed out. These
remaining items should be completed.
Longer term items:
* Possibly add in DMA for packet commands, and possibly add support
for PATA timing code. The DMA on packet commands should be straight
forward. Support for PATA timing can noticeably increase transfer
speeds on these drives, but it requires per-chipset ide
initialization code. That would require a lookup table based on the
PCI ids of the ide controller to code capable of setting up the
proper timing.
* USB booting? This support is definitely needed, but there has been
some debate on whether adding to SeaBIOS makes the most sense. My
experience with ATA DMA indicates that EHCI support will also be a
requirement.
Any other items?
-Kevin