Ronald G Minnich <[EMAIL PROTECTED]> writes:
> one question. It seems like the mainboard-specific chunks of C code are
> really going to grow a lot. That's something I would like to avoid if
> possible.
Only the very last function in that file should be motherboard specific
after I get done converting everything. I started prototyping with just
struct values and that was to hard. So I want something that can build
the structure on the fly. That is the point of the helper functions. And
I'd rather deal with C than some weird config script.
I really don't expect this table to be much worse than the mp_table or
the irq routing tables. Except that it should be a little bigger
as we include more information in it.
My goal has been to find a table structure simpler than ACPI that is
sufficient to describe all of your motherboard hardware. I think
I have succeeded but using simple primitives leads to a fairly complex
table. The only nice thing is that mappings for odd devices seem to
suggest themselves from the properties of those devices, instead of
having to be totally generated from scratch.
I need to confirm that what I have really works but once that happens,
I'll start checking it into the tree.
For things like initializing the interrupt controllers, dma controllers,
serial ports etc, the logic in liuxBIOS should get down to. Oh
I have a dma controller on device X. Initializing the path to device X.
Initializing device X. O.k. you can now do DMA to access your floppy
drive....
Grr. There is another case I've left out of my tables. The whole DMA
connection of the floppy drive. It is always the hardest the first
time you do something like this.
> Is there any chance of this stuff being generated by the config
> tool (or a better version of it).
The file I sent could be run at build time if necessary. So yes.
Though for things like the pci scan some of this code also must
be inside of linuxBIOS.
> It does look to me like that might be
> possible from what I've seen in the structures.
Definentily.
Eric
