FAQ question fixup

Stefan Reinauer stepan at openbios.org
Wed Mar 2 11:27:00 CET 2005

* Stefan Reinauer <stepan at openbios.org> [050302 17:04]:
> * Richard Smith <smithbone at 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?



  * code placed at reset vector (0xfffffff0)
  * jump to _start in entry16.inc
  * jump to protected_start in entry32.inc (what is this good for??)

  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?

  * linker script provides 16bit versions of the addresses (?)
  * switch to protected mode.
  * jump to __protected_start in entry32.inc
  Can someone enlighten me on the restriction comments here? given that 
  we are always on a standard x86 system, we are always above

  * linker script is a noop.
  * sets up all segment registers to the same value. (ROM_CODE_SEG)
  * falls through to bist32.inc

  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.

  * 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

  * set up variable and fixed mtrrs.
  * set up XIP

  Will this hurt C-A-R? Can we somehow derive the XIP addresses from the
  information that we know, making XIP more solid?

  * 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 ??)

  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