[SeaBIOS PATCH] usb: fix boot paths
by Paolo Bonzini
The fw paths for USB devices that SeaBIOS computes are off-by-one,
because QEMU builds those paths with a numbering that starts from one
(see usb_fill_port and usb_hub_initfn in QEMU). Fix that so that
the numbering agrees.
---
src/boot.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/boot.c b/src/boot.c
index 946850d..434bf80 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -205,9 +205,9 @@ int bootprio_find_usb(struct pci_device *pci, u64 path)
for (i=56; i>0; i-=8) {
int port = (path >> i) & 0xff;
if (port != 0xff)
- p += snprintf(p, desc+sizeof(desc)-p, "/hub@%x", port);
+ p += snprintf(p, desc+sizeof(desc)-p, "/hub@%x", port+1);
}
- snprintf(p, desc+sizeof(desc)-p, "/*@%x", (u32)(path & 0xff));
+ snprintf(p, desc+sizeof(desc)-p, "/*@%x", (u32)(path & 0xff)+1);
return find_prio(desc);
}
--
1.7.7.1
7 years, 9 months
[PATCH 00/16] make SCSI and virtio layers more generic, fix usb-msc bugs
by Paolo Bonzini
Hi all,
this are the preparatory bits for virtio-scsi support in SeaBIOS.
They mostly aim at making code more generic in SeaBIOS for both SCSI and
virtio, but (on the SCSI side) they also fix some bugs, so I'm sending
them early to get more exposure.
New features are mostly visible on the USB side since that's currently
the main consumer of the SCSI implementation. They include more robust
LUN detection, support for hard disk geometry, and USB mass storage
write support.
I also fixed for real the race that the RFC series was working around.
For virtio, the series adds a few extra interface bits that are common
to both virtio-scsi and virtio-blk.
The two parts are logically separate but they have a small conflict,
so I'm sending them together.
Paolo Bonzini (16):
cdrom: use TEST UNIT READY to detect ready medium
usb-uhci: reorganize wait_qh into wait_pipe
usb-uhci: fix race against host controller
usb-msc: support commands without payload
usb-msc: add usb_msc_send
usb-msc: support WRITE commands
usb-msc: move READ CAPACITY to usb_msc_init, fix off-by-one
usb-msc: pass drive to setup_drive_*
usb-msc: rename INQUIRY types
usb-msc: go through TEST UNIT READY for hard disks.
usb-msc: move common scsi code to blockcmd.c
usb-msc: move cdb dispatch to block.c
scsi: get physical chs geometry from mode page 0x04
always specify virtio-blk rather than virtio
virtio-pci: introduce vp_init_simple
virtio-pci: allocate vq in vp_find_vq
v1->v2:
do not send commands to CDs until they are actually selected for
boot; fix usb-uhci race for real; virtio-scsi driver not yet
included.
src/Kconfig | 4 +-
src/block.c | 34 ++++++++++--
src/blockcmd.c | 157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/blockcmd.h | 42 ++++++++++++++-
src/cdrom.c | 58 +-------------------
src/disk.c | 4 +-
src/disk.h | 18 +++---
src/usb-msc.c | 132 ++++++++++++++-------------------------------
src/usb-msc.h | 3 -
src/usb-uhci.c | 91 +++++++++++++++----------------
src/virtio-blk.c | 25 +++------
src/virtio-blk.h | 2 +-
src/virtio-pci.c | 33 ++++++++++--
src/virtio-pci.h | 3 +-
14 files changed, 364 insertions(+), 242 deletions(-)
--
1.7.7.1
7 years, 9 months
[PATCH 0/3] Additional USB fixes
by Kevin O'Connor
This series ports Paolo's uhci fixes to the ehci code. Unfortunately,
I'm still seeing an occasional hang with my flash drives on my e350m1
(ehci controller), so there's still some other bug lurking in the ehci
code.
I also noticed an error in the usb-uhci (missing GET_FLATPTR) which is
also in this series.
Kevin O'Connor (3):
usb-uhci: Be sure to wrap pipe->iobase in GET_FLATPTR().
usb-ehci: Convert ehci_wait_qh to ehci_wait_pipe.
usb-ehci: Fix race with host controller.
src/usb-ehci.c | 70 ++++++++++++++++++++++++-------------------------------
src/usb-uhci.c | 7 +++--
2 files changed, 35 insertions(+), 42 deletions(-)
--
1.7.6.4
7 years, 9 months
Booting from USB cdrom device doesn't work
by Sven Schnelle
Hi List,
i have seabios running on a Thinkpad T60 with coreboot and seabios as
Payload. When trying to boot from a USB cdrom, i get the following errors:
Booting from DVD/CD...
wait_td error - status=184007ff
uhci_send_bulk failed
USB transmission failed
wait_td error - status=184007ff
uhci_send_bulk failed
USB transmission failed
WARNING - Timeout at wait_td:427!
uhci_send_bulk failed
USB transmission failed
WARNING - Timeout at wait_td:427!
uhci_send_bulk failed
USB transmission failed
read capacity failed
atapi_is_ready returned -1
WARNING - Timeout at wait_td:427!
uhci_send_bulk failed
USB transmission failed
Boot failed: Could not read from CDROM (code 0003)
I have no knowledge about USB, so if anybody could
help me in interpreting those messages, or has an
other idea what the problem is, that would be great.
Thanks,
Sven
7 years, 9 months
[PATCH] USB-MSC: Support multiple LUN devices
by Sven Schnelle
Add suport for using USB storage devices with multiple LUNs.
One example for such a device is the HAGIWARA UDRW stick,
which has one LUN that simulates a cdrom device, and one
that acts like a disk device.
Signed-off-by: Sven Schnelle <svens(a)stackframe.org>
---
src/usb-msc.c | 146 +++++++++++++++++++++++++++++++++++++++-----------------
1 files changed, 101 insertions(+), 45 deletions(-)
diff --git a/src/usb-msc.c b/src/usb-msc.c
index deccf35..bf5dce8 100644
--- a/src/usb-msc.c
+++ b/src/usb-msc.c
@@ -16,6 +16,7 @@
struct usbdrive_s {
struct drive_s drive;
struct usb_pipe *bulkin, *bulkout;
+ int lun;
};
@@ -53,14 +54,32 @@ usb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize)
if (!CONFIG_USB_MSC)
return 0;
-restart:
- dprintf(16, "usb_cmd_data id=%p write=%d count=%d bs=%d buf=%p\n"
- , op->drive_g, 0, op->count, blocksize, op->buf_fl);
struct usbdrive_s *udrive_g = container_of(
op->drive_g, struct usbdrive_s, drive);
struct usb_pipe *bulkin = GET_GLOBAL(udrive_g->bulkin);
struct usb_pipe *bulkout = GET_GLOBAL(udrive_g->bulkout);
struct cdbres_request_sense sense;
+ int lun = GET_GLOBAL(udrive_g->lun);
+ unsigned char *data = (unsigned char *)cdbcmd;
+
+restart:
+ dprintf(16, "usb_cmd_data lun=%d id=%p write=%d count=%d bs=%d buf=%p\n"
+ , lun, op->drive_g, 0, op->count, blocksize, op->buf_fl);
+
+ /* some SCSI commands have the LUN in CDB */
+ if (data[0] == 0x08 || // READ(6)
+ data[0] == 0x12 || // INQUIRY
+ data[0] == 0x15 || // MODE SELECT(6)
+ data[0] == 0x55 || // MODE SELECT(10)
+ data[0] == 0x1A || // MODE SENSE(6)
+ data[0] == 0x28 || // READ(10)
+ data[0] == 0x1B || // START STOP UNIT(6)
+ data[0] == 0x25 || // READ CAPACITY
+ data[0] == 0x03 // REQUEST SENSE
+ ) {
+ data[1] &= ~0x10;
+ data[1] |= (lun & 7) << 5;
+ }
// Setup command block wrapper.
u32 bytes = blocksize * op->count;
@@ -70,7 +89,7 @@ restart:
cbw.dCBWTag = 999; // XXX
cbw.dCBWDataTransferLength = bytes;
cbw.bmCBWFlags = USB_DIR_IN; // XXX
- cbw.bCBWLUN = 0; // XXX
+ cbw.bCBWLUN = lun;
cbw.bCBWCBLength = USB_CDB_SIZE;
memcpy(cbw.CBWCB, cdbcmd, USB_CDB_SIZE);
@@ -199,44 +218,36 @@ setup_drive_hd(struct disk_op_s *op, char *desc)
return 0;
}
-// Configure a usb msc device.
-int
-usb_msc_init(struct usb_pipe *pipe
- , struct usb_interface_descriptor *iface, int imax)
+static int
+usb_msc_maxlun(struct usb_pipe *pipe, unsigned char *maxlun)
{
- if (!CONFIG_USB_MSC)
- return -1;
-
- // Verify right kind of device
- if ((iface->bInterfaceSubClass != US_SC_SCSI &&
- iface->bInterfaceSubClass != US_SC_ATAPI_8070 &&
- iface->bInterfaceSubClass != US_SC_ATAPI_8020)
- || iface->bInterfaceProtocol != US_PR_BULK) {
- dprintf(1, "Unsupported MSC USB device (subclass=%02x proto=%02x)\n"
- , iface->bInterfaceSubClass, iface->bInterfaceProtocol);
- return -1;
- }
+ struct usb_ctrlrequest req;
+ req.bRequestType = USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE;
+ req.bRequest = 0xfe;
+ req.wValue = 0;
+ req.wIndex = 0;
+ req.wLength = 1;
+ return send_default_control(pipe, &req, maxlun);
+}
+static int usb_msc_init_lun(struct usb_pipe *inpipe,
+ struct usb_pipe *outpipe,
+ struct usb_interface_descriptor *iface,
+ int lun)
+{
// Allocate drive structure.
struct usbdrive_s *udrive_g = malloc_fseg(sizeof(*udrive_g));
if (!udrive_g) {
- warn_noalloc();
- goto fail;
+ warn_noalloc();
+ return -1;
}
+
memset(udrive_g, 0, sizeof(*udrive_g));
udrive_g->drive.type = DTYPE_USB;
+ udrive_g->lun = lun;
- // Find bulk in and bulk out endpoints.
- struct usb_endpoint_descriptor *indesc = findEndPointDesc(
- iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_IN);
- struct usb_endpoint_descriptor *outdesc = findEndPointDesc(
- iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_OUT);
- if (!indesc || !outdesc)
- goto fail;
- udrive_g->bulkin = alloc_bulk_pipe(pipe, indesc);
- udrive_g->bulkout = alloc_bulk_pipe(pipe, outdesc);
- if (!udrive_g->bulkin || !udrive_g->bulkout)
- goto fail;
+ udrive_g->bulkin = inpipe;
+ udrive_g->bulkout = outpipe;
// Validate drive and find block size and sector count.
struct disk_op_s dop;
@@ -245,10 +256,10 @@ usb_msc_init(struct usb_pipe *pipe
struct cdbres_inquiry data;
int ret = cdb_get_inquiry(&dop, &data);
if (ret)
- goto fail;
+ goto fail;
if (cdb_start_stop_unit(&dop, 0, 1))
- goto fail;
+ goto fail;
char vendor[sizeof(data.vendor)+1], product[sizeof(data.product)+1];
char rev[sizeof(data.rev)+1];
@@ -261,24 +272,69 @@ usb_msc_init(struct usb_pipe *pipe
int pdt = data.pdt & 0x1f;
int removable = !!(data.removable & 0x80);
dprintf(1, "USB MSC vendor='%s' product='%s' rev='%s' type=%d removable=%d\n"
- , vendor, product, rev, pdt, removable);
+ , vendor, product, rev, pdt, removable);
udrive_g->drive.removable = removable;
if (pdt == USB_MSC_TYPE_CDROM) {
- char *desc = znprintf(MAXDESCSIZE, "DVD/CD [USB Drive %s %s %s]"
- , vendor, product, rev);
- ret = setup_drive_cdrom(&dop, desc);
+ char *desc = znprintf(MAXDESCSIZE, "DVD/CD [USB Drive %s %s %s]"
+ , vendor, product, rev);
+ ret = setup_drive_cdrom(&dop, desc);
} else {
- char *desc = znprintf(MAXDESCSIZE, "USB Drive %s %s %s"
- , vendor, product, rev);
- ret = setup_drive_hd(&dop, desc);
+ char *desc = znprintf(MAXDESCSIZE, "USB Drive %s %s %s"
+ , vendor, product, rev);
+ ret = setup_drive_hd(&dop, desc);
}
if (ret)
- goto fail;
+ goto fail;
return 0;
-fail:
- dprintf(1, "Unable to configure USB MSC device.\n");
+ fail:
free(udrive_g);
return -1;
}
+
+// Configure a usb msc device.
+int
+usb_msc_init(struct usb_pipe *pipe
+ , struct usb_interface_descriptor *iface, int imax)
+{
+ unsigned char maxlun, lun;
+
+ if (!CONFIG_USB_MSC)
+ return -1;
+
+ // Verify right kind of device
+ if ((iface->bInterfaceSubClass != US_SC_SCSI &&
+ iface->bInterfaceSubClass != US_SC_ATAPI_8070 &&
+ iface->bInterfaceSubClass != US_SC_ATAPI_8020)
+ || iface->bInterfaceProtocol != US_PR_BULK) {
+ dprintf(1, "Unsupported MSC USB device (subclass=%02x proto=%02x)\n"
+ , iface->bInterfaceSubClass, iface->bInterfaceProtocol);
+ return -1;
+ }
+
+ // Find bulk in and bulk out endpoints.
+ struct usb_endpoint_descriptor *indesc = findEndPointDesc(
+ iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_IN);
+ struct usb_endpoint_descriptor *outdesc = findEndPointDesc(
+ iface, imax, USB_ENDPOINT_XFER_BULK, USB_DIR_OUT);
+
+ if (!indesc || !outdesc)
+ return -1;
+
+ struct usb_pipe *inpipe = alloc_bulk_pipe(pipe, indesc);
+ if (!inpipe)
+ return -1;
+
+ struct usb_pipe *outpipe = alloc_bulk_pipe(pipe, outdesc);
+ if (!outpipe)
+ return -1;
+
+ if (usb_msc_maxlun(pipe, &maxlun))
+ maxlun = 0;
+
+ for (lun = 0; lun < maxlun+1; lun++)
+ usb_msc_init_lun(inpipe, outpipe, iface, lun);
+
+ return 0;
+}
--
1.7.7
7 years, 9 months
[RFC PATCH 00/16] make SCSI layer more generic, introduce virtio-scsi driver
by Paolo Bonzini
Hi all,
this is the first bit of working code for the mythical virtio-scsi
HBA. This patch mostly aims at making code more generic in SeaBIOS
for both SCSI and virtio.
For SCSI, it introduces common bits for LUN detection and fixes some
bugs. This is visible for example in that I can now boot the FreeDOS
image on bochs.sf.net from a USB drive.
For virtio, it adds a few extra interface bits that are common
to both virtio-scsi and virtio-blk.
The final patch adds the virtio-scsi code itself. I think the first 13
patches can go in before the virtio-scsi QEMU code, anyway I'm sending
now the whole batch for review.
Paolo Bonzini (16):
cdrom: use TEST UNIT READY to detect ready medium
usb-msc: add usb_msc_send
usb-uhci: wait tick after sending data
usb-msc: support WRITE and TEST UNIT READY
usb-msc: move READ CAPACITY to usb_msc_init, fix off-by-one
usb-msc: pass drive to setup_drive_*
usb-msc: rename INQUIRY types
usb-msc: always go through TEST UNIT READY
usb-msc: move common scsi code to blockcmd.c
scsi: get physical chs geometry from mode page 0x04
always specify virtio-blk rather than virtio
virtio-pci: introduce vp_init_simple
virtio-pci: allocate vq in vp_find_vq
virtio-pci: add vp_set
usb-msc: move cdb dispatch to block.c
add virtio-scsi driver
Makefile | 2 +-
src/Kconfig | 10 ++-
src/block.c | 35 +++++++--
src/blockcmd.c | 155 ++++++++++++++++++++++++++++++++++++++
src/blockcmd.h | 42 ++++++++++-
src/boot.c | 14 ++++
src/boot.h | 1 +
src/cdrom.c | 58 +--------------
src/disk.c | 5 +-
src/disk.h | 19 +++--
src/pci_ids.h | 1 +
src/post.c | 2 +
src/usb-msc.c | 132 ++++++++++----------------------
src/usb-msc.h | 3 -
src/usb-uhci.c | 1 +
src/virtio-blk.c | 30 +++-----
src/virtio-blk.h | 2 +-
src/virtio-pci.c | 33 +++++++-
src/virtio-pci.h | 13 +++-
src/virtio-scsi.c | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++
src/virtio-scsi.h | 43 +++++++++++
21 files changed, 620 insertions(+), 197 deletions(-)
create mode 100644 src/virtio-scsi.c
create mode 100644 src/virtio-scsi.h
--
1.7.7.1
7 years, 9 months
Re: [SeaBIOS] [Xen-devel] Re: [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820
by Keir Fraser
On 14/11/2011 19:25, "Julian Pidancet" <julian.pidancet(a)gmail.com> wrote:
> On Mon, Nov 14, 2011 at 1:23 PM, Keir Fraser <keir(a)xen.org> wrote:
>> On 14/11/2011 08:53, "Keir Fraser" <keir.xen(a)gmail.com> wrote:
>>
>>> On 14/11/2011 03:36, "Kevin O'Connor" <kevin(a)koconnor.net> wrote:
>>>
>>>> On Xen, the PCI init code isn't used, so assuming this struct doesn't
>>>> need to live in real "ram", I think it could live just about anywhere
>>>> past the end of ram. Even with pciinit.c, addresses over 0xfc00000
>>>> (with the exception of a few bytes for hpet, apic, ioapic, and bios
>>>> image) could be used.
>>>
>>> I suggest we stick it at FC000000, and shift hvmloader's mem_alloc()
>>> starting address up by one page to FC001000. The acpi build code will have
>>> to manually mem_hole_populate_ram() that one page before writing to it. This
>>> can then be documented in hvmloader/config.h which contains a description
>>> of, and defines for, the system memory map. This is by far the easiest
>>> solution to this problem; manually crafting an SSDT is a right pain in the
>>> arse, whereas this is maybe a 5-line patch.
>>
>> Like the attached patch (untested), which is a bit larger than anticipated,
>> but actually allows code to be net deleted. :-)
>>
>
> I just tested your patch with Windows 7 and Linux guest booted from iPXE.
>
> Everything seems to work fine. SeaBIOS reports the following e820:
>
> (XEN) HVM23: e820 map has 6 items:
> (XEN) HVM23: 0: 0000000000000000 - 000000000009f400 = 1 RAM
> (XEN) HVM23: 1: 000000000009f400 - 00000000000a0000 = 2 RESERVED
> (XEN) HVM23: 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
> (XEN) HVM23: 3: 0000000000100000 - 000000003f7ff000 = 1 RAM
> (XEN) HVM23: 4: 000000003f7ff000 - 000000003f800000 = 2 RESERVED
> (XEN) HVM23: 5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
>
> The ACPI code in Linux reports the right PCI memory window:
>
> [ 0.338966] PCI: Using host bridge windows from ACPI; if necessary,
> use "pci=nocrs" and report a bug
> [ 0.340000] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [ 0.341029] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7]
> [ 0.341965] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff]
> [ 0.342965] pci_root PNP0A03:00: host bridge window [mem
> 0x000a0000-0x000bffff]
> [ 0.343965] pci_root PNP0A03:00: host bridge window [mem
> 0xf0000000-0xfbffffff]
>
> Can you ship it ?
Done. Xen-unstable:24143
Thanks,
Keir
7 years, 9 months
Re: [SeaBIOS] [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820
by Kevin O'Connor
On Mon, Nov 14, 2011 at 02:48:28AM +0000, Julian Pidancet wrote:
> On Mon, Nov 14, 2011 at 2:09 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > Why does it have to be at a fixed location? What structure is
> > actually placed at this address?
>
> Xen's hvmloader automatically computes the size of the PCI memory and
> stores the PCI memory range adresses in that structure. It also
> provide information about wether some devices are present (uart, hpet,
> ect...). The ACPI code that we inject in the guest has the address of
> this structure hardcoded, and it contains some tricks to make the AML
> interpreter go read the values contained in it, and take action to
> expose the right information to the guest OS. Like the right PCI root
> window for example.
>
> I'm not at all an ACPI expert, I don't know if there's a better way to
> expose to the guest the right information.
Unfortunately, there aren't very many places to put a hardcoded
address. The safest thing is probably to dynamically generate an SSDT
with a pointer - then the DSDT can use the pointer instead of a
hardcoded address. This is more work, however.
> > The AML interpreter should be able to see all of ram, so that doesn't
> > seem like an issue.
>
> Like I said, I'm not an ACPI expert. But let say we decide to move
> this ACPI info structure to some other area, where there's less risk
> for it to be overwritten, like somewhere above 0xFC000000, wouldn't
> that prevent some Operating System with limited memory capabilities to
> access it ?
If the OS can handle AML it can handle 32bit addresses.
> Besides, it seems that SeaBIOS manages itself the space between
> 0xFC000000 and 4G, so it seems difficult to imagine to have a reserved
> space with a fixed address in there.
On Xen, the PCI init code isn't used, so assuming this struct doesn't
need to live in real "ram", I think it could live just about anywhere
past the end of ram. Even with pciinit.c, addresses over 0xfc00000
(with the exception of a few bytes for hpet, apic, ioapic, and bios
image) could be used.
-Kevin
7 years, 9 months
Re: [SeaBIOS] PCI Option ROM debugging with Coreboot+SeaBIOS (detailed steps)
by Darmawan Salihun
However, there is one area which it lacks. The PnP function supported
by SeaBIOS at the moment is only related to PXE boot.
-Darmawan
On 11/14/11, QingPei Wang <wangqingpei(a)gmail.com> wrote:
> you may need another firmware to do the init things of hardware which
> coreboot did
>
>
>
> Best wishes
> QingPei Wang
> Phone: 86+018930528086
>
>
> 2011/11/13 WangXiao <cw1501(a)hotmail.com>
>
>> That's a good way for debugging,
>>
>> ...I have a question, can SeaBIOS use on real board seperatly without
>> Coreboot?
>> Thanks!
>>
>> > Date: Sat, 12 Nov 2011 15:41:15 +0700
>> > From: darmawan.salihun(a)gmail.com
>> > To: coreboot(a)coreboot.org
>> > CC: seabios(a)seabios.org
>> > Subject: [SeaBIOS] PCI Option ROM debugging with Coreboot+SeaBIOS
>> (detailed steps)
>>
>> >
>> > I made a blogpost detailing the steps to debug PCI Option ROM with
>> > Coreboot+SeaBIOS and a GDB-server-compatible debugger:
>> >
>> > http://bioshacking.blogspot.com/search/label/PCI%20Option%20ROM
>> >
>> > Hopefully would help those in need because it takes quite a while to
>> > get it right.
>> > Thanks to Kevin O'Connor for the helps :-)
>> >
>> > Regards,
>> >
>> > Darmawan
>> > --
>> > --------------------------------------------------------------------
>> > -= Human knowledge belongs to the world =-
>> >
>> > _______________________________________________
>> > SeaBIOS mailing list
>> > SeaBIOS(a)seabios.org
>> > http://www.seabios.org/mailman/listinfo/seabios
>>
>> _______________________________________________
>> SeaBIOS mailing list
>> SeaBIOS(a)seabios.org
>> http://www.seabios.org/mailman/listinfo/seabios
>>
>>
>
--
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-
7 years, 9 months
Re: [SeaBIOS] [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820
by Kevin O'Connor
On Mon, Nov 14, 2011 at 02:03:38AM +0000, Julian Pidancet wrote:
> On Mon, Nov 14, 2011 at 1:11 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> >
> > That wont work reliably - SeaBIOS (and option roms) can grow the EBDA.
> > It's not realistic to put a whole in the middle of the first 640k.
> >
>
> When you say "grow" do you mean grow downwards ? Because if not, the
> ACPI info structure lives in 9F000, so there shouldn't be any problem
> reporting the 0-9F000 range as the memory size in the BDA.
Yes - the EBDA grows down. Both SeaBIOS itself can grow the EBDA (see
pmm.c:zonelow_expand) and option roms can grow the EBDA.
> > As above, this doesn't look right - SeaBIOS will still locate the EBDA
> > at 9fc00 and nothing will stop it from growing it over the 9f000 area.
> >
>
> The EBDA is a standard bios structure, can't we safely assume that
> it's size will hardly change ? If not, would you suggest that this
> ACPI info structure should be placed at a different location ? The
> problem with this is that it has to be in a location with a fixed
> address, and preferably in a location which is accessible by any AML
> interpreter.
Why does it have to be at a fixed location? What structure is
actually placed at this address?
The AML interpreter should be able to see all of ram, so that doesn't
seem like an issue.
-Kevin
7 years, 9 months