* Stefan Reinauer stepan@openbios.org [050302 17:04]:
- Richard Smith smithbone@gmail.com [050302 17:00]:
I've been adding selected info from my V1 FAQ up into the wiki. The following is some info I compiled up on V1 start up.
If someone(s) would update this for V2 and post it t the wiki I think it would be very useful.
Something along this line. I wrote it about a year ago and never really used it since so it might be wrong here and there.
--> wiki?
Stefan
-----------------------------------------------------------------------
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 -----------------------------
- compile romcc
- create option table
- process and compile romcc based code
- 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