Documentation

[Xavier Pegenaute]

Hello,

i'm doing documentation about the code of LinuxBios with ADLO for my 
thesis, and i thought that may be you can helpme in things that are 
usefull to know for understand the code of LinuxBios. Of course after 
the document can be for linuxbios.

I started by a mail of Greg Watson that explain how is linked crt0.S and 
linuxbios, after this i started to explain the main things of 
hardwaremain.c that jump to the elfboot and finally elfboot to kernel.

Any one thing that is usefull to explain something else ?

Another thing that is a little confused in me .., the true point of 
start code, in some info say that is in 0xf0000, but in the compilation 
of ms7308e i see that is in:

linuxbios.map:00080004 T _start

i supose that then it depends of the motherboard ...

At the moment it's all.
Thanks for all.
Xavi.

[steven james]

Greetings,

The confusion is that there are multiple stages to LinuxBIOS. All x86
machines start at 0xf000:fff0 in real mode. The flash itself lives at the
top of the 4GB address space and the chipset arranges for an alias at the
top of the 1MB real mode address space.

The instruction at that start address will be a jmp to the assembly
language initialization code. Once the memory is set up, the next stage is
copied from rom (possibly with decompression) to 0x80000 which includes
_start. That code consists of a little assembly language (equivilant to
crt0 in a normal C application) followed by the bulk of LinuxBIOS which is
compiled from C. That code is entered at hardwaremain.

G'day,
sjames

On Mon, 5 May 2003, Xavier Pegenaute wrote:
> Hello,
>
> i'm doing documentation about the code of LinuxBios with ADLO for my 
> thesis, and i thought that may be you can helpme in things that are 
> usefull to know for understand the code of LinuxBios. Of course after 
> the document can be for linuxbios.
>
> I started by a mail of Greg Watson that explain how is linked crt0.S and 
> linuxbios, after this i started to explain the main things of 
> hardwaremain.c that jump to the elfboot and finally elfboot to kernel.
>
> Any one thing that is usefull to explain something else ?
>
> Another thing that is a little confused in me .., the true point of 
> start code, in some info say that is in 0xf0000, but in the compilation 
> of ms7308e i see that is in:
>
> linuxbios.map:00080004 T _start
>
> i supose that then it depends of the motherboard ...
>
> At the moment it's all.
> Thanks for all.
> Xavi.
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[Steve Gehlbach]

steven james wrote:
> All x86
> machines start at 0xf000:fff0 in real mode.

To be strictly correct, x86 machines start at 0xfffffff0 in real mode. 
( IA-32 Intel Architecture Software Developer’s Manual Volume 3, System 
Programming Guide, sect. 9.1.4.).

Quoting the manual, for those that don't have it handy:

"The first instruction that is fetched and executed following a hardware 
reset is located at physical address FFFFFFF0H. This address is 16 bytes 
below the processor’s uppermost physical address. The EPROM containing 
the software-initialization code must be located at this address

The address FFFFFFF0H is beyond the 1-MByte addressable range of the 
processor while in real-address mode. The processor is initialized to 
this starting address as follows. The CS register has two parts: the 
visible segment selector part and the hidden base address part. In 
real-address mode, the base address is normally formed by shifting the 
16-bit segment selector value 4 bits to the left to produce a 20-bit 
base address. However, during a hardware reset, the segment selector in 
the CS register is loaded with F000H and the base address is loaded with 
FFFF0000H. The starting address is thus formed by adding the base 
address to the value in the EIP register (that is, FFFF0000 + FFF0H = 
FFFFFFF0H).

The first time the CS register is loaded with a new value after a 
hardware reset, the processor will follow the normal rule for address 
translation in real-address mode (that is, [CS base address
= CS segment selector * 16]). To insure that the base address in the CS 
register remains unchanged until the EPROM based software-initialization 
code is completed, the code must not contain a far jump or far call or 
allow an interrupt to occur (which would cause the CS selector
value to be changed)."

-----------

If the biosbase option is not set, almost immediately, linuxbios does a 
far jump to 0xf0000:0004, and so reloads the segment register such that 
the aliasing of this address to the top 4G becomes important, as Steven 
James points out. But setting biosbase=0xffff0000 will use a relative 
jump and actually execute physically in the top 4G.

-Steve

Runtime flow of LinuxBIOS with a payload(etherboot for IDE) for FLASHROM and IDE

[Deepak Kotian]

Hi,

How does the runtime flow of LinuxBIOS go.
    If I see the Makefile, the romimage is done using
    cat payload linixbios >romimage.

1. Why is the payload stuck before linuxbios, any specific
    reason ?

2. Is there some specific addressing rule one needs to flow
    when making/burning the payload and linuxbios , basically the sizing?

3. I assume that the entherboot payload is also copied to RAM , is
        this correct ?
        If yes, is there a way to know, if it is done properly.

Regards
Deepak

Runtime flow of LinuxBIOS with a payload(etherboot for IDE) for FLASHROM and IDE

[Richard Smith]

Deepak Kotian wrote:
> If I see the Makefile, the romimage is done using
> cat payload linixbios >romimage.
>
> 1. Why is the payload stuck before linuxbios, any specific
> reason ?

Linuxbios has to be the last bit of code in your rom image.  See the 
recient thread on how the x86 starts up.  You have to have startup code 
located at that upper address or you will be attempting to run data.

Plus most chipsets will only assert the BIOS rom chipselect for specific 
address ranges.  So you have to have your bios code located in those 
ranges or your rom won't be selected.

Basically its a hardware thing.  Linuxbios (or at least the startup 
code) needs to be located in the last 64k of address space.
> 2. Is there some specific addressing rule one needs to flow
> when making/burning the payload and linuxbios , basically the sizing?

That's kinda board specific.  Depends on how the chipset works and the 
size of your rom.  For example on my board I have 2 512KiB roms.  So I 
have to tweak ROM_IMAGE_SIZE and PAYLOAD_SIZE such that they equal 
512KiB which locates linuxbios in the right spot.
> 3. I assume that the entherboot payload is also copied to RAM , is
>     this correct ?

Yes.
>     If yes, is there a way to know, if it is done properly.

Sure.  If it boots its probally done correctly. *grin*  There are a few 
other items you can use to test though.

1) is the ramtest.inc code.  Include it directly after you get ram setup.

see freebios/src/ram/ramtest.inc

When I was using this I had the following in my mainboard config file 
dirctly after my northbridge and southbridge inits

mainboardinit ram/ramtest.inc
mainboardinit mainboard/bitworks/rim/do_ramtest.inc

where do_ramtest.inc calls the ram test routine.

2) Is to build memtest86 as an elfimage and boot that.  Memtest does 
extensive memory testing.  Of course you need elfboot working first.