On 10/09/12 05:35, Jason Baron wrote:
> From: Jason Baron <jbaron(a)redhat.com>
>
> This builds seabios such that the dsdt tables are no longer built into the
> seabios binary. They must be passed to the seabios via fw_cfg. This saves
> space in the seabios binary for unnecessary dsdt tables.
>
> I suspect that this will make other users of Seabios, besides qemu unhappy,
> but I'm not sure.
I think this should best be submitted / discussed separately from the
q35 patch series. And dropping the dsdt from seabios will should
actually be the last step. Loading via fw_cfg works even when seabios
has a builtin dsdt. So we can start loading the dsdt via fwcfg
unconditionally in qemu without touching seabios. Once everything is in
place in qemu we can finally zap the builtin dsdt in seabios (or make it
a config option so latest seabios continues to work with older qemu
versions).
cheers,
Gerd
On Mon, Oct 08, 2012 at 11:35:15PM -0400, Jason Baron wrote:
> From: Jason Baron <jbaron(a)redhat.com>
>
> This builds seabios such that the dsdt tables are no longer built into the
> seabios binary. They must be passed to the seabios via fw_cfg. This saves
> space in the seabios binary for unnecessary dsdt tables.
>
> I suspect that this will make other users of Seabios, besides qemu unhappy,
> but I'm not sure.
Only qemu/kvm uses the acpi support in seabios. (If one excludes
bochs which hasn't really used seabios.) Coreboot and Xen both deploy
acpi completely separately from seabios.
Instead of moving just the dsdt to qemu, though, can we move all acpi
tables into qemu? Moving just the dsdt can lead to conflicts with the
generated ssdt code and potentially some of the other acpi tables.
The only seabios acpi dependency that pops into mind is the memory
addresses of the acpi tables themselves. It should be trivial to have
seabios create the rsdt/rsdp while pulling all the remaining acpi
tables from qemu via fw_cfg. Almost all the tables in acpi describe
hardware and not the firmware. Are there other cases where the
firmware needs to have input when generating the contents of an acpi
table?
-Kevin
2012/10/9 Christian Gmeiner <christian.gmeiner(a)gmail.com>:
> 2012/10/9 Kevin O'Connor <kevin(a)koconnor.net>:
>> On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote:
>>> HI all
>>>
>>> I am running into some usb problems with coreboot & seabios:
>>>
>>>
>>> init usb
>>> pmm_malloc zone=0x1f7afe7f handle=ffffffff size=72 align=10
>>> ret=0x1f7a8860 (detail=0x1f7a88b0)
>> [...]
>>>
>>> Mabye somebody has some hints how to start debugging this and what I
>>> should look for.
>>
>> Hi Christian,
>>
>> Can you set the debug level to 8 and post the whole log? Also, for
>> timeout issues, having timestamps (via tools/readserial.py tool)
>> sometimes helps.
>
>
> Attached
>
>>
>> Did this regress, or has it never worked? What type of USB drive are
>> you attempting to use?
>
>
> It never worked and tried it with a hand full of different usb sticks.
> This one is my target stick, which must work:
>
> Bus 002 Device 029: ID 1370:3252 Swissbit
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x1370 Swissbit
> idProduct 0x3252
> bcdDevice 1.00
> iManufacturer 1 Swissbit
> iProduct 2 unitedCONTRAST
> iSerial 3 60042417C3000001
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 32
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 200mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk-Only
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 255
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 255
> Device Qualifier (for other device speed):
> bLength 10
> bDescriptorType 6
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> bNumConfigurations 1
> Device Status: 0x0000
> (Bus Powered)
>
I got access to an ellisys usb explorer and dumped the whole transfer
between usb stick and
lx800. I started to look at the whole USB stuff this day and I hope we
can get it working :)
To view the dump you need this:
http://www.ellisys.com/products/usbex200/download.php
The dump can be found here:
https://docs.google.com/open?id=0B_fznDimUHVuTkRfYkE5b0NtRzg
greets
---
Christian Gmeiner, MSc
On 10/09/12 05:35, Jason Baron wrote:
> From: Jason Baron <jbaron(a)redhat.com>
>
> Set up the UC area of mtrr dynamically based on mtrr_base. This allows
> the bios to work for other chipsets that might want to set the mtrr.
Nice catch, didn't notice the mtrr thing when making the pci window dynamic.
> +u64 mtrr_base = BUILD_PCIMEM_START;
> +
> u64 pcimem_start = BUILD_PCIMEM_START;
Any reason you add a new variable instead of just using pcimem_start
directly?
I guess when pcimem_start is updated mtrr_base should be updated too.
And we probably should make sure pcimem_start has a value mtrr can
handle. Which pretty much implies pcimem_start can be one of
0x80000000, 0xc0000000 or 0xe000000 depending on the amout of memory the
guest has if we want stick to a single mtrr register.
cheers,
Gerd
Hi,
sorry for the delayed answer.
On Sat, Sep 29, 2012 at 11:13:04AM +0000, Blue Swirl wrote:
> >
> > The "-dimm" option is supposed to specify the dimm/memory layout, and not create
> > any devices.
> >
> > If we don't want this new option, I have a question:
> >
> > A "-device/device_add" means we create a new qdev device at startup or as a
> > hotplug operation respectively. So, the semantics of
> > "-device dimm,id=dimm0,size=512M,node=0,populated=on" are clear to me.
> >
> > What does "-device dimm,populated=off" mean from a qdev perspective? There are 2
> > alternatives:
> >
> > - The device is created on the dimmbus, but is not used/populated yet. Than the
> > activation/acpi-hotplug of the dimm may require a separate command (we used to have
> > "dimm_add" in versions < 3). "device_add" handling always hotplugs a new qdev
> > device, so this wouldn't fit this usecase, because the device already exists. In
> > this case, the actual "acpi hotplug" operation is decoupled from qdev device
> > creation.
>
> The bus exists but the devices do not, device_add would add DIMMs to
> the bus. This matches PCI bus created by the host bridge and PCI
> device hotplug.
>
> A more complex setup would be dimm bus, dimm slot devices and DIMM
> devices. The intermediate slot device would contain one DIMM device if
> plugged.
interesting, I haven't thought about this alternative. It does sounds overly
complex, but a dimmslot / dimmdevice splitup could consolidate hotplug semantic
differences between populated=on/off. Something similar to the dimmslot device
is already present in v3 (dimmcfg structure), but it's not a qdev visible device.
I 'd rather avoid the complication, but i might revisit this idea.
>
> >
> > - The dimmdevice is not created when "-device dimm,populated=off" (this would
> > require some ugly checking in normal -device argument handling). Only the dimm
> > layout is saved. The hotplug is triggered from a normal device_add later. So in
> > this case, the "acpi hotplug" happens at the same time as the qdev hotplug.
> >
> > Do you see a simpler alternative without introducing a new option?
> >
> > Using the "-dimm" option follows the second semantic and avoids changing the "-device"
> > semantics. Dimm layout description is decoupled from dimmdevice creation, and qdev
> > hotplug coincides with acpi hotplug.
>
> Maybe even the dimmbus device shouldn't exist by itself after all, or
> it should be pretty much invisible to users. On real HW, the memory
> controller or south bridge handles the memory. For i440fx, it's part
> of the same chipset. So I think we should just add qdev properties to
> i440fx to specify the sizes, nodes etc. Then i440fx should create the
> dimmbus device unconditionally using the properties. The default
> properties should create a sane configuration, otherwise -global
> i440fx.dimm_size=512M etc. could be used. Then the bus would be
> populated as before or with device_add.
hmm the problem with using only i440fx properties, is that size/nodes look
dimm specific to me, not chipset-memcontroller specific. Unless we only allow
uniform size dimms. Is it possible to have a dynamic list of sizes/nodes pairs as
properties of a qdev device?
Also if there is no dimmbus, and instead we have only links<> from i440fx to dimm-devices,
would the current qdev hotplug API be enough?
I am currently leaning towards this: i440fx unconditionally creates the dimmbus. Users
don't have to specify the bus (i assume this is what you mean by "dimmbus should
be invisible to the users")
We only use "-device dimm" to describe dimms. With "-device dimm,populated=off", only
the dimm config layout will be saved in the dimmbus. The hotplug is triggered from a normal
device_add later (same as pci hotplug).
thanks,
- Vasilis
On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote:
> HI all
>
> I am running into some usb problems with coreboot & seabios:
>
>
> init usb
> pmm_malloc zone=0x1f7afe7f handle=ffffffff size=72 align=10
> ret=0x1f7a8860 (detail=0x1f7a88b0)
[...]
>
> Mabye somebody has some hints how to start debugging this and what I
> should look for.
Hi Christian,
Can you set the debug level to 8 and post the whole log? Also, for
timeout issues, having timestamps (via tools/readserial.py tool)
sometimes helps.
Did this regress, or has it never worked? What type of USB drive are
you attempting to use?
-Kevin
Il 09/10/2012 12:04, Fred . ha scritto:
> Maybe it could be modified to add support for G31 and G33 too?
> Or maybe for P35?
Do you have patches for QEMU that implement the host-side support?
Paolo
Hi,
Seabios bits for q35 support, I'm posting the qemu changes separately. The
patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the
qemu command line. Hopefully, we can make it the default for x86 at some future
point when we feel comfortable with it.
Since q35 patches have been posted before I've tried to keep the authorship as
clear as possible.
The current patches have been tested with basic install testing and memory testing
on f16, f17, windows 7 and windows 8. They can be run on the various BSD flavors
by adding a 'piix4-ide' device to the pci bus. ie: -device piix4-ide.
I'm hoping that we'll come to some agreement on the minimal functionality
required for q35 to be merged.
Git trees:
git://github.com/jibaron/q35-qemu.gitgit://github.com/jibaron/q35-seabios.git
Thanks,
-Jason
Changes from v1:
-Updated end of low mem from 0xe0000000 -> 0xb0000000 (Gerd Hoffmann)
-so 0xb000000-0xc000000 is memconfig
-0xc000000-0xfec00000 is 32-bit pci window
-style/various cleanups
-split dsdt out of bios, now passed for piix4 as well (Paolo, Gerd)
-make mtrr setup dynamic
-allow pci windows to be created based on pcimem_* vars (Gerd Hoffmann)
Isaku Yamahata (5):
seabios: acpi: add mcfg table.
seabios: acpi, fadt: make while fadt initialization chipset specific
seabios: pci: enable SERR of normal device.
seabios: add q35 initialization functions.
seabios: q35: add dsdt
Jan Kiszka (1):
seabios: q35: Register PCI IRQs as active high in APIC mode
Jason Baron (3):
seabios: make mttr UC area setup dynamic
seabios: q35: add basic hotplug support
seabios: Build the dsdt separately
Makefile | 12 +-
src/acpi-dsdt.dsl | 3 -
src/acpi.c | 189 ++++++++--
src/acpi.h | 17 +
src/config.h | 1 -
src/dev-q35.h | 46 +++
src/mtrr.c | 5 +-
src/pci.h | 1 +
src/pciinit.c | 88 +++++-
src/post.c | 6 +-
src/q35-acpi-dsdt.dsl | 980 +++++++++++++++++++++++++++++++++++++++++++++++++
src/shadow.c | 13 +
src/smm.c | 37 ++
13 files changed, 1357 insertions(+), 41 deletions(-)
create mode 100644 src/dev-q35.h
create mode 100644 src/q35-acpi-dsdt.dsl
