[LinuxBIOS] First instruction in linuxbios
Stefan Reinauer
stepan at openbios.org
Fri Aug 5 22:05:20 CEST 2005
* Jorge Cardona <jorgeecardona at gmail.com> [050701 18:29]:
> Hi.
> I'm new in this, and i'm reading the source and i have a question, which one
> it's exactly the first instruction that the processor execute when the pc is
> booting?, in which file is it?
Here's a little summary I wrote a while ago.. don't know if it is still
correct and complete.
> I don't complete understand the relationship between a normal bios and the
> kernel, i think that the bios it's has to pass some data to the kernel, if
> that's true ¿how exactly is that data passed to the kernel?
There are several possibilities. Either the information is placed at
well known addresses or in a certain address range, using a signature so
the kernel can find it.
Or the Kernel does callbacks (intXX).
> In linuxbios, how it's this issue handle?
LinuxBIOS provides tables: ACPI, MPTABLE, PIRQ table, and a LinuxBIOS
table which should some day obsolete all the other tables.
No callbacks. They are considered unsafe and error prone.
Stefan
-------------- next part --------------
Ok,
I think I got it now, except some minor things. I would like to add this
explanation to my LinuxBIOS document. Please help me advance it with
some expert comments, since I feel rather like a novice in this part of
the code. Has there been anyone describing this in detail, while
still being understandable? I remember seeing something a long time ago
for v1, but I couldnt find it in the archives anymore.
It seems that my current approach, leaving everything up to failover.c
untouched, might not be the best way to go. From early_mtrr.inc on we
have XIP acceleration available, thus it seems that we hook in after
this point, and do everything afterwards in gcc, creating an extra hunk
with an extra .lds file to pack it all into.
reset16.[inc|lds]
-----------------
Description:
* code placed at reset vector (0xfffffff0)
* jump to _start in entry16.inc
* jump to protected_start in entry32.inc (what is this good for??)
Comments:
reset16.lds supports ROMBASEs smaller than 0xffff0000. reset16.inc does
not. Do we ever need anything else on x86 based systems? If not, I
suggest to drop the conditionals.
It seems to me that the second jump is later done by entry16.inc, and
the reset vector is never reached. Is it used by something else?
entry16.[inc|lds]
-----------------
Description:
* linker script provides 16bit versions of the addresses (?)
* switch to protected mode.
* jump to __protected_start in entry32.inc
Comments:
Can someone enlighten me on the restriction comments here? given that
we are always on a standard x86 system, we are always above
0xffff0000?
entry32.[inc|lds]
-----------------
Description:
* linker script is a noop.
* sets up all segment registers to the same value. (ROM_CODE_SEG)
* falls through to bist32.inc
Comments:
there's two entry points here, protected_start and __protected_start.
Are they both needed? protected_start seems to do the same thing as
the end of entry16.inc.
The comment states that we do something with memory here. It seems
this is wrong, since we are far before enabling memory.
bist32.inc
----------
Description:
* Checks EAX for BIST failures.
* if everything is ok, falls through (skipping next
files that put code in different sections: reset16.inc,
cpu_reset.inc, id.inc) On K8 this goes to early_mtrr.inc
early_mtrr.inc
--------------
Description:
* set up variable and fixed mtrrs.
* set up XIP
Comments:
Will this hurt C-A-R? Can we somehow derive the XIP addresses from the
information that we know, making XIP more solid?
failover.c
----------
Description:
* romcc generated code
* if normal boot, we jump into normal image.
* if cpu reset, we jump into __cpu_reset, which jumps into
__main (Where is this one? crt0.base? auto.inc?)
* if we're running on the second CPU, we jump into normal/fallback
image (???)
* if no problems appeared, jump into normal image
* otherwise fall through (to auto.c ??)
Comments:
What's HAVE_REGPARM_SUPPORT? There's a lot of conditions in this file.
I did not follow all the branches yet. Maybe someone can explain more?
it seems that __cpu_reset jumps into __main - does this mean the dram
init survives a cpu reset?
> -------------- part 1: creating init code -----------------------------
> 1) compile romcc
> 2) create option table
> 3) process and compile romcc based code
> 4) create crt0.o from romcc based code
>
> -------------- part 2: creating payload -------------------------------
> 5) compile all drivers
> 6) compile all objects
> 7) compile static device tree
> 8) link objects and static tree --> linuxbios.a
> 9) create linuxbios_c from start.o, drivers and linuxbios.a
> a) create linuxbios_payload from linuxbios_c (with or w/o nrv2b)
>
> -------------- part 3: final image ------------------------------------
> b) create "linuxbios" from crt0.o (including linuxbios_payload via
> linker script arch/i386/config/ldscript.lb)
> c) create romimage linuxbios.rom from "linuxbios" with buildrom
More information about the coreboot
mailing list