[BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling ACPI tables?

[Stefan Reinauer]

* yhlu <yinghailu at gmail.com> [050804 18:28]:
> So everyone agree to put acpi support to LinuxBIOS?

It's there already ;-) 

But the question is how do we want to create the information ..

> An the way that we need to create our own acpi tables dynamically. (
> in case user add pci bridge .....)

I'm not sure how far we get with this approach, since we'd quickly need
a DSDT for basically everything. 

Look at the island/aruma - it won't find any devices on bus!=0 unless 
the dsdt is there and it needs to be patched online with the bus numbers
(that may vary, dependent on the cards that are connected)

As soon as you start with ACPI in the Linux kernel you need to provide
a pretty complete set of it, since the ACPI code is not very modular.

And it does not interact well with the other tables. So basically, if
you have ACPI enabled, Linux will ignore the mptable and the pirq table.

This is probably due to inconsistent tables of different kinds in
awkward and ashes bios, so you can't really blame the linux code. It's
not really a clean modular parallel implementation of the standards but
an empirical answer to the real world.

To make sure we don't run into problems, LinuxBIOS should create all
tables from a single internal representation, to make sure they are
consistant. This will bloat the configs noticably so I am not sure
whether it is a good idea to head here before another set of config
mechanism changes. The next step then would be to provide all
information in the config that can not be autoprobed. ie. the board's
IRQ wiring.

Then pack all this information into the internal device representation.
Possibly in the LinuxBIOS table. 

Most ACPI tables will then be pretty easy to produce:
 * MADT  (APICs and IRQ routing, overrides, NMIs) ..
   see mainboard/island/aruma/acpi_tables.c:acpi_dump_apics()
 * HPET (timers)
 * FACS, RSDT, RSDP
 * FADT

The most nasty one is definitely the DSDT. Maybe this one can be
generated from the config.lb files. The result would have to be passed
through iasl or your favourite ASL compiler, and linked in the bios
image. 

Generating mp and pirq from the internal representation seems pretty
trivial once acpi is working, since both are a lot less complex.

   Stefan