On 7 Feb, Eric Seppanen wrote:
> On Wed, Feb 07, 2001 at 01:32:00PM -0700, Ronald G Minnich wrote:
>>
>>
>> Each item on the list is marked as M (mandatory), R (recommended),
>> O (optional), A (architecture dependent, not needed on all systems),
>> C (chipset dependent)
>
> I have made a few notes from the embedded-system point of view.
>
>> Assembly startup:
>> M Reset jump to start of LinuxBIOS
>> M Ensure CPU is in sane state (e.g. Purge I Pipeline, etc.)
>> A Put CPU into protected virtual memory mode
>> O Enable serial port debugging print
>> O Enable debugging prints to console graphics
>> O Memory test
>
> I presume that mixed in here somewhere was basic chipset init, enough to
> get RAM turned on? That'd be chipset-dependent, of course.
It can also be board type specific. My system has not SPD eeproms and
uses a hard coded SDRAM config.
>> M Set up C environment
>> M Jump to C code
>>
>> Hardware startup:
>> A Configure Cache. Needed here for speed.
>> A Processor-dependent steps that are required, e.g. microcode patch
>> M Init C display variables. Required before printk()
Isn't this done first in hardware startup so that we can print debug
stuff when configuring cache and the like?
>> 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
--
Tyson D Sawyer iRobot Corporation
Senior Systems Engineer Real World Interface Div.
[EMAIL PROTECTED] Robots for the Real World
603-532-6900 ext 206 http://www.irobot.com
