> > Maybe this wasn't clear, but in (4) the table is generated by *qemu*
> > with the values programmed by the firmware.
>
> Yes. I still don't much like it. I'd think it would be much simpler
> for qemu to generate the tables once at startup and not have to patch
> them at runtime. It also int
On Tue, Aug 13, 2013 at 08:49:21AM +0200, Gerd Hoffmann wrote:
> On Mo, 2013-08-12 at 18:42 -0400, Kevin O'Connor wrote:
> > On Mon, Aug 12, 2013 at 08:05:08AM +0200, Gerd Hoffmann wrote:
> > > We'll need some way to make sure the pmbase (also mmconf xbar) set by
> > > the firmware matches the pmba
On Mo, 2013-08-12 at 18:42 -0400, Kevin O'Connor wrote:
> On Mon, Aug 12, 2013 at 08:05:08AM +0200, Gerd Hoffmann wrote:
> > We'll need some way to make sure the pmbase (also mmconf xbar) set by
> > the firmware matches the pmbase address filled into the acpi tables by
> > qemu ...
> >
> > So the
On Mon, Aug 12, 2013 at 08:05:08AM +0200, Gerd Hoffmann wrote:
> We'll need some way to make sure the pmbase (also mmconf xbar) set by
> the firmware matches the pmbase address filled into the acpi tables by
> qemu ...
>
> So the options we have are:
>
> (1) Hardcode the address everywhere. Th
On 08/09/13 17:49, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2013 at 12:13:06AM -0400, Kevin O'Connor wrote:
>> On Thu, Aug 08, 2013 at 04:56:55PM +0200, Gerd Hoffmann wrote:
>>> On 08/08/13 16:13, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
>
On Mon, Aug 12, 2013 at 08:37:00AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > If we make it a rule that PCI is`setup before ACPI tables
> > are read, then QEMU can do the patching itself when
> > it detects BIOS reading the tables.
>
> Approach makes sense to me. The ordering constrain shouldn't
Hi,
> If we make it a rule that PCI is`setup before ACPI tables
> are read, then QEMU can do the patching itself when
> it detects BIOS reading the tables.
Approach makes sense to me. The ordering constrain shouldn't be a big
burden, hardware detection+bringup (including pci setup) is the firs
On 08/10/13 05:10, Kevin O'Connor wrote:
> On Fri, Aug 09, 2013 at 08:25:00AM +0200, Gerd Hoffmann wrote:
>>> I don't think SeaBIOS should continue to do the above once the tables
>>> are moved to QEMU. QEMU has all the info SeaBIOS has, so it can
>>> generate the tables correctly on its own.
>>
>
On Fri, Aug 09, 2013 at 11:30:14PM -0400, Kevin O'Connor wrote:
> On Fri, Aug 09, 2013 at 11:45:59AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > Converting src/smm.c to use a runtime value isn't hard - just change
> > > the assembler from: "mov $" __stringify(PORT_ACPI_PM_BASE) " + 0x04,
> > >
On Fri, Aug 09, 2013 at 11:45:59AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > Converting src/smm.c to use a runtime value isn't hard - just change
> > the assembler from: "mov $" __stringify(PORT_ACPI_PM_BASE) " + 0x04,
> > %dx\n" to: "mov 4(my_acpi_base), %dx\n" and make sure to define the
> > glo
On Fri, Aug 09, 2013 at 08:25:00AM +0200, Gerd Hoffmann wrote:
> > I don't think SeaBIOS should continue to do the above once the tables
> > are moved to QEMU. QEMU has all the info SeaBIOS has, so it can
> > generate the tables correctly on its own.
>
> The loader script provided by qemu has fix
On Fri, Aug 09, 2013 at 06:49:18PM +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 09, 2013 at 12:13:06AM -0400, Kevin O'Connor wrote:
> > I don't think SeaBIOS should continue to do the above once the tables
> > are moved to QEMU. QEMU has all the info SeaBIOS has, so it can
> > generate the table
On Fri, Aug 09, 2013 at 12:13:06AM -0400, Kevin O'Connor wrote:
> On Thu, Aug 08, 2013 at 04:56:55PM +0200, Gerd Hoffmann wrote:
> > On 08/08/13 16:13, Michael S. Tsirkin wrote:
> > > On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
> > >> On 08/08/13 11:52, Michael S. Tsirkin wrote:
Hi,
> Converting src/smm.c to use a runtime value isn't hard - just change
> the assembler from: "mov $" __stringify(PORT_ACPI_PM_BASE) " + 0x04,
> %dx\n" to: "mov 4(my_acpi_base), %dx\n" and make sure to define the
> global variable my_acpi_base as VARFSEG.
The apm fix brought a ctl register v
Hi,
>> pmbase is a compile-time constant (aka #define) in both seabios and
>> coreboot, and making this runtime-configurable is non-trivial. See
>> src/smm.c in seabios for one reason why.
> Converting src/smm.c to use a runtime value isn't hard - just change
> the assembler from: "mov $" __s
On Thu, Aug 08, 2013 at 04:56:55PM +0200, Gerd Hoffmann wrote:
> On 08/08/13 16:13, Michael S. Tsirkin wrote:
> > On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
> >> On 08/08/13 11:52, Michael S. Tsirkin wrote:
> >>> On Thu, Aug 08, 2013 at 10:57:44AM +0200, Gerd Hoffmann wrote:
> >
On 08/08/13 16:13, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
>> On 08/08/13 11:52, Michael S. Tsirkin wrote:
>>> On Thu, Aug 08, 2013 at 10:57:44AM +0200, Gerd Hoffmann wrote:
On 08/08/13 10:37, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 20
On Thu, Aug 08, 2013 at 12:21:32PM +0200, Gerd Hoffmann wrote:
> On 08/08/13 11:52, Michael S. Tsirkin wrote:
> > On Thu, Aug 08, 2013 at 10:57:44AM +0200, Gerd Hoffmann wrote:
> >> On 08/08/13 10:37, Michael S. Tsirkin wrote:
> >>> On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
> >
On 08/08/13 11:52, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2013 at 10:57:44AM +0200, Gerd Hoffmann wrote:
>> On 08/08/13 10:37, Michael S. Tsirkin wrote:
>>> On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
Also coreboot and seabios use different values for pmbase. coreboot
On Thu, Aug 08, 2013 at 10:57:44AM +0200, Gerd Hoffmann wrote:
> On 08/08/13 10:37, Michael S. Tsirkin wrote:
> > On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
> (3) mmconf xbar start (MCFG, q35 only, at 0xb000 now).
> (4) pmbase (FADT, at 0xb000 now).
>
> >>
On Thu, Aug 08, 2013 at 10:51:59AM +0200, Gerd Hoffmann wrote:
> On 08/08/13 10:22, Michael S. Tsirkin wrote:
> > On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> Huh? The 32bit window is sized according to the installed memory.
> That
> logic is in s
On 08/08/13 10:37, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
(3) mmconf xbar start (MCFG, q35 only, at 0xb000 now).
(4) pmbase (FADT, at 0xb000 now).
Especially 3+4 tend to be compile-time constants in the firmware as they
On Thu, Aug 08, 2013 at 09:57:39AM +0200, Gerd Hoffmann wrote:
> >> (3) mmconf xbar start (MCFG, q35 only, at 0xb000 now).
> >> (4) pmbase (FADT, at 0xb000 now).
> >>
> >> Especially 3+4 tend to be compile-time constants in the firmware as they
> >> are needed very early in the setup proces
On Wed, Aug 07, 2013 at 09:29:39AM +0200, Gerd Hoffmann wrote:
> We'll need some way for seabios to fill in the pci window information
> into the qemu-provided tables. Easiest way to do that would be to
> extend the COMMAND_ADD_POINTER bios linker script command.
This idea certainly has an advant
24 matches
Mail list logo
