V2 Epia report
Greg Watson
gwatson at lanl.gov
Fri Oct 10 15:47:00 CEST 2003
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
More information about the coreboot
mailing list