Making IPL coding easier? (fwd)

Ronald G Minnich rminnich at
Thu Oct 10 00:18:00 CEST 2002

Neil has a very interesting point, and it does bring up the "cache as ram"
issue again.

Neil, my only question is, did you test this MTRR approach on lots of
CPUs. My impression is that it is not guaranteed to work.



---------- Forwarded message ----------
Date: Wed, 9 Oct 2002 17:50:22 -0600
From: Neil Crossley <etanza at>
To: rminnich at
Subject: Making IPL coding easier?

Hi Ron,

Dunno if this will be any use to you but you never know .....

I was thinking how much easier is would be to write dram setup code for IPL's if it was
possible to get even a small amount of memory for temp variables and a stack. This
would get rid of the annoing CALL_SP/BP and RET_SP macros.

Obviously this 'memory' couldn't be DRAM coz we haven't initialised it yet. and using the
CMOS RTC locations would get us a few bytes of memory, but no stack (i'm suprised you
dont use the RTC memory though as at least you could store a few temp vars if you
needed to)

Having some work memory should make the IPL code a bit more readable and thus
easier to work with, you could also put more functionality there leaving less work for the
C code to do later.

I found 2 methods of getting some work memory, one relies of the motherboard having
a SiS7018 soundchip (as found on the SiS540/630/730 series) and the other requires a
CPU with MTRR support.

Using method 2 may allow you to code the DRAM initialisation code in 'C' as it will
provide you with 64K of work memory, but it may take some tweaking to get C code

Appologies for the following code fragments using intel syntax but they should be easy
enoogh to follow.

Have fun and mail me if you have any questions ...

bye for now .... Neil :)

METHOD 1 - Use the 7018 Soundchip to get 1KB of memory

The first way is at least relativley sane but relies on the mainboard having the 7018
soundchip enabled (some motherboard manufacturers choose to disable this and fit
another chip on the mainboard)

The 1KB of ram exists from offset 0x800 in the soundchip's Memory mapped IO space

 mov ebx,0x80000c00		; Select 7018 Soundchip
 mov eax,ebx ; Set MMIO Base address
 mov al,0x14
 mov dx,0xcf8
 out dx,eax
 add dl,4
 mov eax,0xf8100000		; Map MMIO at this address
 out dx,eax
 mov eax,ebx ; Enable device
 mov al,0x04
 sub dl,4
 out dx,eax
 add dl,4
 mov eax,0x6			; Just set Bus master and MMIO,
not I/O
 out dx,eax
 mov esp,0xf8100bfc ; Set stack to top of ram
 mov ebp,0xf8100800 ; Set ebp to bottom
 mov eax,0xf00dface ; Check the memory is really
 mov [ebp],eax ; working ...
 mov ebx,[ebp]
 cmp eax,ebx
 je .got_mem
 jmp ERROR_1 ; issue some sort of BEEP code or something

As far as I know, VIA and ALI both use variations of this soundchip on their integrated
boards so this may work on those chipsets too :)

METHOD 2 - Abuse the CPU Cache to get 64K of memory

CPU's like the Hitachi SH series allow the cache to be memory mapped and used as RAM,
so I wondered if there was any way to do this on the Intel chips. I actually discovered
this method by accident (dont ask - long story!!). To use it requires a CPU with MTRR

Note - When you switch to protected mode make sure the NW and CD bits in CR0 are 0
 doing "mov eax,1" and "mov cr0,eax" will do this nicely :)

 ; Enable Variable MTRR's only (not fixed) and set the default memory type to
 ; uncached

 xor edx,edx
 mov eax,0x800
 mov ecx,0x2ff

 ; Allocate ONE MTRR to map 64KB at location 0xc000000

 mov ecx,0x200 ; Base
 mov edx,0
 mov eax,0xc0000006
 mov eax,0xffff0800 ; Mask (64K)
 mov edx,0x0000000f
 mov ecx,0x201

 cld ; Wipe our 'memory' forcing all the 64K
 xor eax,eax			; to be cached
 mov ecx,65536/4
 mov edi,ebp
 rep stosd

 mov esp,0xc000fffc ; Set stack to top of ram
 mov ebp,0xc0000000 ; Set ebp to bottom

 mov eax,0xf00dface ; Check the memory is really
 mov [ebp],eax ; working ...
 mov ebx,[ebp]
 cmp eax,ebx
 je .got_mem
 jmp ERROR_1 ; issue some sort of BEEP code or something

Check out all the latest outrageous email attachments on the Outrageous Email Chart! -

More information about the coreboot mailing list