[coreboot] Enabling 4MB window in LPC adressing space

llandre r&d2 at dave-tech.it
Mon May 26 15:47:08 CEST 2008

It works now!
It seems LPC bus is somehow influenced by the USB 5V power voltage. If 
we don't provide this voltage LPC dongle exhibits the problems described 
before. We are still investigating this issue. When 5V is provided:

a) 4MB window is enabled (red LED is on)
b) post code are captured and sent to the virtual COM port correctly

coreboot is now able to find the kernel, however checksum is not ok. 
Maybe we still do not create the binary image correctly ...

Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000
Adjust rom_table_end from 0x000f0400 to 0x00100000
Wrote coreboot table at: 00000530 - 00000738  checksum 4eb4

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

rom_stream: 0xffc09000 - 0xfffeffff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
n_type: 00000001 n_name(8): ELFBoot  n_desc(6): Linux
n_type: 00000002 n_name(8): ELFBoot  n_desc(77): 
2.6.26-rc3-00285-gf556f19 (vit@
linuxserver2) #8 Fri May 23 16:07:56 CEST 2008
malloc Enter, size 20, free_mem_ptr 0001b130
malloc 0x0001b130
n_type: 00000003 n_name(8): ELFBoot  n_desc(2): Ã…
Dropping non PT_LOAD segment
malloc Enter, size 32, free_mem_ptr 0001b144
malloc 0x0001b144
New segment addr 0x10000 size 0x55c4 offset 0x14c filesize 0x1328
(cleaned up) New segment addr 0x10000 size 0x55c4 offset 0x14c filesize 
lb: [0x0000000000004000, 0x000000000001e000)
segment: [0x0000000000010000, 0x0000000000011328, 0x00000000000155c4)
  bounce: [0x000000000f7b8000, 0x000000000f7b9328, 0x000000000f7bd5c4)
malloc Enter, size 32, free_mem_ptr 0001b164
malloc 0x0001b164
New segment addr 0x20000 size 0x1070 offset 0x1474 filesize 0x0
(cleaned up) New segment addr 0x20000 size 0x1070 offset 0x1474 filesize 0x0
lb: [0x0000000000004000, 0x000000000001e000)
malloc Enter, size 32, free_mem_ptr 0001b184
malloc 0x0001b184
New segment addr 0x100000 size 0x700000 offset 0x1474 filesize 0xfe5f0
(cleaned up) New segment addr 0x100000 size 0x700000 offset 0x1474 
filesize 0xfe
lb: [0x0000000000004000, 0x000000000001e000)
Loading Segment: addr: 0x000000000f7b8000 memsz: 0x00000000000055c4 
filesz: 0x00
[ 0x000000000f7b8000, 000000000f7b9328, 0x000000000f7bd5c4) <- 
Clearing Segment: addr: 0x000000000f7b9328 memsz: 0x000000000000429c
Loading Segment: addr: 0x0000000000020000 memsz: 0x0000000000001070 
filesz: 0x00
[ 0x0000000000020000, 0000000000020000, 0x0000000000021070) <- 
Clearing Segment: addr: 0x0000000000020000 memsz: 0x0000000000001070
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 
filesz: 0x00
[ 0x0000000000100000, 00000000001fe5f0, 0x0000000000800000) <- 
Clearing Segment: addr: 0x00000000001fe5f0 memsz: 0x0000000000601a10
Loaded segments
Image checksum: 85c3 != computed checksum: 2705
Can not load ELF Image.

> Ühel kenal päeval, E, 2008-05-26 kell 12:51, kirjutas llandre:
>>>>>> However it does not work:
>>>>>> a) white LED on dongle is still off
>>>>> See http://coreboot.org/viewvc?view=rev&root=coreboot-v3&revision=660
>>>>> and do it in a similar place
>>>> Ok, thank you for your suggestion. I'll try it.
>>> This particular spot enables 4MB mode in mainboard stage1, which I'd
>>> think would be early enough, as it's right after the enabling of serial
>>> output (and the 4MB mode LED should be lighting up). Then again, I'd
>>> think that your previous spot should have been early enough as well, so
>>> not sure what the issue is.
>> Also when the post code logger is enabled (jumper 7-8 shorted), we see 
>> on the USB virtual serial port these strings only: "x00" .
>> So we suspect dongle is not getting the the I/O write operations at all.
>> Any idea?
> Nope, works for me. If post code logger isn't enabled, do you see other
> codes than 00 on the post code segments on the dongle?
>>>>>> b) coreboot prints:
>>>>>> Before VSA:
>>>> ...
>>>> option ROM_SIZE=4*1024*1024-36*1024
>>>> Is this correct?
>>> Two questions about this:
>>> 1) Why do you need a 4MB ROM? Do you have linux as a payload or what?
>> Yes. I need to boot a linux kernel. At the moment I don't see any other 
>> ways to do that.
> The commit message of the commit that I pointed you at explains a way to
> do that on the dongle with FILO payload and a 256KB or so ROM (that
> includes coreboot, VSA, VGA ROM and filo). You can address the dongle
> memory in FILO when 4MB mode is turned on, and you don't have to then
> deal with the mess that is dealing with over 1MB at firmware stage.
>>> 2) Don't you have VGA ROM added to the ROM? Your ROM_SIZE seems to
>>> indicate there is no room for that, and the log seems to indicate it's
>>> trying to do graphics init, which my ignorancy makes me now believe it's
>>> trying to init the VGA ROM and doesn't find it. Maybe you don't have VGA
>>> ROM included, but using a VSA that does the VGA init stuff which might
>>> need a VGA ROM to pass? I'm not sure about these specifics, but I do
>>> have to use a different VSA on coreboot-v2 and coreboot-v3, with my v2
>>> code having a VGA ROM too, and v3 not - this might very well be just
>>> codebase and coreboot VSA init differences, but could also be related to
>>> VGA - hopefully someone who knows will chime in, I've been wondering
>>> about the differences in the VSA versions for a while.
>> I suspect VGA ROM is not found by coreboot because it can't access whole 
>> 4MB window.
> you aren't reserving any space to fit a VGA ROM in 4MB.
> You have
> option ROM_SIZE=4*1024*1024-36*1024
> but for example upstream artecgroup/dbe61 has the following comment (in
> the code we use we have the commented out version that has 32KB for VGA
> ROM reserved too):
> ## ROM_SIZE is the total number of bytes allocated for coreboot use
> ## (normal AND fallback images and payloads).
> ## leave 36k for vsa and 32K for video ROM
> #option ROM_SIZE = 1024*256 - 36*1024 - 32 * 1024
> #No VGA for now
> option ROM_SIZE = 1024*512 - 36*1024
> There's no 32KB reserved for VGA ROM in your case either, hence why I
> don't believe you are adding a VGA ROM to the end result. That might be
> what you want (the VGA ROM is proprietary and has not had code released
> due to that, while the VSA code without VGA ROM init bits is), but just
> make sure you are using an appropriate VSA. Note that you won't be able
> to see any VGA picture without the VGA ROM unless you use libpayload's
> geode graphics support (coreinfo payload with libpayload configured with
> geode gfx support is a great way to test if things work) or until you
> reach lxfb module loading in linux kernel or native Xorg driver, which
> talk to the hardware directly instead of relying on the BIOS interrupt
> handlers that the VGA ROM blob provides.
> Regards,
> Mart Raudsepp
> Artec Design LLC


DAVE Electronics System House - R&D Department
web:   http://www.dave.eu
email: r&d2 at dave-tech.it

More information about the coreboot mailing list