Hi,
I'm a new subscriber to seabios.org. Not much exp. with mailing lists nor C++, so feel free to straighten me out as
necessary. I found out an issue: Booting from CD-ROM doesn't work anymore, though related make options have been set. I
tried to debug it a little bit. To me it looks that order changes related to media sensing/capacity request broke it up.
In 1.6.3, cdb_read_capacity(line 204 in src/cdrom.c) takes place before cdb_get_sense(line 209) resulting in a break.
In current revision, this has been changed, has it?
cdrom_boot(src/cdrom.cline 188) calls scsi_is_ready(line 197), which looks similar to atapi_is_ready from 1.6.3/src/cdrom.c.
However: scsi_is_ready is missing
struct cdbres_read_capacity info;
ret = cdb_read_capacity(op, &info);
if (!ret)
// Success
break;
contrary to 1.6.3. In line cdb_get_sense returns 0xC with a medium in the drive, but this seems to result into an
endless loop due to continue;
For me, I added above snippet to blockcmd.c right before ret = cdb_get_sense(..) and it worked.
Later CD-ROM boots using boot managers(e.g. grub4dos or PloP) work fine without changes, though.
Debugging was done in Qemu 1.0.1. Since I'm on Windows, I used this build:
http://lassauge.free.fr/qemu/release/Qemu-1.0.1-windows.zip
Please confirm or advise.
Kind Regards,
fellaw
On Wed, Mar 21, 2012 at 10:50:17PM +0100, Nils wrote:
> Op zaterdag 10-03-2012 om 14:05 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > It looks pretty clear that the controller doesn't like 9-segment nor
> > e-segment addresses. You could try "malloc_low() - 0x50000" to see
> > how the controller likes 4-segment address, but basically the only
> > hope of getting this to work is to see if you can fix the controller.
> I studied the datasheets and tried different things but had no result.
>
> Then i tried "malloc_low() - 0x100" and the controller seems to work.
>
> Could it be that some SeaBIOS parts overlap at LOWRAM_END ?
> ( ohci controller and (E)BDA ?)
The logs pretty clearly indicate that the ram is in the 9-segment and
not the a-segment. It may be a hardware bug that confuses addresses
that are close.
> Do you have any suggestions ?
>
> Attached log from latest git + debugging patch and log from same code
> but with "malloc_low() - 0x100" .
If it's just a 256 byte offset, you can add a "malloc_low(256)" to the
top of usb.c:usb_setup() to reserve the troublesome addresses. Note
though, the e-segment values we tested before seem to be also
impacted. I have a vague plan to change SeaBIOS in the future to use
e-segment addresses instead of 9-segment addresses.
-Kevin
Hi,
This patch series redesigns the existing pciinit.c code and introduces
linked list operations.
Changes are more about structures definitions rather than functionality.
There are no more arrays of bases and counts in new implementation. The
new implementation is based on dynamic allocation of pci_region_entry
structures.
Each pci_region_entry structure could be a PCI bar or a downstream PCI
region (bridge). Each entry has a set of attributes: type (IO, MEM,
PREFMEM), is64bit, size, base address, PCI device owner, and a
pointer to the pci_bus it belongs to.
Also this series introduces list head operations which could be quite
handy not only for pciinit.c code but for post memory manager and thread
operations.
The patch series includes 3 patches.
1. Introduce List operations
2. Add pci_region_entry and linked lists operations in place while still
using the array system to do the allocations.
3. Switch to lists operations
4. Delete old code. (3 & 4 are split for better readability)
5. Get rid of size element from bus->r structure, now we use entry->size
for the same purpose
6. Make use of list operations in pmm.c and stack.c
src/pciinit.c | 270 ++++++++++++++++++++++++++-------------------------------
src/pmm.c | 29 ++----
src/stacks.c | 8 +--
src/util.h | 32 +++++++
4 files changed, 165 insertions(+), 174 deletions(-)
P/s
It is basically the same functionality as in previous version. I just
split commit in more pieces to make the changes to be as obvious as
possible.
On 2012-02-27 10:51, Daniel P. Berrange wrote:
> I'm seeing current QEMU GIT fail to boot MS-Dos 6.22 with the following
> crash:
>
> # qemu-system-x86_64 -fda ~/MS-DOS\ 6.22.img -m 1 -curses
> iPXE v1.0.0-591-g7aee315
> iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+00000000+00000000 C900
>
> Booting from Floppy..
> . qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000001000effff
>
> EAX=ffffffff EBX=ffffffff ECX=0000c934 EDX=00000068
> ESI=00006801 EDI=00000000 EBP=0000002b ESP=0000fff5
> EIP=ffffffff EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0040 00000400 0000ffff 00009300
> CS =f000 000f0000 0000ffff 00009b00
> SS =9ec4 0009ec40 0000ffff 00009300
> DS =9ec4 0009ec40 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT= 000fcd78 00000037
> IDT= 00000000 000003ff
> CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> CCS=000000d0 CCD=00000068 CCO=SARL
> EFER=0000000000000000
> FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
> FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
> XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
> XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
> XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
> XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
> Aborted
>
>
> Git bisect blames this
>
> commit 41bd360325168b3c1db78eb7311420a1607d521f
> Author: Jan Kiszka <jan.kiszka(a)siemens.com>
> Date: Sun Jan 15 17:48:25 2012 +0100
>
> seabios: Update to release 1.6.3.1
>
> User visible changes in seabios:
> - Probe HPET existence (fix for -no-hpet)
> - Probe PCI existence (fix for -machine isapc)
> - usb: fix boot paths
>
> Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
>
>
> I tried to bisect Seabios, but every revision in Seabios upstream works
> fine.
>
> Then I noticed, that if I rebuild the BIOS, from the exact same revision
> 1.6.3.1 revision that is committed in 'seabios' submodule in QEMU, then
> it works fine. So AFAICT, it is not the Seabios source code at fault,
> but rather the binary build we have commited to GIT. Should/can we rebuild
> the bios.bin in GIT ?
Probably not without understanding what causes this strange
inconsistency. If Seabios builds without errors and then later on fails,
this is also a bug.
Kevin, what information do you need to assess my tool chain?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
On Wed, Mar 14, 2012 at 01:02:39PM -0600, Steve Goodrich wrote:
> I've been working with coreboot and SeaBIOS lately to try to get a platform
> working, including having boot capability using an SD-to-USB adapter. I got
> stuck on this last part: the USB/SD adapter would start enumeration, but
> would fail out during TEST_UNIT_READY because the device came back with a
> STALL (this via a LeCroy/CACT USB analyzer). I compared the transactions to
> those done during USB enumeration/configuration in Linux, and I noticed that
> the Direction bit in bmCBWFlags is *cleared* for the TEST_UNIT_READY command
> in Linux, but *set* in coreboot.
If Linux always clears the direction bit for zero length transfers,
then I think it should be safe to do that in SeaBIOS also. How about
the patch below?
-Kevin
>From 1fd9a89082b807a4bb4ab6ce1285df474cb75746 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor <kevin(a)koconnor.net>
Date: Wed, 14 Mar 2012 21:27:45 -0400
Subject: [PATCH] Use OUT mode for all zero byte "scsi" transfers.
Some devices can get confused if asked to "read" data during a zero
byte transfer, so consider these transfers as "writes". (Reported by
Steve Goodrich.)
Also, extract out the code to determine the transfer direction into
cdb_is_read().
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/blockcmd.c | 7 +++++++
src/blockcmd.h | 1 +
src/usb-msc.c | 4 ++--
src/virtio-scsi.c | 7 ++++---
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/blockcmd.c b/src/blockcmd.c
index 8d881a5..2dda04d 100644
--- a/src/blockcmd.c
+++ b/src/blockcmd.c
@@ -35,6 +35,13 @@ cdb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize)
}
}
+// Determine if the command is a request to pull data from the device
+int
+cdb_is_read(u8 *cdbcmd, u16 blocksize)
+{
+ return blocksize && cdbcmd[0] != CDB_CMD_WRITE_10;
+}
+
int
scsi_is_ready(struct disk_op_s *op)
{
diff --git a/src/blockcmd.h b/src/blockcmd.h
index ccfeeaf..8459d3e 100644
--- a/src/blockcmd.h
+++ b/src/blockcmd.h
@@ -100,6 +100,7 @@ struct cdbres_mode_sense_geom {
} PACKED;
// blockcmd.c
+int cdb_is_read(u8 *cdbcmd, u16 blocksize);
int cdb_get_inquiry(struct disk_op_s *op, struct cdbres_inquiry *data);
int cdb_get_sense(struct disk_op_s *op, struct cdbres_request_sense *data);
int cdb_test_unit_ready(struct disk_op_s *op);
diff --git a/src/usb-msc.c b/src/usb-msc.c
index dadb9ca..c53a1f5 100644
--- a/src/usb-msc.c
+++ b/src/usb-msc.c
@@ -77,13 +77,13 @@ usb_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize)
cbw.dCBWSignature = CBW_SIGNATURE;
cbw.dCBWTag = 999; // XXX
cbw.dCBWDataTransferLength = bytes;
- cbw.bmCBWFlags = (cbw.CBWCB[0] == CDB_CMD_WRITE_10) ? USB_DIR_OUT : USB_DIR_IN;
+ cbw.bmCBWFlags = cdb_is_read(cdbcmd, blocksize) ? USB_DIR_IN : USB_DIR_OUT;
cbw.bCBWLUN = 0; // XXX
cbw.bCBWCBLength = USB_CDB_SIZE;
// Transfer cbw to device.
int ret = usb_msc_send(udrive_g, USB_DIR_OUT
- , MAKE_FLATPTR(GET_SEG(SS), &cbw), sizeof(cbw));
+ , MAKE_FLATPTR(GET_SEG(SS), &cbw), sizeof(cbw));
if (ret)
goto fail;
diff --git a/src/virtio-scsi.c b/src/virtio-scsi.c
index 3c59438..50339d7 100644
--- a/src/virtio-scsi.c
+++ b/src/virtio-scsi.c
@@ -31,7 +31,7 @@ struct virtio_lun_s {
static int
virtio_scsi_cmd(u16 ioaddr, struct vring_virtqueue *vq, struct disk_op_s *op,
- void *cdbcmd, u16 target, u16 lun, u32 len)
+ void *cdbcmd, u16 target, u16 lun, u16 blocksize)
{
struct virtio_scsi_req_cmd req;
struct virtio_scsi_resp_cmd resp;
@@ -44,7 +44,8 @@ virtio_scsi_cmd(u16 ioaddr, struct vring_virtqueue *vq, struct disk_op_s *op,
req.lun[3] = (lun & 0xff);
memcpy(req.cdb, cdbcmd, 16);
- int datain = (req.cdb[0] != CDB_CMD_WRITE_10);
+ u32 len = op->count * blocksize;
+ int datain = cdb_is_read(cdbcmd, blocksize);
int data_idx = (datain ? 2 : 1);
int out_num = (datain ? 1 : 2);
int in_num = (len ? 3 : 2) - out_num;
@@ -89,7 +90,7 @@ virtio_scsi_cmd_data(struct disk_op_s *op, void *cdbcmd, u16 blocksize)
return virtio_scsi_cmd(GET_GLOBAL(vlun->ioaddr),
GET_GLOBAL(vlun->vq), op, cdbcmd,
GET_GLOBAL(vlun->target), GET_GLOBAL(vlun->lun),
- blocksize * op->count);
+ blocksize);
}
static int
--
1.7.6.5
All,
I'm seeing another USB issue with our platform(s). I've been following the
other active USB mail list issue "usb ohci pipe free fix" but don't exactly
know where that one started. I'm only guessing that this could be related.
The description of my h/w setup is ...
- AMD/Persimmon platform (also observed failure on IEI/Kino)
- USB thumbdrive with GRUB (menu options for Ubuntu,memtest86,etc)
- USB wireless keyboard/mouse (also observed failure with wired USB keyboard)
I using the SeaBIOS master source.
The failure occurs when the system boots up to the GRUB menu. If I let the menu timeout
it will boot the default option which is Ubuntu. If I hit the <Enter> key the system
will lock-up with no output on the debug COM port. If at the GRUB menu and I <down arrow>
to the memtest86 option, it will sometimes work and sometimes lockup.
I then changed the SeaBIOS debug message level to 8. Then at the point where I hit <ENTER>
for the default GRUB option. I will see several debug messages indicating traffic related
to the USB thumbdrive and then never ending "handle_hwpic1 irq=0" messages.
Then as I was browsing through the usb code I noticed that some of the keyboard messages only
occur at level 9, so I set the level to 9 and all of my booting failures went away. ?.
I tracked the message that was somehow fixing my problem down to the file usb-hid.c, in ftn
handle_key() (~line 216). If I change that "dprintf(9,..." to "dprintf(1,...", and change
the debug message level down below 9, everything still works.
So the delay due to that one debug message fixes some issue related to using a USB keyboard
and thumbdrive at the same time. I don't see this issue if I use a SATA drive instead of the
USB thumbdrive. Our in-house USB guru (whose not familiar with coreboot) suggests it could be
an issue with the OHCI stack.
Does anybody have any suggestions on what this could be?
Or where I should start looking?
thanks in advance,
Dave
On 03/16/2012 03:09 PM, Vasilis Liaskovitis wrote:
> Hi,
>
> On Thu, Mar 15, 2012 at 02:01:38PM +0200, Gleb Natapov wrote:
>> Commenting a little bit late, but since you've said that you are working on
>> a new version of the patch... better late than never.
>>
>> On Thu, Aug 11, 2011 at 04:39:38PM +0200, Vasilis Liaskovitis wrote:
>>> Hi,
>>>
>>> I am testing a set of experimental patches for memory-hotplug on x86_64 host /
>>> guest combinations. I have implemented this in a similar way to cpu-hotplug.
>>>
>>> A dynamic SSDT table with all memory devices is created at boot time. This
>>> table calls static methods from the DSDT. A byte array indicates which memory
>>> device is online or not. This array is kept in sync with a qemu-kvm bitmap array
>>> through ioport 0xaf20. Qemu-kvm updates this table on a "mem_set" command and
>>> an ACPI event is triggered.
>>>
>>> Memory devices are 128MB in size (to match /sys/devices/memory/block_size_bytes
>>> in x86_64). They are constructed dynamically in src/ssdt-mem.asl , similarly to
>>> hotpluggable-CPUs. The _CRS memstart-memend attribute for each memory device is
>>> defined accordingly, skipping the hole at 0xe0000000 - 0x100000000.
>>> Hotpluggable memory is always located above 4GB.
>>>
>> What is the reason for this limitation?
>
> We currently model a PCI hole from below_4g_mem_size to 4GB, see i440fx_init
> call in pc_init1. The decision was discussed here:
> http://patchwork.ozlabs.org/patch/105892/
> afaict because there was no clear resolution on using a top-of-memory register.
> So, hotplugging will start at 4GB + above_4g_mem_size. Unless we can model the
> pci hole more accurately hardware-wise.
>
>>
>>> Qemu-kvm sets the upper bound of hotpluggable memory with "maxmem = [totalmemory in
>>> MB]" on the command line. Maxmem is an argument for "-m" similar to maxcpus for smp.
>>> E.g. "-m 1024,maxmem=2048" on the qemu command line will create memory devices
>>> for 2GB of RAM, enabling only 1GB initially.
>>>
>>> Qemu_monitor triggers a memory hotplug with:
>>> (qemu) mem_set [memory range in MBs] online
>>>
>> As far as I see mem_set does not get memory range as a parameter. The
>> parameter is amount of memory to add/remove and memory is added/removed
>> to/from the top.
>>
>> This is not flexible enough. Find grained control for memory slots is
>> needed. What about exposing memory slot configuration to command line
>> like this:
>>
>> -memslot mem=size,populated=yes|no
>>
>> adding one of those for each slot.
>>
> yes, I agree we need this.
> Is the idea to model all physical DIMMs? For initial system RAM does it make
> sense to explicitly specify slots at the command line, or infer them?
>
> I think we can allocate a new qemu ram MemoryRegion for each new hotplugged
> slot/DIMM, so there will be a 1-1 mapping between new populated slots and
> qemu memory ram regions. Perhaps we want initial memory allocation to also
> comply with physical slot/DIMM modeling. Initial (cold) RAM is created as
> a single MemoryRegion pc.ram
>
> Also in kvm we can easily run out of kvm_memory_slots (10 slots per VM and 32
> system-wide I think)
>
>> mem_set will get slot id to populate/depopulate just like cpu_set gets
>> cpu slot number to remove and not just yanks cpus with highest slot id.
>
> right, but I think for upstream qemu, people would like to eventually use device_add,
> instead of a new mem_set command. Pretty much the same way as cpu hotplug?
>
> For this to happen, memory devices should be modeled in QOM/qdev. Are we planning
> on keeping a CPUSocket structures for CPUs? or perhaps modelling a memory controller
I'd rather dump CPUSocket structure unless it's really required, it was introduced just
for providing hotplug-able icc bus for cpus since hot-plug on sysbus was disabled.
> is the right way. What type should the memory controller/devices be a child of?
>
> I 'll try to resubmit in a few weeks time, though depending on feedack qom/qdev of
> memory devices will probably take longer.
>
> thanks,
>
> - Vasilis
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-----
Igor
Commenting a little bit late, but since you've said that you are working on
a new version of the patch... better late than never.
On Thu, Aug 11, 2011 at 04:39:38PM +0200, Vasilis Liaskovitis wrote:
> Hi,
>
> I am testing a set of experimental patches for memory-hotplug on x86_64 host /
> guest combinations. I have implemented this in a similar way to cpu-hotplug.
>
> A dynamic SSDT table with all memory devices is created at boot time. This
> table calls static methods from the DSDT. A byte array indicates which memory
> device is online or not. This array is kept in sync with a qemu-kvm bitmap array
> through ioport 0xaf20. Qemu-kvm updates this table on a "mem_set" command and
> an ACPI event is triggered.
>
> Memory devices are 128MB in size (to match /sys/devices/memory/block_size_bytes
> in x86_64). They are constructed dynamically in src/ssdt-mem.asl , similarly to
> hotpluggable-CPUs. The _CRS memstart-memend attribute for each memory device is
> defined accordingly, skipping the hole at 0xe0000000 - 0x100000000.
> Hotpluggable memory is always located above 4GB.
>
What is the reason for this limitation?
> Qemu-kvm sets the upper bound of hotpluggable memory with "maxmem = [totalmemory in
> MB]" on the command line. Maxmem is an argument for "-m" similar to maxcpus for smp.
> E.g. "-m 1024,maxmem=2048" on the qemu command line will create memory devices
> for 2GB of RAM, enabling only 1GB initially.
>
> Qemu_monitor triggers a memory hotplug with:
> (qemu) mem_set [memory range in MBs] online
>
As far as I see mem_set does not get memory range as a parameter. The
parameter is amount of memory to add/remove and memory is added/removed
to/from the top.
This is not flexible enough. Find grained control for memory slots is
needed. What about exposing memory slot configuration to command line
like this:
-memslot mem=size,populated=yes|no
adding one of those for each slot.
mem_set will get slot id to populate/depopulate just like cpu_set gets
cpu slot number to remove and not just yanks cpus with highest slot id.
--
Gleb.
