[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