On 10/18/2010 08:39 PM, Anthony Liguori wrote:
SeaBIOS rejects them when loaded from the rom bar and doesn't reject
them when loaded via fw_cfg.
What I meant was, rombar=0 in qdev. Sometimes my fingers don't work
the same way my brain does :-)
Are you using qmp or the human monitor
On 10/21/2010 05:09 AM, Avi Kivity wrote:
On 10/18/2010 08:39 PM, Anthony Liguori wrote:
SeaBIOS rejects them when loaded from the rom bar and doesn't reject
them when loaded via fw_cfg.
What I meant was, rombar=0 in qdev. Sometimes my fingers don't work
the same way my brain does :-)
On 10/21/2010 03:14 PM, Anthony Liguori wrote:
On 10/21/2010 05:09 AM, Avi Kivity wrote:
On 10/18/2010 08:39 PM, Anthony Liguori wrote:
SeaBIOS rejects them when loaded from the rom bar and doesn't
reject them when loaded via fw_cfg.
What I meant was, rombar=0 in qdev. Sometimes my
Hi,
+/* Don't patch a rom with wrong vendor id (might be changed if needed). */
+if (vendor_id != rom_vendor_id) {
+return;
+}
Yes, please drop that one. If this is accepted I'd like to use this for
vga roms too, so we have to carry only two of them instead of four.
+
On 10/15/10 23:05, Anthony Liguori wrote:
On 10/15/2010 03:51 PM, Stefan Weil wrote:
PCI device with different device ids sometimes share
the same rom code. Only the device id and the checksum
differ in a boot rom for such devices.
BTW, SeaBIOS doesn't reject ROMs when they're loaded via
Am 18.10.2010 12:04, schrieb Gerd Hoffmann:
Hi,
+/* Don't patch a rom with wrong vendor id (might be changed if
needed). */
+if (vendor_id != rom_vendor_id) {
+return;
+}
Yes, please drop that one. If this is accepted I'd like to use this for
vga roms too, so we have
Hi,
As far as I know there is no well-defined checksum offset.
The checksum is simply set by modifying any byte (which
normally should be unused).
Etherboot has some unused bytes at the beginning of rom data
and always uses the same offset 6.
Ah, so you don't actually update the checksum
Hi,
Am 18.10.2010 13:54, schrieb Gerd Hoffmann:
Hi,
As far as I know there is no well-defined checksum offset.
The checksum is simply set by modifying any byte (which
normally should be unused).
Etherboot has some unused bytes at the beginning of rom data
and always uses the same offset 6.
Hi,
When following this argumentation the vendor id sanity check shouldn't
be there in the first place ;)
The sanity check is simply there because I had no test case
which patches the vendor id. How could I test with vga bios?
No trivial way as the vgabios needs to be patched to handle
On 10/18/10 15:30, Gerd Hoffmann wrote:
Hi,
When following this argumentation the vendor id sanity check shouldn't
be there in the first place ;)
The sanity check is simply there because I had no test case
which patches the vendor id. How could I test with vga bios?
No trivial way as the
Am 18.10.2010 17:50, schrieb Gerd Hoffmann:
On 10/18/10 15:30, Gerd Hoffmann wrote:
Hi,
When following this argumentation the vendor id sanity check shouldn't
be there in the first place ;)
The sanity check is simply there because I had no test case
which patches the vendor id. How could
On 10/18/2010 05:09 AM, Gerd Hoffmann wrote:
On 10/15/10 23:05, Anthony Liguori wrote:
On 10/15/2010 03:51 PM, Stefan Weil wrote:
PCI device with different device ids sometimes share
the same rom code. Only the device id and the checksum
differ in a boot rom for such devices.
BTW, SeaBIOS
PCI device with different device ids sometimes share
the same rom code. Only the device id and the checksum
differ in a boot rom for such devices.
The i825xx ethernet controller family is a typical example
which is implemented in hw/eepro100.c. It uses at least
3 different device ids, so normally
On 10/15/2010 03:51 PM, Stefan Weil wrote:
PCI device with different device ids sometimes share
the same rom code. Only the device id and the checksum
differ in a boot rom for such devices.
BTW, SeaBIOS doesn't reject ROMs when they're loaded via rombar, only
when they're loaded via
14 matches
Mail list logo
