V2 Epia report

[Greg Watson]

At 12:11 PM -0600 9/10/03, Eric W. Biederman wrote:
>Greg Watson <gwatson at lanl.gov> 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