[BULK] RFC: Generic shadow mechanism useable from a payload

Adam Sulmicki adam at cfar.umd.edu
Wed Jan 26 09:57:01 CET 2005


On Wed, 26 Jan 2005, Richard Smith wrote:

> On Wed, 26 Jan 2005 13:12:27 -0600, Richard Smith <smithbone at gmail.com> wrote:
>>> But I actually think that is overkill. v2 by default and design
>>> enables all of the shadow ranges as memory.  So we just need to
>>> use those ranges.  That should be much easier having to patch
>>> ADLO each time.  It is fairly unlikely a writable ROM segment is
>>
>> Ok.. Well when you put it that way yeah dosen't sound like its needed
>> at all. It should probally just work.
>
> Wait a minute.  I don't see how this will work.  To do the shadows you
> need to read from the bios chip, yet write to the RAM.  Then re-enable
> both read and writes to go to RAM.  This requires you to toggle some
> bits in the norhtbridge.

it is been a while but looking at loader.s

 	http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/util/ADLO/loader.s?rev=1.1&view=auto

it mentions sources as 0x8000 and 0x18000, so I guess they have been 
aready copied out of rom into the the low memory by linuxbios ???

(i think that's part of the ELF header specs to tell LB where to put the 
image).

wget http://cvs.sourceforge.net/viewcvs.py/*checkout*/freebios/freebios/util/ADLO/elf/elf-header-065kb.payload?rev=1.1

[adam at mtdew tmp]$ readelf -l elf-header-065kb.payload\?rev\=1.1

Elf file type is EXEC (Executable file)
Entry point 0x7c00
There are 1 program headers, starting at offset 64

Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
   LOAD           0x000100 0x00007c00 0x00007c00 0x10400 0x10400 R E 0x100

> I't will be awhile but I guess I will find out when I get there.  I'm 
> planning on still trying to use ADLO when I get V2 up and going on our 
> board.

I'm looking forward hearing about results.




More information about the coreboot mailing list