On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote:
>
> Isn't this done first in hardware startup so that we can print debug
> stuff when configuring cache and the like?
No,
>
> >> M Init malloc memory pool
> >> O Display processor internal details of value (e.g. intel cpuid)
> >> O Pick a PCI method if you need to init PCI
> >> M Size memory so you can tell Linux
> > ^
> > Embedded systems may prefer this be optional so memory-size can be
> > hardcoded and forgotten. Wouldn't this also be arch- or chipset-
> > dependent?
>
> This is really just probing what was set when SDRAM was initialized and
> is nearly zero overhead.
>
> >> A Re-config the cache so that it caches all or memory
> >> O Configure PCI bus
>
> Here is where we get into the area that I don't yet believe it is
> practical to have one size fits all code.
>
> >> A Mainboard fixup
>
> Board and application dependent.
>
> >> C enabled extended NVRAM access
>
> This may be board dependent.
>
> >> A Handle extended machine state (e.g. MTRR)
>
> Can you give examples? I only see MTRRs used to config L2 cache. This
> seems like a board and/or application dependent thing.
>
> >> C Enable keyboard
> >> C Enable floppy
> >
> > For obvious reasons, embedded folks would like to see this be optional.
>
> Yup! These items are board/application dependent.
>
> >> A Enable tables that Linux uses on startup (e.g. SMPBLOCK)
> >> M Set up IRQ tables for Linux
> >
> > For simplicity, I'd prefer this be optional. With no capability for
> > hot-plug devices, I'd rather have interrupts get set up once and left
> > alone. That assumes, of course, that PCI config has calls to a
> > chipset/mainboard-specific irq-routing function. (don't remember if
> > linuxbios has that capability right now).
>
> This is done the way it is because the kernel already has the ability
> and linuxbios doesn't so we used the ability where it already existed.
> Unless you are going to trim the code out of the kernel I'm not sure
> there isn't a reason to use it.
>
> However, in support of why I'm not favoring the one-size fits all
> intel_mail() is that the existing system assumes that you need to copy
> the irq_tables from someplace else. I think this is a DoC thing. It
> doesn't seem to be hurting my system but doesn't make me comfortable.
>
> >> R Enable interrupts
> >> O Final Mainboard Fixup
> >> A Final L2 Configure
> >> M Call non-hardware-dependent linuxbiosmain()
> >>
> >> Kernel startup:
> >> O Banner
> >
> > For debugging and development reasons, I have stuck a check for keypress
> > here, along with a debugging menu that allows me to fiddle with things
> > from cache setup to kernel params. I did this stuff for my own needs, but
> > it turned out to be such a useful item that other folks might find some
> > use for it. I know you cluster guys hate using the console, but it's
> > pretty nice for debugging and development in my embedded system. That
> > might affect the location of kernel parameter setup below. Example: what
> > if a particular driver suddenly starts locking up the system on boot? It
> > sure is nice to pass "1" (means start in runlevel 1) to the kernel as a
> > parameter, to get yourself into the system to fix things...
>
> Can you make this code available? I may need it and would definatly
> like it.
>
> >> M gunzip setup
> >> M gunzip
> >> M Linux parameter setup
> >> (mistake! move me!) APIC setup
> >> M Jump to Linux
>
> ...again, I don't see a one size fits all solution for this group of
> functions.
>
> My concern about one size fits all is that it doesn't. And when you
> are forced to go outside the system it gets hard to support and hard to
> share results. A much more general system certainly can include a one
> size fits most function that could be called by the board/application
> dependent initializer function.
>
> Ty
>
>
