On 2 Feb, Ronald G Minnich wrote:
> On Fri, 2 Feb 2001, Ronald G Minnich wrote:
>
>> On Thu, 1 Feb 2001 [EMAIL PROTECTED] wrote:
>>
>> > How entrenched is this super IO API? Can I replace it with something
>> > that is more useful? I need to configure two super IO chips to custom
>> > specifications.
>> >
>>
>> not entrenched at all. Do what you need to do ...
>
>
> tyson, it seems that we ought to support multiple superio commands in the
> config tool. Then, for each superio named in the config file, the init
> functions would be called for that device.
>
> ron
I would rather see mainboard_fixup() do the calls to initialize the
superio. If we don't use this as a design philosopy the config tool
is going to have to allow for every variation in every motherboard and
will end up getting pretty hairy.
We can still use the 'option' option to set parameters and enable or
disable certain features such that we can still write functions that
will work for a class of devices rather than having to duplicate lots
of code.
In general, I'd like to see lots of functions that make it easy to
write mainboard_fixup() plus a few "high level" functions so that most
mainboard_fixup() functions don't need to have much in them.
Right now the irq tables get copied around. I believe that this is to
support DoC systems but there is no way to avoid it for non-DoC systems.
Right now the superio.c code doesn't allow for enabling more than one
superio chip or to have any control over the baud rate.
Right now it isn't possible to load an initrd because of how
intel_main() is structured.
We need to be able to choose between EXIO bus and full ISA bus
configuration. We need to be able to configure the superio chips for
how its interrupts are wired to the southbridge. We need to be able to
configure the CarBus controller for how its interrupts are interfaced
to the southbridge and configure the southbridge to match. (the CardBus
interface on our board uses "serial interrupts").
All of these things are board dependent and the current structure
assumes that systems the linuxbios is used are are more heterogenous
than they really are. It also assumes that all chip sets have the same
functionallity and can be supported with the same API and parameters.
This is probably true for the most common and simplest cases but I see
linuxbios getting a lot of use in uncommon and not-so simple
situations, esp. for embedded systems.
Now, the sincere question: Is extending the config tool to handle all
cases the right design philosophy? I think we would be better off
letting mainboard_fixup() do what it needs and giving it the tools
(functions) it needs to make this easy. ...but I could be wrong.
Consider that many of the features in the config tool are redundant to
'option' and 'object'. Only those features that cause code to be
generated are really special, like the options the are used to generate
crt0.S.
Cheers!
Ty
--
Tyson D Sawyer iRobot Corporation
Senior Systems Engineer Real World Interface Div.
[EMAIL PROTECTED] Robots for the Real World
603-532-6900 ext 206 http://www.irobot.com
