[LinuxBIOS] MB1030 / 3036 VGA resume

[Stefan Reinauer]

* Christian Sühs <chris at suehsi.de> [060511 15:33]:
> 
> > One of the many delicacies of LinuxBIOS is that it enters protected mode
> > (32bit mode) after only 17(!) CPU instructions. 
> 
> Ok, were is it done in LB
> is entering protected mode a standard procedur of LB.
 
Yes, this is a standard procedure on all x86 CPUs

I wrote the attached document quite a long time ago. Its not all current
but it might help to understand the concept

> > I would assume it is there anyways, or the FPU is always enabled for the
> > GX1?
> 
> Maybe, I have to read the datasheet for FPU
 
I would not care any further. This part works...

Stefan



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
-------------- 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