V2 Epia report

[Greg Watson]

In the interests of moving forward here, I will see if I can get this 
to work with dynamic device tree.

Greg

At 7:25 PM -0600 9/10/03, Eric W. Biederman wrote:
>  > 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.
>
>I concur.   And the really weird stuff either needs to happen before
>we enter hardwaremain or as the first function we call.  I have no problem
>with doing that.  But it should be done that way because it is weird
>motherboard dependent code.
>
>  > 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()
>>  }
>
>Ok.  If everything is working out of ram I can see modifying things
>so there is both a hook before console_init, and a hook after it so generic
>console code can be used.  It is possible to define motherboard
>specific console drivers but proposing that as a solution to your
>problem is silly.
>
>The ethernet case is not a case I currently understand.  I would be
>highly surprised if something is needed there.  My gut feel is a
>simple init method should be all that is needed.  Unless you are doing
>an ethernet device driver and that is something else again.
>
>>  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 agree they way we are currently dealing with cpus is problematic, as
>it does not follow the same model as the rest of the code.  There has
>not yet been much looking given to how to handle them correctly.
>Doing cpu initialization late has not mattered much because if you can
>run the code in C generally there are no show stopper cpu bugs or cpu
>setup that needs to be worried about.
>
>  >
>>  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.
>
>There are two kinds of devices.  Devices that are highly motherboard
>centric, and no matter what you do will have special rules and generic
>code cannot cope with them.  And then there are devices that are well
>factored, and can be treated as independent pieces of hardware.
>The generic device tree is aimed at hardware that is well factored, for
>the rest we do need a different mechanism. 
>
>For a well factored device having it initialized at the wrong place
>is almost impossible.  Except in the rare cases where the devices is
>needed to bootstrap another say the smbus controller for memory, and
>in those cases it is the memory or whatever else it is that is not a
>standalone device.
>
>  >
>>  The current design is too tied to PCI setup.
>
>I have to vent at this statement.  Yes the code was derived from what
>is needed to setup PCI devices.  But no it is not tied to PCI devices,
>and I believe this view is part of what is limiting this conversation.
>In particular I see no problem setting up superio I/O devices with
>this code.
>
>I try and full fill a couple of requirements with the code.
>1) Enable code reuse when the hardware is tied together on another
>    board in a different way.
>2) Enable flexible resource allocation.
>3) If I have multiples of the device allow the code to just work.
>
>For an individual device knowing specifically when it is initialized
>inspires brittle code.
>
>If I have multiples of the same device the code needs to be able
>to hand out dynamic resource assignments.
>
>And yes this results in a little bit of duplicate setup for hardware
>like a serial console that is both a generic piece of code and that
>must be bootstrapped early.
>
>>  , 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.
>
>It is assumed the dependencies can be represented in the device tree.  If you
>are higher up in the tree you are initialized first.  And of devices in the
>same level of the device tree the order in the static tree pretty much
>rules.
>
>>  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.
>
>It also provides no structure and it solves none of the hard problems.
>As for being able to do things in the boot sequence I have 6 methods
>to your 8.  Plenty of opportunity to do weird things if need be.
>
>I guess what I would like to avoid is representing what is essentially
>a motherboard dependent function call graph in a static device tree
>instead of just doing it straight forwardly in C.
>
>What I don't see with chip_configure is it promoting any level of code
>reuse because what the calls do is not well defined.  They are called
>in relationship to other code instead of being called to do something.
>
>>  I'd be happy if the current scheme could provide this 
>>functionality, but I don't
>>  see any easy way to do it.
>
>Hmm.
>
>>  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.
>
>I agree that the current x86 ports do a substantial amount prior to
>hardwaremain, and so we don't have a few of your issues.  That can
>easily be rectified. 
>
>>  Once you're in hardwaremain, basically all that's left to
>>  do is get PCI going. 
>
>Not at all.
>>  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.
>
>I totally agree with the sentiment.  And if you don't have very many
>devices that need their addresses programmed dynamically.
>
>Eric