Greg Watson <[EMAIL PROTECTED]> writes:
Yes, I have a similar problem with the current setup. I need to be able to do
static initialization on entry to hardwaremain, but before console_init(), and
also prior to pci enumeration.
The original conception was that such things would happen before hardwaremain was actually called. But regardless.
On the PPC, much of what must be done in assembly or romcc on Intel/AMD, can be done in C in hardwaremain. The architecture needs to be flexible enough to accommodate this.
Currently static device initialization can only be done during pci setup which is too late.
Why???
For example, I want to be able to configure the serial port on the superio chip so that console logging will work. This has to happen before console_init() is called. Other things that I want to be able to do that I don't want tied to PCI setup are:
- flash setup - NVRAM setup - on-board network interface setup - SDRAM setup
The order goes something like this:
hardwaremain() {
pre_console:
superio()
console_init()
pre_pci:
nvram()
sdram()
flash()
pci:
pci()
usb()
ide()
pre_boot:
fenet()
elfboot()
}In addition, I probably don't want to call cpu_initialize() after PCI setup. I would prefer if the cpu (or cpu's) was treated much the same as any other static device, then I could choose where cpu_init() gets called, which may be in multiple places.
I've started using chip_configure() again to get around this problem, but it means I have to skip the enumerate_static_devices() step or things go to hell.
Why???
Otherwise the chip initialization happens twice: once from the call to chip_configure() and once from dev_initialize(). And it happens at the wrong place.
I can feel that there is pain here. But I cannot see the source. There are two possible solutions. Either the current structure needs redesign or I need to more clearly document and explain the current structure so it can be fully taken advantage of.
The current design is too tied to PCI setup, doesn't provide any means of doing initialization other than when PCI devices are initialized and doesn't give any control over *when* devices are initialized. chip_configure() allows devices to choose when in the boot sequence they want to perform some action, and allows multiple actions to occur for a single device.
I'd be happy if the current scheme could provide this functionality, but I don't see any easy way to do it.
The fundamental problem I see is that Intel/AMD architectures do a lot more initialization prior to hardwaremain, so the functionality that I'm looking for is not really needed. Once you're in hardwaremain, basically all that's left to do is get PCI going. This is not the case for PPC (and maybe other architectures.) The question is really: should linuxbios be Intel/AMD specific and required other architecture support grafted on, or should it be made general enough to work with any architecture. I guess I'm suggesting the latter.
Greg
_______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
