Hi all,
I'm trying to boot a linux kernel image. It is about 2 MBytes. I used buildrom to generate the 4MB binary image (coreboot+linux) that I downloaded to Artec LCP Dongle flash. IIUC, to read the payload it is necessary to enable the 4MB window in LCP addressing space. To do that I modified cache_as_ram_main function in order to write 0xF4 to I/O port 0x88:
void cache_as_ram_main(void) { outb(0xF4, 0x88); ...
However it does not work: a) white LED on dongle is still off b) coreboot prints:
Before VSA: do_vsmbios buf ilen 1011820 olen949065 buf 00060000 *buf 255 buf[256k] 255 buf[0x20] signature is ff:ff:ff:ff do_vsmbios: no vsainit.bin signature, skipping! After VSA: Graphics init... VRC_VG value: 0xffff Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
Anybody can help me?
TIA, llandre
DAVE Electronics System House - R&D Department web: http://www.dave.eu email: r&d2@dave-tech.it
Ühel kenal päeval, R, 2008-05-23 kell 17:45, kirjutas llandre:
Hi all,
Hello,
I'm trying to boot a linux kernel image. It is about 2 MBytes. I used buildrom to generate the 4MB binary image (coreboot+linux) that I downloaded to Artec LCP Dongle flash. IIUC, to read the payload it is necessary to enable the 4MB window in LCP addressing space. To do that I modified cache_as_ram_main function in order to write 0xF4 to I/O port 0x88:
void cache_as_ram_main(void) { outb(0xF4, 0x88); ...
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
b) coreboot prints:
Before VSA: do_vsmbios buf ilen 1011820 olen949065 buf 00060000 *buf 255 buf[256k] 255 buf[0x20] signature is ff:ff:ff:ff do_vsmbios: no vsainit.bin signature, skipping! After VSA: Graphics init... VRC_VG value: 0xffff Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
I guess this isn't related to the dongle and it's 4MB mode, as that's just really useful post-BIOS at payload time, unless you are trying to fit the ROM into more than 1MB. But at a glance it seems like you don't have the VSA blob included in flash? Is this coreboot-v2 or coreboot-v3?
Anybody can help me?
Regards, Mart Raudsepp Artec Design LLC
...
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.
b) coreboot prints:
Before VSA: do_vsmbios buf ilen 1011820 olen949065 buf 00060000 *buf 255 buf[256k] 255 buf[0x20] signature is ff:ff:ff:ff do_vsmbios: no vsainit.bin signature, skipping! After VSA: Graphics init... VRC_VG value: 0xffff Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
I guess this isn't related to the dongle and it's 4MB mode, as that's just really useful post-BIOS at payload time, unless you are trying to fit the ROM into more than 1MB. But at a glance it seems like you don't have the VSA blob included in flash? Is this coreboot-v2 or coreboot-v3?
coreboot is v2 I suspect VSA blob is there but coreboot can't find it because it is stored where processor can't read because 4MB mode has not been enabled. Please note that ROM_SIZE in Config.lb has been changed like this:
option ROM_SIZE=4*1024*1024-36*1024
Is this correct?
Ühel kenal päeval, L, 2008-05-24 kell 16:10, 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.
b) coreboot prints:
Before VSA: do_vsmbios buf ilen 1011820 olen949065 buf 00060000 *buf 255 buf[256k] 255 buf[0x20] signature is ff:ff:ff:ff do_vsmbios: no vsainit.bin signature, skipping! After VSA: Graphics init... VRC_VG value: 0xffff Finding PCI configuration type. PCI: Sanity check failed pci_check_direct failed
I guess this isn't related to the dongle and it's 4MB mode, as that's just really useful post-BIOS at payload time, unless you are trying to fit the ROM into more than 1MB. But at a glance it seems like you don't have the VSA blob included in flash? Is this coreboot-v2 or coreboot-v3?
coreboot is v2 I suspect VSA blob is there but coreboot can't find it because it is stored where processor can't read because 4MB mode has not been enabled. Please note that ROM_SIZE in Config.lb has been changed like this:
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?
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.
Regards, Mart Raudsepp Artec Design LLC
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?
b) coreboot prints:
Before VSA:
... option ROM_SIZE=4*1024*1024-36*1024
Is this correct?
Two questions about this:
- 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.
- 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.
Ü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:
- 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.
- 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
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 0x1328 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 5f0 lb: [0x0000000000004000, 0x000000000001e000) Loading Segment: addr: 0x000000000f7b8000 memsz: 0x00000000000055c4 filesz: 0x00 00000000001328 [ 0x000000000f7b8000, 000000000f7b9328, 0x000000000f7bd5c4) <- 000000000000014c Clearing Segment: addr: 0x000000000f7b9328 memsz: 0x000000000000429c Loading Segment: addr: 0x0000000000020000 memsz: 0x0000000000001070 filesz: 0x00 00000000000000 [ 0x0000000000020000, 0000000000020000, 0x0000000000021070) <- 0000000000001474 Clearing Segment: addr: 0x0000000000020000 memsz: 0x0000000000001070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x00 000000000fe5f0 [ 0x0000000000100000, 00000000001fe5f0, 0x0000000000800000) <- 0000000000001474 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:
- 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.
- 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
Ühel kenal päeval, E, 2008-05-26 kell 15:47, kirjutas llandre:
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.
As you got 0x00 from post code logging, I'm assuming you had JMP4 in the correct position, as otherwise there would have been no power at all. Maybe your board is unable to give enough current to the dongle over LPC, so such funny things happen? Funny things can also happen (might also involve smoke, albeit unlikely), if you power over USB but forget the JMP4 in LPC power mode, so it gets power from both places. This is covered in the documentation.
Note that when dongle is only LPC powered you need to reset the mainboard for the dongle to do its initial LPC reads again after the logic configuration has been loaded into the FPGA (it takes longer than most mainboard would like, so by powering it on it does that, and the reset on mainboard side will do the read again, but now with FPGA already ready, as the LPC power isn't cut)
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
Ok, looks good from the dongle side. This is the topic I know about, for the rest others will have to chime in if you don't figure this out yourself.
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 0x1328 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 5f0 lb: [0x0000000000004000, 0x000000000001e000) Loading Segment: addr: 0x000000000f7b8000 memsz: 0x00000000000055c4 filesz: 0x00 00000000001328 [ 0x000000000f7b8000, 000000000f7b9328, 0x000000000f7bd5c4) <- 000000000000014c Clearing Segment: addr: 0x000000000f7b9328 memsz: 0x000000000000429c Loading Segment: addr: 0x0000000000020000 memsz: 0x0000000000001070 filesz: 0x00 00000000000000 [ 0x0000000000020000, 0000000000020000, 0x0000000000021070) <- 0000000000001474 Clearing Segment: addr: 0x0000000000020000 memsz: 0x0000000000001070 Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 filesz: 0x00 000000000fe5f0 [ 0x0000000000100000, 00000000001fe5f0, 0x0000000000800000) <- 0000000000001474 Clearing Segment: addr: 0x00000000001fe5f0 memsz: 0x0000000000601a10 Loaded segments Image checksum: 85c3 != computed checksum: 2705 Can not load ELF Image.
-
llandre -
Mart Raudsepp