Patty,
For some devices, Coreboot has the ROM image in a section of the ROM. It copies that image to memory and passes a pointer to run_bios. Actually, right now Coreboot copies the ROMs to RAM for devices too. YABEL works when the ROM is accessible from the device (by ignoring the fact that Coreboot already copied it), but not in the case that Coreboot expects it to be run from RAM. Do you have any thoughts on how to handle this case?
Thanks, Myles
Myles Watson wrote:
Patty,
For some devices, Coreboot has the ROM image in a section of the ROM. It copies that image to memory and passes a pointer to run_bios. Actually, right now Coreboot copies the ROMs to RAM for devices too. YABEL works when the ROM is accessible from the device (by ignoring the fact that Coreboot already copied it), but not in the case that Coreboot expects it to be run from RAM. Do you have any thoughts on how to handle this case?
Thanks, Myles
We don't _have_ to copy it to RAM, it just never occurred to us that it shouldn't be. However, if we leave it on the ROM, don't we hit the same issue with the shadowed memory that we did with the shared functions a while back?
Jordan
-----Original Message----- From: Jordan Crouse [mailto:jordan@cosmicpenguin.net] Sent: Friday, December 19, 2008 9:48 AM To: Myles Watson Cc: Pattrick Hueper; Coreboot Subject: Re: [coreboot] YABEL and images in LAR files
Myles Watson wrote:
Patty,
For some devices, Coreboot has the ROM image in a section of the ROM.
It
copies that image to memory and passes a pointer to run_bios. Actually, right now Coreboot copies the ROMs to RAM for devices too. YABEL works
when
the ROM is accessible from the device (by ignoring the fact that
Coreboot
already copied it), but not in the case that Coreboot expects it to be
run
from RAM. Do you have any thoughts on how to handle this case?
Thanks, Myles
We don't _have_ to copy it to RAM, it just never occurred to us that it shouldn't be. However, if we leave it on the ROM, don't we hit the same issue with the shadowed memory that we did with the shared functions a
I think it needs to be copied to RAM. I was just wondering who should do that copy. YABEL doesn't have a way of knowing where to find the ROM for onboard devices that have their ROM images imbedded in a LAR file. That information isn't in the ROM BAR. That's why we pass the address to bios_run. Right now YABEL just ignores that address.
I was just trying to think of the cleanest way to handle the following cases: 1. The device is an add-in card with its own ROM. 2. The device is onboard and coreboot has the ROM image. 3. The device is an add-in card and coreboot wants to initialize it with a different ROM.
I know 3 is unusual, but it might be useful sometimes.
Thanks, Myles
Hi,
well following the BIOS spec (i think its somewhere in the PNP BIOS spec... i have to check... ) the BIOS copies the ROM to RAM... since YABEL uses its own "virtual" memory it _has_ to copy the ROM to its RAM... also some of the cards i have used do actually modify the memory where the ROM is stored, so it has to be in the virtual RAM.
Currently, the ROM is always copied from the Expansion ROM bar of PCI devices.... i havent had to initialize any onboard devices. If there is a parameter to run_bios that points to the location of the Option ROM i could pass that parameter to YABEL and only use the Expansion ROM BAR if that parameter is not set (null?). But IIRC i still have to copy it to the virtual memory.
If it helps coreboot to know where the Option ROM image is after execution of the ROM, i guess YABEL could return the location of the ROM (the length which could be changed during execution is part of the ROM, so coreboot could figure out how much to copy back if it decides to do so.
I am thinking of buying a x86 board to do coreboot development, i am wondering which one would be a good choice with regards to YABEL and maybe SEABIOS development? Any recommendations?
My requirements:
coreboot-v3 and preferably v2 "compatible" PCI and PCIe slots since Myles mentioned onboard devices with ROM in LAR that would be very interesting too... "affordable"
I am really unsure what else to look for... Flash Chip Types? Processor?
Cheers Patty
On Fri, Dec 19, 2008 at 6:05 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan@cosmicpenguin.net] Sent: Friday, December 19, 2008 9:48 AM To: Myles Watson Cc: Pattrick Hueper; Coreboot Subject: Re: [coreboot] YABEL and images in LAR files
Myles Watson wrote:
Patty,
For some devices, Coreboot has the ROM image in a section of the ROM.
It
copies that image to memory and passes a pointer to run_bios. Actually, right now Coreboot copies the ROMs to RAM for devices too. YABEL works
when
the ROM is accessible from the device (by ignoring the fact that
Coreboot
already copied it), but not in the case that Coreboot expects it to be
run
from RAM. Do you have any thoughts on how to handle this case?
Thanks, Myles
We don't _have_ to copy it to RAM, it just never occurred to us that it shouldn't be. However, if we leave it on the ROM, don't we hit the same issue with the shadowed memory that we did with the shared functions a
I think it needs to be copied to RAM. I was just wondering who should do that copy. YABEL doesn't have a way of knowing where to find the ROM for onboard devices that have their ROM images imbedded in a LAR file. That information isn't in the ROM BAR. That's why we pass the address to bios_run. Right now YABEL just ignores that address.
I was just trying to think of the cleanest way to handle the following cases:
- The device is an add-in card with its own ROM.
- The device is onboard and coreboot has the ROM image.
- The device is an add-in card and coreboot wants to initialize it with a
different ROM.
I know 3 is unusual, but it might be useful sometimes.
Thanks, Myles
On Fri, Dec 19, 2008 at 11:57 AM, Pattrick Hueper phueper@hueper.netwrote:
Hi,
well following the BIOS spec (i think its somewhere in the PNP BIOS spec... i have to check... ) the BIOS copies the ROM to RAM... since YABEL uses its own "virtual" memory it _has_ to copy the ROM to its RAM...
Yes. Right now there's just a redundant copy, since Coreboot copies it to RAM too.
also some of the cards i have used do actually modify the memory where the ROM is stored, so it has to be in the virtual RAM.
Currently, the ROM is always copied from the Expansion ROM bar of PCI devices.... i havent had to initialize any onboard devices. If there is a parameter to run_bios that points to the location of the Option ROM i could pass that parameter to YABEL and only use the Expansion ROM BAR if that parameter is not set (null?).
That's what I was thinking.
But IIRC i still have to copy it to the virtual memory.
Yes.
If it helps coreboot to know where the Option ROM image is after execution of the ROM, i guess YABEL could return the location of the ROM (the length which could be changed during execution is part of the ROM, so coreboot could figure out how much to copy back if it decides to do so.
I don't think Coreboot cares after the card is initialized.
I am thinking of buying a x86 board to do coreboot development, i am wondering which one would be a good choice with regards to YABEL and maybe SEABIOS development? Any recommendations?
My requirements:
coreboot-v3 and preferably v2 "compatible" PCI and PCIe slots since Myles mentioned onboard devices with ROM in LAR that would be very interesting too...
You can test even with an add-in card if you "pretend" its onboard. Then you can have coreboot give you a pointer to it and initialize it.
"affordable"
I am really unsure what else to look for... Flash Chip Types? Processor?
Socketed flash chip. Preferably compatible with a BIOS savior.
Thanks, Myles
On Fri, Dec 19, 2008 at 8:37 PM, Myles Watson mylesgw@gmail.com wrote:
well following the BIOS spec (i think its somewhere in the PNP BIOS spec... i have to check... ) the BIOS copies the ROM to RAM... since YABEL uses its own "virtual" memory it _has_ to copy the ROM to its RAM...
Yes. Right now there's just a redundant copy, since Coreboot copies it to RAM too.
true, but YABEL still has to copy it, after all the code runs from copy... can we modify coreboot to not copy the image from ROM if YABEL is selected, but pass the location of the image in ROM to YABEL?
...
Currently, the ROM is always copied from the Expansion ROM bar of PCI devices.... i havent had to initialize any onboard devices. If there is a parameter to run_bios that points to the location of the Option ROM i could pass that parameter to YABEL and only use the Expansion ROM BAR if that parameter is not set (null?).
That's what I was thinking.
Ok, i will try to implement that and send patches.
Cheers, Patty
-----Original Message----- From: Pattrick Hueper [mailto:phueper@hueper.net] Sent: Friday, December 19, 2008 1:38 PM To: Myles Watson Cc: jordan@cosmicpenguin.net; Coreboot Subject: Re: [coreboot] YABEL and images in LAR files
On Fri, Dec 19, 2008 at 8:37 PM, Myles Watson mylesgw@gmail.com wrote:
well following the BIOS spec (i think its somewhere in the PNP BIOS spec... i have to check... ) the BIOS copies the ROM to RAM... since YABEL uses its own "virtual" memory it _has_ to copy the ROM to its RAM...
Yes. Right now there's just a redundant copy, since Coreboot copies it
to
RAM too.
true, but YABEL still has to copy it, after all the code runs from copy... can we modify coreboot to not copy the image from ROM if YABEL is selected, but pass the location of the image in ROM to YABEL?
...
Currently, the ROM is always copied from the Expansion ROM bar of PCI devices.... i havent had to initialize any onboard devices. If there is a parameter to run_bios that points to the location of the Option ROM i could pass that parameter to YABEL and only use the Expansion ROM BAR if that parameter is not set (null?).
That's what I was thinking.
Ok, i will try to implement that and send patches.
That would be great. Once that's done I think I'll try YABEL on a "factory" BIOS from inside Coreboot. Qemu would be an easy place to try that.
Thanks, Myles
Hi, On Sat, Dec 20, 2008 at 2:44 PM, Myles Watson mylesgw@gmail.com wrote:
That would be great. Once that's done I think I'll try YABEL on a "factory" BIOS from inside Coreboot. Qemu would be an easy place to try that.
here is the patch that should use the address that coreboot passes, unless that address is 0, then the ExpROM BAR address is used.
Subject: [PATCH] use the rom_addr passed by coreboot, needed for ROM images from LAR
Signed-off-by: Pattrick Hueper phueper@hueper.net --- util/x86emu/yabel/biosemu.c | 11 +++++++++-- util/x86emu/yabel/compat/functions.c | 4 ++-- util/x86emu/yabel/device.c | 22 +++++++++++++--------- util/x86emu/yabel/device.h | 2 +- 4 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/util/x86emu/yabel/biosemu.c b/util/x86emu/yabel/biosemu.c index 7e92fde..cc11c0f 100644 --- a/util/x86emu/yabel/biosemu.c +++ b/util/x86emu/yabel/biosemu.c @@ -43,8 +43,15 @@ static X86EMU_pioFuncs my_pio_funcs = {
void dump(u8 * addr, u32 len);
+/* main entry into YABEL biosemu, arguments are: + * *biosmem = pointer to virtual memory + * biosmem_size = size of the virtual memory + * *dev = pointer to the device to be initialised + * rom_addr = address of the OptionROM to be executed, if this is = 0, YABEL + * will look for an ExpansionROM BAR and use the code from there. + */ u32 -biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev) +biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev, unsigned long rom_addr) { u8 *rom_image; int i = 0; @@ -60,7 +67,7 @@ biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev) printf("Error initializing device!\n"); return -1; } - if (biosemu_dev_check_exprom() != 0) { + if (biosemu_dev_check_exprom(rom_addr) != 0) { printf("Error: Device Expansion ROM invalid!\n"); return -1; } diff --git a/util/x86emu/yabel/compat/functions.c b/util/x86emu/yabel/compat/functions.c index c1a6d9a..33c9115 100644 --- a/util/x86emu/yabel/compat/functions.c +++ b/util/x86emu/yabel/compat/functions.c @@ -15,11 +15,11 @@ u8* vmem = (u8 *) CONFIG_YABEL_VIRTMEM_LOCATION; u8* vmem = (u8 *) (16*1024*1024); /* default to 16MB */ #endif
-u32 biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev); +u32 biosemu(u8 *biosmem, u32 biosmem_size, struct device * dev, unsigned long rom_addr);
void run_bios(struct device * dev, unsigned long addr) { - biosemu(vmem, VMEM_SIZE, dev); + biosemu(vmem, VMEM_SIZE, dev, addr); }
u64 get_time(void) diff --git a/util/x86emu/yabel/device.c b/util/x86emu/yabel/device.c index ab4e7a2..0a0e00f 100644 --- a/util/x86emu/yabel/device.c +++ b/util/x86emu/yabel/device.c @@ -282,21 +282,25 @@ biosemu_dev_get_device_vendor_id(void) }
/* check, wether the device has a valid Expansion ROM, also search the PCI Data Structure and - * any Expansion ROM Header (using dev_scan_exp_header()) for needed information */ + * any Expansion ROM Header (using dev_scan_exp_header()) for needed information + * if the rom_addr parameter is != 0, it is the address of the Expansion ROM image and will be + * used, if it is == 0, the Expansion ROM BAR address will be used + */ u8 -biosemu_dev_check_exprom() +biosemu_dev_check_exprom(unsigned long rom_base_addr) { int i = 0; translate_address_t ta; - unsigned long rom_base_addr = 0; u16 pci_ds_offset; pci_data_struct_t pci_ds; - // check for ExpROM Address (Offset 30) in taa - for (i = 0; i <= taa_last_entry; i++) { - ta = translate_address_array[i]; - if (ta.cfg_space_offset == 0x30) { - rom_base_addr = ta.address + ta.address_offset; //translated address - break; + if (rom_base_addr == 0) { + // check for ExpROM Address (Offset 30) in taa + for (i = 0; i <= taa_last_entry; i++) { + ta = translate_address_array[i]; + if (ta.cfg_space_offset == 0x30) { + rom_base_addr = ta.address + ta.address_offset; //translated address + break; + } } } // in the ROM there could be multiple Expansion ROM Images... start searching diff --git a/util/x86emu/yabel/device.h b/util/x86emu/yabel/device.h index 09c7710..0f1680c 100644 --- a/util/x86emu/yabel/device.h +++ b/util/x86emu/yabel/device.h @@ -115,7 +115,7 @@ extern biosemu_device_t bios_device;
u8 biosemu_dev_init(struct device * device); // NOTE: for dev_check_exprom to work, biosemu_dev_init MUST be called first! -u8 biosemu_dev_check_exprom(void); +u8 biosemu_dev_check_exprom(unsigned long rom_base_addr);
u8 biosemu_dev_translate_address(unsigned long * addr);
here is the patch that should use the address that coreboot passes, unless that address is 0, then the ExpROM BAR address is used.
Subject: [PATCH] use the rom_addr passed by coreboot, needed for ROM images from LAR
Signed-off-by: Pattrick Hueper phueper@hueper.net
Acked-by: Myles Watson mylesgw@gmail.com
Rev 1081. I did some very minor cleanup of comments and white space.
Thanks, Myles
On Fri, Dec 19, 2008 at 1:57 PM, Pattrick Hueper phueper@hueper.net wrote:
Hi,
well following the BIOS spec (i think its somewhere in the PNP BIOS spec... i have to check... ) the BIOS copies the ROM to RAM... since YABEL uses its own "virtual" memory it _has_ to copy the ROM to its RAM... also some of the cards i have used do actually modify the memory where the ROM is stored, so it has to be in the virtual RAM.
Currently, the ROM is always copied from the Expansion ROM bar of PCI devices.... i havent had to initialize any onboard devices. If there is a parameter to run_bios that points to the location of the Option ROM i could pass that parameter to YABEL and only use the Expansion ROM BAR if that parameter is not set (null?). But IIRC i still have to copy it to the virtual memory.
If it helps coreboot to know where the Option ROM image is after execution of the ROM, i guess YABEL could return the location of the ROM (the length which could be changed during execution is part of the ROM, so coreboot could figure out how much to copy back if it decides to do so.
I am thinking of buying a x86 board to do coreboot development, i am wondering which one would be a good choice with regards to YABEL and maybe SEABIOS development? Any recommendations?
My requirements:
coreboot-v3 and preferably v2 "compatible" PCI and PCIe slots since Myles mentioned onboard devices with ROM in LAR that would be very interesting too... "affordable"
I am really unsure what else to look for... Flash Chip Types? Processor?
Cheers Patty
A used i810 board? You can get the for next to nothing off ebay, they're fairly simple to port (almost every possible super io is supported), have onboard video and pci for an expansion card, and the onboard video works in v2 now, iirc. No v3 support though. You can get a Jetway J2F2-series for around $100, that board is in v2 working well and is almost booting linux in v3. The downside is that the video BIOS in that one is very picky, I had to copy BOCHS to 0xf0000 and run it with vm86 in v2.
-Corey
On Fri, Dec 19, 2008 at 6:05 PM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: Jordan Crouse [mailto:jordan@cosmicpenguin.net] Sent: Friday, December 19, 2008 9:48 AM To: Myles Watson Cc: Pattrick Hueper; Coreboot Subject: Re: [coreboot] YABEL and images in LAR files
Myles Watson wrote:
Patty,
For some devices, Coreboot has the ROM image in a section of the ROM.
It
copies that image to memory and passes a pointer to run_bios.
Actually,
right now Coreboot copies the ROMs to RAM for devices too. YABEL
works
when
the ROM is accessible from the device (by ignoring the fact that
Coreboot
already copied it), but not in the case that Coreboot expects it to be
run
from RAM. Do you have any thoughts on how to handle this case?
Thanks, Myles
We don't _have_ to copy it to RAM, it just never occurred to us that it shouldn't be. However, if we leave it on the ROM, don't we hit the same issue with the shadowed memory that we did with the shared functions a
I think it needs to be copied to RAM. I was just wondering who should do that copy. YABEL doesn't have a way of knowing where to find the ROM for onboard devices that have their ROM images imbedded in a LAR file. That information isn't in the ROM BAR. That's why we pass the address to bios_run. Right now YABEL just ignores that address.
I was just trying to think of the cleanest way to handle the following cases:
- The device is an add-in card with its own ROM.
- The device is onboard and coreboot has the ROM image.
- The device is an add-in card and coreboot wants to initialize it with
a
different ROM.
I know 3 is unusual, but it might be useful sometimes.
Thanks, Myles
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Dec 19, 2008 at 8:52 PM, Corey Osgood corey.osgood@gmail.com wrote:
A used i810 board? You can get the for next to nothing off ebay, they're fairly simple to port (almost every possible super io is supported), have onboard video and pci for an expansion card, and the onboard video works in v2 now, iirc. No v3 support though.
No, i do want v3 support...
You can get a Jetway J2F2-series for around $100, that board is in v2 working well and is almost booting linux in v3. The downside is that the video BIOS in that one is very picky, I had to copy BOCHS to 0xf0000 and run it with vm86 in v2.
Heh... cool... that sounds like a good test case for YABEL ;-) Do i need to watch out for anything else, do they always come with socketed flash chips?
Should i get one of those boards, what would be the best type of replacement flash chip?
Patty
On Fri, Dec 19, 2008 at 9:12 PM, Pattrick Hueper phueper@hueper.net wrote:
You can get a Jetway J2F2-series for
Hm, cant find a J2F2... looking at the supported mainboards page, did you mean a J7F2??
Cheers, Patty
On Fri, Dec 19, 2008 at 3:17 PM, Pattrick Hueper phueper@hueper.net wrote:
On Fri, Dec 19, 2008 at 9:12 PM, Pattrick Hueper phueper@hueper.net wrote:
You can get a Jetway J2F2-series for
Hm, cant find a J2F2... looking at the supported mainboards page, did you mean a J7F2??
Cheers, Patty
Yep, that's what I meant.
For flash chips, it works with the BIOS Savior RD1-PMC4 or RD1-LPC8, that's PMC49FL004 and Winbond 39V080A chips. The stock BIOS chip, Winbond 39V040BPZ, doesn't program correctly on this board, I've now owned two board with the same exact chip and it hasn't worked on either one. Don't try to flash it, don't ever flash it, or you'll need to buy a programmer to fix it. SST49LF040/080 should also work, but I don't know for sure.
-Corey
On 19.12.2008 21:28, Corey Osgood wrote:
On Fri, Dec 19, 2008 at 3:17 PM, Pattrick Hueper phueper@hueper.net wrote:
On Fri, Dec 19, 2008 at 9:12 PM, Pattrick Hueper phueper@hueper.net wrote:
You can get a Jetway J2F2-series for
Hm, cant find a J2F2... looking at the supported mainboards page, did you mean a J7F2??
Cheers, Patty
Yep, that's what I meant.
For flash chips, it works with the BIOS Savior RD1-PMC4 or RD1-LPC8, that's PMC49FL004 and Winbond 39V080A chips. The stock BIOS chip, Winbond 39V040BPZ, doesn't program correctly on this board, I've now owned two board with the same exact chip and it hasn't worked on either one. Don't try to flash it, don't ever flash it, or you'll need to buy a programmer to fix it.
Yes indeed. I had the same problem.
SST49LF040/080 should also work, but I don't know for sure.
If you want a v3 supported board, I suggest an PCEngines Alix1C which has a PCI slot, but the interactions with VSA might be a problem for YABEL.
OTOH, my Asus M2A-VM works in v2 (with one patch) and somewhat matching code is in v3 and could probably be made to work in relatively short time. It has onboard graphics with a graphics ROM inside onboard BIOS flash. The benefit of this board is really good chipset documentation and a very responsive chipset manufacturer.
Regards, Carl-Daniel
On Wed, Dec 24, 2008 at 7:33 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
OTOH, my Asus M2A-VM works in v2 (with one patch) and somewhat matching code is in v3 and could probably be made to work in relatively short
Hm, interesting, does it have a flashchip in a socket?
Patty
On 25.12.2008 00:49, Pattrick Hueper wrote:
On Wed, Dec 24, 2008 at 7:33 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
OTOH, my Asus M2A-VM works in v2 (with one patch) and somewhat matching code is in v3 and could probably be made to work in relatively short
Hm, interesting, does it have a flashchip in a socket?
No, but IIRC you can use top hat flash to emulate that.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Corey Osgood -
Jordan Crouse -
Myles Watson -
Pattrick Hueper -
Peter Stuge