Entrance point (ipl and linuxbios)

ollie lho ollie at sis.com.tw
Tue May 27 00:20:01 CEST 2003


On Thu, 2003-05-22 at 20:04, Xavier Pegenaute wrote:
> 
> In theory we have mapped the completly EPROM into the top of memory (4Gb 
> for 32 bits) (Vol. 3 Cap. 9.10 of IA-32 ...), how we have the CS.BASE = 
> 0xFFFF0000 and EIP = 0x0000FFF0 with the special memory config we start 
> in 0xFFFFFFF0. We only can see a range of 0x0000 - 0xFFFF (the last 
> 64Kbytes?) until we turn to protected mode.
> Then we start the init of EPROM with the last 16 bytes below the top of 
> memory, that is the last 16 bytes below of vmlinux.bin.gz, of course 
> impossible, any one can help me in this ?
> 

The cases for DoC and normal flash are different. Your image map is for 
DoC. The DoC is very special that it will map the IPL to the top and
bottom of its addressable window. The addressable window is mapped
multiple times to 64KB below 4GB and 1MB by HW. In this way, the memory
map for the image has nothing to do with what CPU see in its address
space.

> Also, in ipl.S, we can find this code:
> 
> -----------------------------------------------------------------------
> #ifdef STD_FLASH
>     .org 0xfff0
> reset_vector:
>     .byte    0xea                # jmp to f000:fc00, where IPL
>     .word    0xfc00, 0xf000            # starts in Standard Flash
> #else /* !STD_FLASH i.e. DoC Mil */
> -----------------------------------------------------------------------
> Here if we have a standard flash eeprom we jump to the code of 
> initialitzacion "sis630spd_start:" in ipl.S and we execute until 
> "sis630ipl_end:" that there is a
> jump to SPL vector.
> What about ".org 0xfff0" ?

For IPL for normal flash, we deliberated to make the IPL 64kB although 
it is only 512B and overlap the first 63kB with linuxbios.bin. The .org
0xfff0 directive makes the reset_vector at the last 16B of the 64kB 
image.

> -----------------------------------------------------------------------
> #if (USE_DOC_MIL == 1)
>     .org 0x1f0
> -----------------------------------------------------------------------
> If we have DOC_MIL ".org 0x1f0".

We address the reset vector to the last 16B of 512B.

> -----------------------------------------------------------------------
> #elif USE_DOC_2000_TSOP == 1) || (USE_DOC_MIL_PLUS == 1)
>     .org 0x3f0
> -----------------------------------------------------------------------
> and here we put the ".org 0x3f0"
> -----------------------------------------------------------------------

The size of IPL area is 1kB instead of 512kB for newer DoC Mil and DoC
Mil Plus. So we have to make the reset_vector at the last 16B of 1kB.

> #endif
> reset_vector:
>     .byte    0xea                # jmp to fe00:0000, where IPL
>     .word    0x0000, DOC_WIN_SEG        # starts in DoC
> #endif /* STD_FLASH */
> -----------------------------------------------------------------------
> If it is not a DOC_MIL and bla, bla, bla ... we make a jmp to 
> 0xfe00:000, what is there in this direction ?
> -----------------------------------------------------------------------

As I mentioned before, the DoC area is mapped multiple times at the top 
and bottom 2kB of the 8kB window. The 8kB window is than mapped by HW to
0xC0000-0xFFFF and 0xFFFC0000-0xFFFFFFFF. When jumping to fe00:0000, it 
jumps to one alias of the IPL area.

> spl_vector:
>     .byte    0xea                # jmp to 8000:0000, where SPL
>     .word    0x0000, SPL_RAM_SEG        # (LinuxBIOS) starts in RAM
> -----------------------------------------------------------------------
> And finally if it was a standard flash or DOC_MIL we jump to LinuxBios 
> in the segment 0x8000. In theory LinuxBios ?.
> 
> My questions:
> - May be the mapped EEPROM in memory address space is mapped in reverse 
> order (to find linuxbios in the firs 64Kb) ? 0x0 of EEPROM -> 0xFFFFFFFF.

No, it is not.

> - Who is executed first ipl.S, or crt0.S ?
> My confusion are the ".org 0xfff0" in ipl.S but in the same time in 
> src/cpu/i386/reset["16","32"].inc i found some reference to reset_vector 
> but i don't know how it works , also by the other hand who turn the 
> memory in protected memory is crt0.S, then this has to be the first.
> 

For SiS chipsets, the memory init is done in ipl.S instead of crt0.S so
IPL is executed first.

-- 
ollie lho <ollie at sis.com.tw>




More information about the coreboot mailing list