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.
thanks
ron
---------- Forwarded message ----------
Date: Wed, 9 Oct 2002 17:50:22 -0600
From: Neil Crossley <etanza at lycos.co.uk>
To: rminnich at lanl.gov
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
running.
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
.got_mem
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
support.
Note - When you switch to protected mode make sure the NW and CD bits in CR0 are 0
(enabled)
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
wrmsr
; Allocate ONE MTRR to map 64KB at location 0xc000000
mov ecx,0x200 ; Base
mov edx,0
mov eax,0xc0000006
wrmsr
mov eax,0xffff0800 ; Mask (64K)
mov edx,0x0000000f
mov ecx,0x201
wrmsr
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
.got_mem
______________________________________________________
Check out all the latest outrageous email attachments on the Outrageous Email Chart! - http://viral.lycos.co.uk