Re: [SeaBIOS] [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Michael Tokarev]

15.02.2013 07:43, Kevin O'Connor wrote:
> On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
>> On 02/15/13 02:22, Kevin O'Connor wrote:
>>> On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
>>> By chance, are you using an older version of kvm?  There was a bug in
>>> kvm that caused changes to memory mapped at 0xe-0xf to also be
>>> reflected in the "rom" image at 0xfffe-0x.  It was my
>>> understand that this bug was fixed though.
>>
>> You are great! Disabling KVM for the guest (/domain/@type='qemu') made
>> the reboot work on both the RHEL-6 devel version of qemu and on upstream
>> 1.3.1.
>>
>> (I didn't try suspend/resume yet.)
>>
>> Do you recall the precise commit that fixed the "reflection"? I've been
>> eyeballing kvm commit messages for a few ten minutes now, but of course
>> in vain. (CC'ing Gleb and Marcelo.)
> 
> I found this email thread:
> 
> http://kerneltrap.org/mailarchive/linux-kvm/2010/9/21/6267744
> 
> and: http://marc.info/?l=kvm-commits&m=128576215909532

This patch is more than 2 years old and is applied to all more or
less recent qemu versions.  This does not tell us why disabling
kvm (with this patch applied!) makes a difference.  So there must
be another (maybe similar) bug somewhere...

/mjt

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Kevin O'Connor]

On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
> On 02/15/13 02:22, Kevin O'Connor wrote:
> > On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
> > By chance, are you using an older version of kvm?  There was a bug in
> > kvm that caused changes to memory mapped at 0xe-0xf to also be
> > reflected in the "rom" image at 0xfffe-0x.  It was my
> > understand that this bug was fixed though.
> 
> You are great! Disabling KVM for the guest (/domain/@type='qemu') made
> the reboot work on both the RHEL-6 devel version of qemu and on upstream
> 1.3.1.
> 
> (I didn't try suspend/resume yet.)
> 
> Do you recall the precise commit that fixed the "reflection"? I've been
> eyeballing kvm commit messages for a few ten minutes now, but of course
> in vain. (CC'ing Gleb and Marcelo.)

I found this email thread:

http://kerneltrap.org/mailarchive/linux-kvm/2010/9/21/6267744

and: http://marc.info/?l=kvm-commits&m=128576215909532

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

On 02/15/13 02:22, Kevin O'Connor wrote:
> On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
>> On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote:
>>> On 02/14/13 21:55, David Woodhouse wrote:
>>>
 Thanks for testing this, btw. Are you looking at suspend/resume too? :)
>>>
>>> Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
>>> I woke up the guest with
>>>
>>> # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
>>>   --hmp --cmd system_wakeup
>>>
>>> Trailing portion of the log:
>>>
>>>   In resume (status=254)
>>>   In 32bit resume
>>>   rsdp=0x
>>>   No resume vector set!
>>
>> That is strange.  As noted elsewhere, on a resume or reboot the cpu
>> should have started execution at 0xfff0 which is OVMF and not
>> SeaBIOS.  I don't understand why/how SeaBIOS would be involved in the
>> resume code path at all.
> 
> By chance, are you using an older version of kvm?  There was a bug in
> kvm that caused changes to memory mapped at 0xe-0xf to also be
> reflected in the "rom" image at 0xfffe-0x.  It was my
> understand that this bug was fixed though.

You are great! Disabling KVM for the guest (/domain/@type='qemu') made
the reboot work on both the RHEL-6 devel version of qemu and on upstream
1.3.1.

(I didn't try suspend/resume yet.)

Do you recall the precise commit that fixed the "reflection"? I've been
eyeballing kvm commit messages for a few ten minutes now, but of course
in vain. (CC'ing Gleb and Marcelo.)

Thank you,
Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Kevin O'Connor]

On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote:
> On 02/14/13 21:55, David Woodhouse wrote:
> 
> > Thanks for testing this, btw. Are you looking at suspend/resume too? :)
> 
> Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
> I woke up the guest with
> 
> # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
>   --hmp --cmd system_wakeup
> 
> Trailing portion of the log:
> 
>   In resume (status=254)
>   In 32bit resume
>   rsdp=0x
>   No resume vector set!

That is strange.  As noted elsewhere, on a resume or reboot the cpu
should have started execution at 0xfff0 which is OVMF and not
SeaBIOS.  I don't understand why/how SeaBIOS would be involved in the
resume code path at all.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Kevin O'Connor]

On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
> On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote:
> > On 02/14/13 21:55, David Woodhouse wrote:
> > 
> > > Thanks for testing this, btw. Are you looking at suspend/resume too? :)
> > 
> > Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
> > I woke up the guest with
> > 
> > # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
> >   --hmp --cmd system_wakeup
> > 
> > Trailing portion of the log:
> > 
> >   In resume (status=254)
> >   In 32bit resume
> >   rsdp=0x
> >   No resume vector set!
> 
> That is strange.  As noted elsewhere, on a resume or reboot the cpu
> should have started execution at 0xfff0 which is OVMF and not
> SeaBIOS.  I don't understand why/how SeaBIOS would be involved in the
> resume code path at all.

By chance, are you using an older version of kvm?  There was a bug in
kvm that caused changes to memory mapped at 0xe-0xf to also be
reflected in the "rom" image at 0xfffe-0x.  It was my
understand that this bug was fixed though.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [seabios][PATCH 2/2] acpi: change numa data format from fw_cfg interface

[li guang]

Sorry for late reply

在 2013-02-06三的 23:18 -0500，Kevin O'Connor写道：
> On Mon, Feb 04, 2013 at 10:28:00AM +0800, liguang wrote:
> > the old numa format got form fw_cfg is:
> > number of nodes
> > node id of cpu (array)
> > node memory size (array)
> > 
> > now, format it like array of:
> > apci_map,
> > memory_size,
> > 
> > it has the advantage of simple and clear.
> 
> With this change, will old versions of seabios work with new versions
> of qemu, and old versions of qemu work with new versions of seabios?

may be not.

> 
> Also, can you provide a high-level summary of why this change is
> useful to an end-user?

This change have nothing to do with end-user,
just for clear design.

> 
> -Kevin
> 



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [seabios][PATCH 1/2] move all acpi-table related definitions to acpi.h

[li guang]

在 2013-02-06三的 23:15 -0500，Kevin O'Connor写道：
> On Mon, Feb 04, 2013 at 10:27:59AM +0800, liguang wrote:
> > Signed-off-by: liguang 
> 
> Thanks.  Some comments.
> 
> [...]
> > --- a/src/acpi.h
> > +++ b/src/acpi.h
> [...]
> > +#include "acpi-dsdt.hex"
> 
> Moving the acpi structure defines to the header is fine, but moving
> the DSDT code into the header is definitely not right.

OK, will remove this include.

> 
> -Kevin
> 



___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Andrew Fish]

On Feb 14, 2013, at 2:09 PM, "H. Peter Anvin"  wrote:

> On 02/14/2013 01:27 PM, David Woodhouse wrote:
>> 
>> So it *is* jumping to 0xfff0 but the memory at that location isn't
>> what we expect? Do the PAM registers affect *that* too, or only the
>> region from 0xc-0xf? Surely the contents at 4GiB-δ should be
>> unchanged by *anything* we do with the PAM registers?
>> 
>> Or maybe not... after also downloading the i440fx data sheet, I'm even
>> more confused. There's some aliasing with... not the region at 1MiB-δ
>> but the region at 16MiB-δ:
>> 

I don't remember the specific registers for the 440BX

 The i486 moved the reset vector to 0xFFF0, but it is in real mode. The 
processor CS register has some magic internal value that lets you run real mode 
code  up high, but the 1st long jmp you do sends you down low. Thus the chipset 
needs to alias 0xF000:0xFFF0 to the high address. If you BIOS is written in 
protected mode then it will turn on the HIgh BIOS Area and jump back into the 
just under the 4GB region and now it has access to a ROM that can be up to 2MB 
in size after it turns on the high BIOS area. 

If you hardware reset the PAM registers should get set back to defaults, and 
CPU goes into the reset state.
If you soft (also called warm) reset, jump to 0xF000:0xFFF0 then, you are not 
running the reset code in ROM (called SEC in the PI lingo) you are running the 
shadowed copy from memory provided by the SeaBIOS for  compatibility. 

Thanks,

Andrew

>> (From §4.1 System Address Map):
>> 
>> 2. High BIOS Area (FFE0_h−− _h)
>>   The top 2 Mbytes of the Extended Memory Region is reserved for System
>>   BIOS (High BIOS), extended BIOS for PCI devices, and the A20 alias of
>>   the system BIOS. The CPU begins execution from the High BIOS after
>>   reset. This region is mapped to the PCI so that the upper subset of
>>   this region is aliased to 16 Mbytes minus 256-Kbyte range.
>> 
> 
> That is presumably a 286 compatibility hack -- the 286 had 24 address 
> lines.  I doubt anyone gives a hoot about it, and neither EDK2 nor 
> SeaBIOS should care.
> 
>   -hpa
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[David Woodhouse]

On Fri, 2013-02-15 at 00:01 +0100, Laszlo Ersek wrote:
> 
> Entering S3 seemed OK (except the screen was not cleared; using
> Cirrus).
> I woke up the guest with
> 
> # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
>   --hmp --cmd system_wakeup
> 
> Trailing portion of the log:
> 
>   In resume (status=254)
>   In 32bit resume
>   rsdp=0x
>   No resume vector set!
>   Attempting a hard reboot
>   i8042_wait_write
>   In resume (status=0)
>   In 32bit resume
>   Attempting a hard reboot
>   [...]
> 
> I can see the following CSM calls earlier:
> - Legacy16InitializeYourself
> - Legacy16GetTableAddress
> - Legacy16DispatchOprom
> - Legacy16UpdateBbs
> 
> No calls to PrepareToBoot (which could set RsdpAddr); this is an UEFI
> guest. (The CSM is used for the GOP only.)

So you have the same problem as with reset — you're ending up back in
the CSM in RAM, when you ought to be in the OVMF "ROM". 

I wonder if a *Legacy* guest might actually fare a little better? At
least find_resume_vector() would have a chance of working if the CSM has
actually been told where the ACPI tables are...



-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

On 02/14/13 21:55, David Woodhouse wrote:

> Thanks for testing this, btw. Are you looking at suspend/resume too? :)

Entering S3 seemed OK (except the screen was not cleared; using Cirrus).
I woke up the guest with

# virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \
  --hmp --cmd system_wakeup

Trailing portion of the log:

  In resume (status=254)
  In 32bit resume
  rsdp=0x
  No resume vector set!
  Attempting a hard reboot
  i8042_wait_write
  In resume (status=0)
  In 32bit resume
  Attempting a hard reboot
  [...]

I can see the following CSM calls earlier:
- Legacy16InitializeYourself
- Legacy16GetTableAddress
- Legacy16DispatchOprom
- Legacy16UpdateBbs

No calls to PrepareToBoot (which could set RsdpAddr); this is an UEFI
guest. (The CSM is used for the GOP only.)

Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

On 02/14/13 22:27, David Woodhouse wrote:
> On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
>> On 02/14/13 21:54, H. Peter Anvin wrote:
>>> On 02/14/2013 12:41 PM, Laszlo Ersek wrote:

 ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
 the exact address of... reset_vector() in SeaBIOS.

>>>
>>> This would be a bug, but it isn't quite true.
>>>
>>> If you look at x86_cpu_reset() you will note that it sets the code
>>> segment base to 0x, not 0xf as one could expect from the
>>> above.  This is also true of a physical x86.
>>>
>>> As such, the *real* reset vector is at 0xfff0 as opposed to the
>>> SeaBIOS vector at 0x0 -- this is a backwards compatibility vector
>>> which typically just issues a real reset.
>>>
>>> Now, if Qemu doesn't handle the distinction here correctly, that is a bug.
>>
>> I think I was simply wrong :)
> 
> So it *is* jumping to 0xfff0 but the memory at that location isn't
> what we expect? Do the PAM registers affect *that* too, or only the
> region from 0xc-0xf? Surely the contents at 4GiB-δ should be
> unchanged by *anything* we do with the PAM registers?

I meant that my reading of what x86_cpu_reset() [nee cpu_reset()] was
wrong, because the constant that it passes as argument in fact conforms
to what Peter says.

(
Also check the rom_add_file_fixed() call in pc_init1() / qemu:

ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);

("bios_size" is an "int"). I referred to this in my thread starter as

When qemu-kvm starts, "OVMF.fd" is installed as ROM, such that the
last address it occupies is "all-bits-one", independently of its
size [...]

Namely, the value of (uint32_t)(-bios_size) is

UINT32_MAX + 1 - bios_size

(the above is meant as a math formula, not as a C expression), hence the
last byte occupied is at UINT32_MAX. In my first post I silently thought
that this value would be truncated to fewer bits somewhere, but
apparently that's not the case.
)

> 
> Or maybe not... after also downloading the i440fx data sheet, I'm even
> more confused. There's some aliasing with... not the region at 1MiB-δ
> but the region at 16MiB-δ:
> 
> (From §4.1 System Address Map):
> 
> 2. High BIOS Area (FFE0_h−− _h)
>   The top 2 Mbytes of the Extended Memory Region is reserved for System
>   BIOS (High BIOS), extended BIOS for PCI devices, and the A20 alias of
>   the system BIOS. The CPU begins execution from the High BIOS after
>   reset. This region is mapped to the PCI so that the upper subset of
>   this region is aliased to 16 Mbytes minus 256-Kbyte range.

After Peter emphasized that the code segment base was 0x, I went
back to wikipedia , and
finally managed to parse

The reset vector for the 80386DX and later x86 processors is
0x0, although the value of the CS register at reset is 0xF000
and the value of the IP register at reset is 0xFFF0. In actuality,
current x86 processors fetch from the physical address 0xFFF0.
This is due to a hidden base address portion of the CS register in
real mode which defaults to 0x after reset.

This is again consistent with the 0xfff0 vector pointed out by Peter
(= 0x + 0xFFF0), but I don't know how to match it to the data
sheet language...

Thanks
Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[David Woodhouse]

On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
> I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
> reset requested by the guest doesn't work as expected. The behavior is
> an infinite loop, with the following debug fragment repeated by the
> CSM-ized SeaBIOS:
> 
>   In resume (status=0)
>   In 32bit resume
>   Attempting a hard reboot
>   i8042_wait_write

Hmm. My build from http://david.woodhou.se/OVMF.fd works fine. I did a
legacy boot into (Ubuntu Oneiric's) Grub, then issued the 'reboot'
command...

This appears to be the case for qemu 1.2.0 and 1.3.0, both with and
without KVM.

enter handle_13:
   a=4200  b=0801  c=003f  d=0080 ds=6000 es= ss=
  si=fe00 di= bp=1ff0 sp=1ff2 cs= ip=9157  f=0202
disk_op d=0xdb20 lba=9269505 buf=0x00068000 count=63 cmd=2
pmtimer: 2:15494096
pmtimer: 2:15494211
In resume (status=0)
In 32bit resume
Attempting a hard reboot
i8042_wait_write
pmtimer: 2:15501497
pmtimer: 2:15501593
pmtimer: 2:15501750
SecCoreStartupWithStack(0xFFFE6000, 0x8)
File->Type: 0xB
Section->Type: 0x2
Section->Type: 0x19
Section->Type (0x19) != SectionType (0x17)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[H. Peter Anvin]

On 02/14/2013 01:27 PM, David Woodhouse wrote:


So it *is* jumping to 0xfff0 but the memory at that location isn't
what we expect? Do the PAM registers affect *that* too, or only the
region from 0xc-0xf? Surely the contents at 4GiB-δ should be
unchanged by *anything* we do with the PAM registers?

Or maybe not... after also downloading the i440fx data sheet, I'm even
more confused. There's some aliasing with... not the region at 1MiB-δ
but the region at 16MiB-δ:

(From §4.1 System Address Map):

2. High BIOS Area (FFE0_h−− _h)
   The top 2 Mbytes of the Extended Memory Region is reserved for System
   BIOS (High BIOS), extended BIOS for PCI devices, and the A20 alias of
   the system BIOS. The CPU begins execution from the High BIOS after
   reset. This region is mapped to the PCI so that the upper subset of
   this region is aliased to 16 Mbytes minus 256-Kbyte range.



That is presumably a 286 compatibility hack -- the 286 had 24 address 
lines.  I doubt anyone gives a hoot about it, and neither EDK2 nor 
SeaBIOS should care.


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

On 02/14/13 21:55, David Woodhouse wrote:

> So, if real hardware would reset the PAMs on reset and avoid the need
> for SeaBIOS to do so, I think we should be doing the same in qemu too.

That's what I couldn't figure out from the i440FX spec, but I believe
one could argue that "reset" should in fact re-set the state that was
observable at VM startup.

> Thanks for testing this, btw. Are you looking at suspend/resume too? :)

I'm either not looking, or not admitting it! :)

In earnest: I "approached" Platform Initialization S3 resume cautiously,
then fled in a panic. See Chapter 8 in Volume 5 -- Jordan convinced me
that this scripting language was in fact reasonable, but the work needed
to follow through OVMF PI, make it S3 resume compliant, and record
everything into a script at cold boot looks very threatening.

Regarding S3 in SeaBIOS CSM: I haven't tried it yet, but I can press the
button in guests if you want me to.

Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[David Woodhouse]

On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
> On 02/14/13 21:54, H. Peter Anvin wrote:
> > On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
> >>
> >> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
> >> the exact address of... reset_vector() in SeaBIOS.
> >>
> > 
> > This would be a bug, but it isn't quite true.
> > 
> > If you look at x86_cpu_reset() you will note that it sets the code
> > segment base to 0x, not 0xf as one could expect from the
> > above.  This is also true of a physical x86.
> > 
> > As such, the *real* reset vector is at 0xfff0 as opposed to the
> > SeaBIOS vector at 0x0 -- this is a backwards compatibility vector
> > which typically just issues a real reset.
> > 
> > Now, if Qemu doesn't handle the distinction here correctly, that is a bug.
> 
> I think I was simply wrong :)

So it *is* jumping to 0xfff0 but the memory at that location isn't
what we expect? Do the PAM registers affect *that* too, or only the
region from 0xc-0xf? Surely the contents at 4GiB-δ should be
unchanged by *anything* we do with the PAM registers?

Or maybe not... after also downloading the i440fx data sheet, I'm even
more confused. There's some aliasing with... not the region at 1MiB-δ
but the region at 16MiB-δ:

(From §4.1 System Address Map):

2. High BIOS Area (FFE0_h−− _h)
  The top 2 Mbytes of the Extended Memory Region is reserved for System
  BIOS (High BIOS), extended BIOS for PCI devices, and the A20 alias of
  the system BIOS. The CPU begins execution from the High BIOS after
  reset. This region is mapped to the PCI so that the upper subset of
  this region is aliased to 16 Mbytes minus 256-Kbyte range.


-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[H. Peter Anvin]

On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
> 
> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
> the exact address of... reset_vector() in SeaBIOS.
> 

This would be a bug, but it isn't quite true.

If you look at x86_cpu_reset() you will note that it sets the code
segment base to 0x, not 0xf as one could expect from the
above.  This is also true of a physical x86.

As such, the *real* reset vector is at 0xfff0 as opposed to the
SeaBIOS vector at 0x0 -- this is a backwards compatibility vector
which typically just issues a real reset.

Now, if Qemu doesn't handle the distinction here correctly, that is a bug.

-hpa


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

On 02/14/13 21:54, H. Peter Anvin wrote:
> On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
>>
>> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
>> the exact address of... reset_vector() in SeaBIOS.
>>
> 
> This would be a bug, but it isn't quite true.
> 
> If you look at x86_cpu_reset() you will note that it sets the code
> segment base to 0x, not 0xf as one could expect from the
> above.  This is also true of a physical x86.
> 
> As such, the *real* reset vector is at 0xfff0 as opposed to the
> SeaBIOS vector at 0x0 -- this is a backwards compatibility vector
> which typically just issues a real reset.
> 
> Now, if Qemu doesn't handle the distinction here correctly, that is a bug.

I think I was simply wrong :)

Thanks
Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[David Woodhouse]

On Thu, 2013-02-14 at 12:54 -0800, H. Peter Anvin wrote:
> This would be a bug, but it isn't quite true.
> 
> If you look at x86_cpu_reset() you will note that it sets the code
> segment base to 0x, not 0xf as one could expect from the
> above.  This is also true of a physical x86.
> 
> As such, the *real* reset vector is at 0xfff0 as opposed to the
> SeaBIOS vector at 0x0 -- this is a backwards compatibility vector
> which typically just issues a real reset.

In SeaBIOS it doesn't. It jumps to entry_post(). Which is fine for
native SeaBIOS, but I suppose I need to fix it to do a *real* reset in
the CSM case, for those operating systems which will switch back to
16-bit mode and jump to f000:fff0 to reboot.

Of course, if said "real reset" is only going to get straight back to
the same 0x0 reset vector, that's not going to help. But at least
then none of it will be *my* fault :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[David Woodhouse]

On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
> Can we dumb down ^W^W generalize this code? :) Or maybe should qemu
> introduce a reset handler for PAMs?

In the UEFI+CSM model, I believe the handling of PAM stuff is left
*entirely* to the UEFI side and the CSM is supposed to be
hardware-agnostic. So actually bashing on the PAM registers from the CSM
side would be my last resort. It's why it's important to fix the
UmbStart/UmbEnd thing correctly, too.

Other people might have been happy to hack up something
machine-specific, given that they control both UEFI and CSM sides of it
and they're shipping their own proprietary version where nobody can see
what they're doing. But when the CSM spec is the interface between two
entirely *separate* projects (OVMF and SeaBIOS), I think it's important
that we *follow* the spec and don't have nasty hacks.

So, if real hardware would reset the PAMs on reset and avoid the need
for SeaBIOS to do so, I think we should be doing the same in qemu too.

Thanks for testing this, btw. Are you looking at suspend/resume too? :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 18:10 +, Ian Campbell wrote:
> 
> I tested:
> HEAD is now at e62d172 Make Xen one of the top-level build target choices
> with the attached config and I'm afraid it booted from the cdrom no
> matter what I did in my config file.

The patch I sent earlier seems to have fixed it. As was pointed out to
me in private email (thanks), it's in the CMOS not fw_cfg.

To bombadil:public_git/seabios.git
 + e62d172...d8ff442 master -> master (forced update)

That version ought to work. Thanks for your help with this.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM

[Laszlo Ersek]

Hi,

I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:

  In resume (status=0)
  In 32bit resume
  Attempting a hard reboot
  i8042_wait_write

The corresponding call chain seems to be:

  reset_vector() [src/romlayout.S]
entry_post()
  entry_resume()
handle_resume() [src/resume.c]
  prints "In resume"
  handle_resume32()
prints "In 32bit resume"
tryReboot()
  prints "Attempting a hard reboot"
  i8042_reboot() [src/ps2port.c]
i8042_wait_write()
  prints "i8042_wait_write"
outb(0xfe, PORT_PS2_STATUS)

(The entry_post -> entry_resume jump occurs because HaveRunPost has been
set to 1 by csm_maininit() --> interface_init() --> ivt_init().)

At this point kbd_write_command() in qemu-kvm's "hw/pckbd.c", case
KBD_CCMD_RESET, requests a system reset. Soon the reset handlers run,
among them cpu_reset() (which was registered by

  pc_init1() [hw/pc.c]
pc_new_cpu()

). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
the exact address of... reset_vector() in SeaBIOS.

Of course OVMF should be re-run instead of SeaBIOS. When qemu-kvm
starts, "OVMF.fd" is installed as ROM, such that the last address it
occupies is "all-bits-one", independently of its size (below a limit of
course):

  pc_init1() [hw/pc.c]
rom_add_file_fixed() []
  open() / read() /close()
  rom_insert()
some calls to inform KVM


I think when OVMF runs SeaBIOS as CSM, OVMF shadows the original ROM
(containing the OVMF binary itself) with the SeaBIOS code + static data
(I'm peeking at
...). This should
render SeaBIOS visible / executable / writeable in the top 16-bit
segment, and leave OVMF in a permanently unusable state (in RAM at least).

My guess at the relevant edk2 function is ShadowAndStartLegacy16()
[IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBios.c]. The
LegacyRegion->UnLock() call should be instrumental (implemented in
"OvmfPkg/Csm/CsmSupportLib/LegacyRegion.c" with PAM (Programmable
Attribute Map) registers?)

Hence I *presume* qemu-kvm should un-shadow the ROM at reset time (ie.
make OVMF visible again as ROM) not later than allowing the VCPU to
continue at f000:fff0 again. Normally that address should be occupied by
OVMF code from (I guess) "UefiCpuPkg/ResetVector/Vtf0".

Does this make any sense? Is qemu-kvm forgetting to reset the PAMs? Or
would that be the responsibility of tryReboot() in SeaBIOS?

... Aah! qemu_prep_reset() in SeaBIOS [src/shadow.c] goes like:

void
qemu_prep_reset(void)
{
if (!CONFIG_QEMU)
return;
// QEMU doesn't map 0xc-0xf back to the original rom on a
// reset, so do that manually before invoking a hard reset.
make_bios_writable();
extern u8 code32flat_start[], code32flat_end[];
memcpy(code32flat_start, code32flat_start + BIOS_SRC_OFFSET
   , code32flat_end - code32flat_start);

if (HaveRunPost)
// Memory copy failed to work - try to halt the machine.
apm_shutdown();
}

and this function is actually called inside the infinite loop (I ignored
it before):

tryReboot()
  prints "Attempting a hard reboot"
  qemu_prep_reset() [src/shadow.c] <-- here
  i8042_reboot() [src/ps2port.c]
i8042_wait_write()
  prints "i8042_wait_write"
outb(0xfe, PORT_PS2_STATUS)

but of course it doesn't do anything with CONFIG_CSM (since that implies
!CONFIG_QEMU). What's more, qemu_prep_reset() and
make_bios_writable_intel() seem to exploit SeaBIOS characteristics
(code32flat_*, HaveRunPost etc.) that probably make no sense when the
data being restored is a different (= OVMF) image.

Can we dumb down ^W^W generalize this code? :) Or maybe should qemu
introduce a reset handler for PAMs?

(I realize I've been reading all the time about PAMs, in the "Writeable
files in fw_cfg" thread, in the discussion about unlocking the 0xE
segment for stack purposes... Didn't understand a single word before,
sorry. Downloaded my copy of the i440FX spec just today; I finally have
a remote idea how shadowing / write-protecting works.)

Thanks!
Laszlo

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 18:10 +, Ian Campbell wrote:
> I tested:
> HEAD is now at e62d172 Make Xen one of the top-level build target choices
> with the attached config and I'm afraid it booted from the cdrom no
> matter what I did in my config file.
> 
> I enabled CONFIG_QEMU_HARDWARE (seabios2.config) and that didn't help
> (which surprised me because I associate that option with fw_cfg).

OK, fw_cfg *is* active in your setup, although my own SeaBIOS build
(before my patch) isn't detecting it for some local reason. Perhaps
because I don't *have* any disks, so it doesn't set the bootorder. And
maybe doesn't expose fw_cfg to the guest at all? Or maybe just other
weirdness here.

Anyway, I *know* my patch breaks it because it's associated with
CONFIG_QEMU not CONFIG_QEMU_HARDWARE. Will modify, but not when there's
a 2-year-old shouting and climbing between me and the keyboard shouting
'Daddy Duddle!'...

Thanks for testing.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 17:11 +, Ian Campbell wrote:
> On Thu, 2013-02-14 at 16:47 +, David Woodhouse wrote:
> > On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
> > > On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> > > > 
> > > > Anyway, I appear to have established that the qemu fw_cfg *doesn't*
> > > > exist in your domains — so how you pass bootorder to the guest, if
> > > you
> > > > successfully do so at all, I have no idea. 
> > > 
> > > Asking around no one seems to have any idea how this works, other than
> > > we pass it to qemu.
> > 
> > *Does* it work?
> 
> People seem to think so, but I'm starting to wonder. I'm going to go and
> check for myself now.

I can indeed select between disk, network and cdrom using the
boot="c" (or "d" or "n") option.

> > And — more to the point, since this is my only real reason for caring
> > about it at all — does it *stop* working if you build SeaBIOS from my
> > tree at git.infradead.org/users/dwmw2/seabios.git ?
> 
> I will give that a go second.

I tested:
HEAD is now at e62d172 Make Xen one of the top-level build target choices
with the attached config and I'm afraid it booted from the cdrom no
matter what I did in my config file.

I enabled CONFIG_QEMU_HARDWARE (seabios2.config) and that didn't help
(which surprised me because I associate that option with fw_cfg).

The following quick hack didn't help, so something deeper must be up, I
can have another poke tomorrow and see if I can work out how this ever
worked...

BTW, the disk stanza for a cdrom is 'file:/scratch/mini.iso,hdc:cdrom,r'

Ian.

diff --git a/src/paravirt.c b/src/paravirt.c
index cc64094..c4ffd32 100644
--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -157,7 +157,7 @@ void qemu_cfg_preinit(void)
 char *sig = "QEMU";
 int i;
 
-if (!CONFIG_QEMU)
+if (!CONFIG_QEMU&&!CONFIG_XEN)
 return;
 
 qemu_cfg_present = 1;
@@ -433,7 +433,7 @@ struct QemuCfgFile {
 
 void qemu_romfile_init(void)
 {
-if (!CONFIG_QEMU || !qemu_cfg_present)
+if ((!CONFIG_QEMU && !CONFIG_XEN) || !qemu_cfg_present)
 return;
 
 u32 count;

-- 
Ian Campbell

rugged, adj.:
Too heavy to lift.

#
# Automatically generated make config: don't edit
# SeaBIOS Configuration
# Thu Feb 14 17:53:04 2013
#

#
# General Features
#
# CONFIG_COREBOOT is not set
# CONFIG_QEMU is not set
# CONFIG_CSM is not set
CONFIG_XEN=y
# CONFIG_QEMU_HARDWARE is not set
CONFIG_THREADS=y
# CONFIG_THREAD_OPTIONROMS is not set
CONFIG_RELOCATE_INIT=y
CONFIG_BOOTMENU=y
# CONFIG_BOOTSPLASH is not set
CONFIG_BOOTORDER=y

#
# Hardware support
#
CONFIG_ATA=y
CONFIG_ATA_DMA=y
CONFIG_ATA_PIO32=y
CONFIG_AHCI=y
CONFIG_MEGASAS=y
CONFIG_FLOPPY=y
CONFIG_PS2PORT=y
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_UAS=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y
CONFIG_SERIAL=y
CONFIG_LPT=y
CONFIG_PMTIMER=y

#
# BIOS interfaces
#
CONFIG_DRIVES=y
CONFIG_CDROM_BOOT=y
CONFIG_CDROM_EMU=y
CONFIG_PCIBIOS=y
CONFIG_APMBIOS=y
CONFIG_PNPBIOS=y
CONFIG_OPTIONROMS=y
CONFIG_PMM=y
CONFIG_BOOT=y
CONFIG_KEYBOARD=y
CONFIG_KBD_CALL_INT15_4F=y
CONFIG_MOUSE=y
CONFIG_S3_RESUME=y
CONFIG_VGAHOOKS=y
# CONFIG_DISABLE_A20 is not set

#
# VGA ROM
#
CONFIG_NO_VGABIOS=y
# CONFIG_VGA_STANDARD_VGA is not set
# CONFIG_VGA_CIRRUS is not set
# CONFIG_VGA_BOCHS is not set
# CONFIG_VGA_GEODEGX2 is not set
# CONFIG_VGA_GEODELX is not set
# CONFIG_BUILD_VGABIOS is not set

#
# Debugging
#
CONFIG_DEBUG_LEVEL=1
# CONFIG_DEBUG_SERIAL is not set
#
# Automatically generated make config: don't edit
# SeaBIOS Configuration
# Thu Feb 14 17:55:58 2013
#

#
# General Features
#
# CONFIG_COREBOOT is not set
# CONFIG_QEMU is not set
# CONFIG_CSM is not set
CONFIG_XEN=y
CONFIG_QEMU_HARDWARE=y
CONFIG_THREADS=y
# CONFIG_THREAD_OPTIONROMS is not set
CONFIG_RELOCATE_INIT=y
CONFIG_BOOTMENU=y
# CONFIG_BOOTSPLASH is not set
CONFIG_BOOTORDER=y

#
# Hardware support
#
CONFIG_ATA=y
CONFIG_ATA_DMA=y
CONFIG_ATA_PIO32=y
CONFIG_AHCI=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_SCSI=y
CONFIG_ESP_SCSI=y
CONFIG_LSI_SCSI=y
CONFIG_MEGASAS=y
CONFIG_FLOPPY=y
CONFIG_PS2PORT=y
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_UAS=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y
CONFIG_SERIAL=y
CONFIG_LPT=y
CONFIG_PMTIMER=y

#
# BIOS interfaces
#
CONFIG_DRIVES=y
CONFIG_CDROM_BOOT=y
CONFIG_CDROM_EMU=y
CONFIG_PCIBIOS=y
CONFIG_APMBIOS=y
CONFIG_PNPBIOS=y
CONFIG_OPTIONROMS=y
CONFIG_PMM=y
CONFIG_BOOT=y
CONFIG_KEYBOARD=y
CONFIG_KBD_CALL_INT15_4F=y
CONFIG_MOUSE=y
CONFIG_S3_RESUME=y
CONFIG_VGAHOOKS=y
# CONFIG_DISABLE_A20 is not set

#
# VGA ROM
#
CONFIG_NO_VGABIOS=y
# CONFIG_VGA_STANDARD_VGA is not set
# CONFIG_VGA_CIRRUS is not set
# CONFIG_VGA_BOCHS is not set
# CONFIG_VGA_GEODEGX2 is not set
# CONFIG_VGA_GEODELX is not set
# CONFIG_BUILD_VGABIOS is not set

#
# Debugging
#
CONFIG_DEBUG_LEVEL=1
# CONFIG_DEBUG_SERIAL is not set
___
SeaB

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[Peter Stuge]

Fred . wrote:
> I propose the name running_on_Xen()

The proper way to do that is to send a perfect patch, created using
git, with your commit on top of current seabios.git code.


//Peter

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 16:46 +, Ian Campbell wrote:
> On Thu, 2013-02-14 at 14:23 +, David Woodhouse wrote:
> > git.infradead.org/users/dwmw2/seabios.git
> > 
> > There's a README.CSM file in the SeaBIOS tree which describes how to
> > build OVMF with CSM support.
> 
> Do I understand correctly from the README that once CSM support is
> enabled at build time you can choose to use it dynamically at boot time?
> If so, Neat!

Right. It's just another boot target. The UEFI device path for each of
the bot targets, and the bootorder variable which sets their relative
priorities, are stored in persistent nvram storage...

> I suppose this selection is persistent for a given VM, but where is it
> saved?

That's another item on my TODO list. On real hardware it's actually
stored in flash. On OVMF we don't have an answer. There's a dirty hack
which stores them in a *file* on the EFI system partition, but that
really isn't very helpful it stops working when the OS calls
ExitBootServices — because you can't be touching the file system at the
same time the OS might be. So when an OS installer does its install and
then sets the NV variables to boot into the newly-installed OS... it
can't work.

There was some initial work on supporting -pflash for qemu on i386 and
working exactly like real hardware does — which meant firmware upgrades
had to be done the same way since the firmware and the variables were
all in the same image. And it didn't work with KVM.

I'm looking at fixing this to use a flash device *other* than the one
that the firmware runs from, adjacent to it at the top of memory. Or
something like that. But it's not quite solved yet. It'll *need* to be,
for OVMF to be usable in the general case. And then it's solved
automatically for CSM too.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 16:47 +, David Woodhouse wrote:
> On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
> > On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> > > 
> > > Anyway, I appear to have established that the qemu fw_cfg *doesn't*
> > > exist in your domains — so how you pass bootorder to the guest, if
> > you
> > > successfully do so at all, I have no idea. 
> > 
> > Asking around no one seems to have any idea how this works, other than
> > we pass it to qemu.
> 
> *Does* it work?

People seem to think so, but I'm starting to wonder. I'm going to go and
check for myself now.

> And — more to the point, since this is my only real reason for caring
> about it at all — does it *stop* working if you build SeaBIOS from my
> tree at git.infradead.org/users/dwmw2/seabios.git ?

I will give that a go second.

Ian.
-- 
Ian Campbell

You will reach the highest possible point in your business or profession.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 16:41 +, Ian Campbell wrote:
> On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> > 
> > Anyway, I appear to have established that the qemu fw_cfg *doesn't*
> > exist in your domains — so how you pass bootorder to the guest, if
> you
> > successfully do so at all, I have no idea. 
> 
> Asking around no one seems to have any idea how this works, other than
> we pass it to qemu.

*Does* it work?

And — more to the point, since this is my only real reason for caring
about it at all — does it *stop* working if you build SeaBIOS from my
tree at git.infradead.org/users/dwmw2/seabios.git ?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 14:23 +, David Woodhouse wrote:
> On Thu, 2013-02-14 at 14:08 +, Ian Campbell wrote:
> > The chap who did our OVMF stuff has moved on to pastures new but ISTR
> > him saying something about a build bug with GCC!=44, which had been
> > fixed in upstream OVMF but not yet sync'd into the Xen tree.
> 
> Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
> building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
> http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
> although I suspect it might be incomplete and I'm about to blow away my
> local build tree and configure from scratch to retest.
> 
> But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
> line which does
> cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

Ack, thanks.

We try and support a reasonably wide range of hosts, usually we use
Debian Stable as our baseline (which is currently 4.4).

> 
> > Awesome! (I've CCd xen-devel just for their info, it's moderated for
> > non-subscribers but valid posters get whitelisted)
> 
> In that case I think the only context I need to add, for those who want
> to play along at home, is the location of my trees for OVMF and SeaBIOS.
> The OVMF one is above, and the SeaBIOS one is next to it:
> git:// or http://git.infradead.org/users/dwmw2/seabios.git
> 
> There's a README.CSM file in the SeaBIOS tree which describes how to
> build OVMF with CSM support.

Do I understand correctly from the README that once CSM support is
enabled at build time you can choose to use it dynamically at boot time?
If so, Neat!

I suppose this selection is persistent for a given VM, but where is it
saved?

>  The main reason I'm pointing you at my
> trees rather than upstream is the patch within each one that adds the
> UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
> parts of the UMB memory region should be made read-only. For Qemu with
> KVM that's a moot point because it doesn't get made read-only anyway, so
> you could just use upstream now. If you don't implement the PAM
> protection of those regions, I suspect the same might be true for you.
> Suck it and see, perhaps.

Right, we really need to find someone with hours to finish properly
integrating OVMF.

> 
> > > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > > PCIR structure unaligned. That was it.
> 
> > ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> > include? (rather than tools/firmware/vgabios/)
> 
> Yes, the one in /usr/share/qemu-xen. You want the patch from
> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

Thanks.

-- 
Ian Campbell
Current Noise: W.A.S.P. - Harder, Faster

We don't need no education, we don't need no thought control.
-- Pink Floyd


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> 
> Anyway, I appear to have established that the qemu fw_cfg *doesn't*
> exist in your domains — so how you pass bootorder to the guest, if you
> successfully do so at all, I have no idea. 

Asking around no one seems to have any idea how this works, other than
we pass it to qemu.

Oh well, this is our mystery not yours, I think.

Ian.
-- 
Ian Campbell
Current Noise: Pink Floyd - The Fletcher Memorial Home

 manoj is going nuts on the bug fixing crusade!  woo woo!
 manoj went nuts long time ago.  but the bug fixing is cool  =>


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 14:08 +, Ian Campbell wrote:
> The chap who did our OVMF stuff has moved on to pastures new but ISTR
> him saying something about a build bug with GCC!=44, which had been
> fixed in upstream OVMF but not yet sync'd into the Xen tree.

Yes, OVMF's toolchain handling is somewhat broken. I *do* have it
building with GCC 4.6 and 4.7. There's a patch in my tree at git:// and
http://git.infradead.org/users/dwmw2/edk2.git which fixes that...
although I suspect it might be incomplete and I'm about to blow away my
local build tree and configure from scratch to retest.

But your tools/ovmf-makefile could also do with s/GCC44/GCC4?/ in the
line which does
cp Build/OvmfX64/DEBUG_GCC44/FV/OVMF.fd ovmf.bin

> Awesome! (I've CCd xen-devel just for their info, it's moderated for
> non-subscribers but valid posters get whitelisted)

In that case I think the only context I need to add, for those who want
to play along at home, is the location of my trees for OVMF and SeaBIOS.
The OVMF one is above, and the SeaBIOS one is next to it:
git:// or http://git.infradead.org/users/dwmw2/seabios.git

There's a README.CSM file in the SeaBIOS tree which describes how to
build OVMF with CSM support. The main reason I'm pointing you at my
trees rather than upstream is the patch within each one that adds the
UmbStart,UmbEnd fields for negotiating between UEFI and SeaBIOS which
parts of the UMB memory region should be made read-only. For Qemu with
KVM that's a moot point because it doesn't get made read-only anyway, so
you could just use upstream now. If you don't implement the PAM
protection of those regions, I suspect the same might be true for you.
Suck it and see, perhaps.

> > I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> > PCIR structure unaligned. That was it.

> ... did you mean the VGA ROM we ship in the qemu-xen branch that we
> include? (rather than tools/firmware/vgabios/)

Yes, the one in /usr/share/qemu-xen. You want the patch from
http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation





smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 13:52 +, David Woodhouse wrote:
> On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> > 
> > I'll probably have a look at OVMF under Xen now, and making sure that my
> > CSM code works there. Then you shouldn't need to offer people the choice
> > between OVMF and SeaBIOS because you'll have one image that handles
> > everything (which is what people get on real hardware, and expect).
> 
> That part, at least, was surprisingly easy. The same OVMF images (with
> SeaBIOS-as-CSM) that I've been testing under Qemu work fine under Xen
> too. The OVMF build system is hosed for GCC 4.7 and your own Makefile
> also has 'GCC44' in the path when copying out the build result. when it
> could have been 'GCC4?' and at least been a little more robust.

The chap who did our OVMF stuff has moved on to pastures new but ISTR
him saying something about a build bug with GCC!=44, which had been
fixed in upstream OVMF but not yet sync'd into the Xen tree.

> But that's just fluff. Basically, it works.

Awesome! (I've CCd xen-devel just for their info, it's moderated for
non-subscribers but valid posters get whitelisted)

> I did need to fix the VGA ROM you're shipping for Cirrus, which has the
> PCIR structure unaligned. That was it.

I would have put a substantial sum of money on the VGA ROM we ship not
being used in the SeaBIOS configuration, since SB pulls the ROM from the
emulated cards ROM BAR. The Cirrus ROM we ship should be used with
ROMBIOS only. I wonder what's going on there (another one for my list)

Or did you mean the VGA ROM we ship in the qemu-xen branch that we
include? (rather than tools/firmware/vgabios/)

> Again, this is without actually trying to boot any OS :)

Lets not get carried away :-P

Ian.
-- 
Ian Campbell
Current Noise: Pink Floyd - Time

* weasel wonders how stupid one has to be to spam alt.anonymous.messages
 weasel: about half as stupid as one has to be to harvest it.


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> On Thu, 2013-02-14 at 12:53 +, Ian Campbell wrote:
> > 
> > I had observed once upon a time that turning up the limit caused odd
> > failures, but I'd never associated it with the size. I spent ages
> > trying
> > to track down a NULL pointer in some level>3 message and the like...
> > 
> > In hvmloader I see:
> > #define SEABIOS_PHYSICAL_ADDRESS0x000E
> > which would have to change if the image grew >128K. Really hvmloader
> > should check the size dynamically and DTRT. I can't remember why I did
> > it this way.
> 
> No idea. If I just set .bios_address = 0x10U - sizeof(seabios),
> it works just fine.
> 
> > Sorry about this, crapness on our end I think :-(
> 
> Ahem, you also have
> //BUILD_BUG_ON(sizeof(seabios) > (0x0010U - SEABIOS_PHYSICAL_ADDRESS));
> 
> Now *that* would have been a time-saver... 

Oh god, sorry.

> Another observation: 'xl -c seabios.cfg' misses the first output of the
> domain. Starting it *paused*, then running 'xl unpause seabios' in
> another terminal, lets me catch even the first 'Start bios ...' message.
> 
> If it *had* been crashing early in SeaBIOS, I'd have been cursing you
> for that one too :)

Justifiably so I think.

> Anyway, I appear to have established that the qemu fw_cfg *doesn't*
> exist in your domains — so how you pass bootorder to the guest, if you
> successfully do so at all, I have no idea. And the patch at
> http://git.infradead.org/users/dwmw2/seabios.git/commitdiff/e62d1720f
> appears to work fine — at least in the case of a domain with nothing to
> actually boot from anyway, where we expect it just to die with 'no
> bootable device'.

Erm, this might be something we Xen folks need to fix! I'm not sure if
that fix will involve using fwcfg or not...

> I'll probably have a look at OVMF under Xen now, and making sure that my
> CSM code works there. Then you shouldn't need to offer people the choice
> between OVMF and SeaBIOS because you'll have one image that handles
> everything (which is what people get on real hardware, and expect).

That would be pretty sweet, thanks!

-- 
Ian Campbell
Current Noise: Pink Floyd - Shine On You Crazy Diamond (Parts 1-7)

All language designers are arrogant.  Goes with the territory... :-)
-- Larry Wall in <1991jul13.010945.19...@netlabs.com


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 13:05 +, David Woodhouse wrote:
> 
> I'll probably have a look at OVMF under Xen now, and making sure that my
> CSM code works there. Then you shouldn't need to offer people the choice
> between OVMF and SeaBIOS because you'll have one image that handles
> everything (which is what people get on real hardware, and expect).

That part, at least, was surprisingly easy. The same OVMF images (with
SeaBIOS-as-CSM) that I've been testing under Qemu work fine under Xen
too. The OVMF build system is hosed for GCC 4.7 and your own Makefile
also has 'GCC44' in the path when copying out the build result. when it
could have been 'GCC4?' and at least been a little more robust. But
that's just fluff. Basically, it works.

I did need to fix the VGA ROM you're shipping for Cirrus, which has the
PCIR structure unaligned. That was it.

Again, this is without actually trying to boot any OS :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 2/5] geodevga: move framebuffer setup

[Christian Gmeiner]

Framebuffer setup has nothing to do with dc_setup(..) so
move it to  geodevga_init(..).

Signed-off-by: Christian Gmeiner 
---
 vgasrc/geodevga.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index ef840a4..e96698c 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -218,22 +218,10 @@ static void dc_setup(void)
 geode_dc_write(DC_CB_ST_OFFSET, 0x0);
 geode_dc_write(DC_CURS_ST_OFFSET, 0x0);
 
-/* read fb-bar from pci, then point dc to the fb base */
-u32 fb = GET_GLOBAL(GeodeFB);
-if (geode_dc_read(DC_GLIU0_MEM_OFFSET) != fb)
-geode_dc_write(DC_GLIU0_MEM_OFFSET, fb);
-
 geode_dc_mask(DC_DISPLAY_CFG, ~DC_CFG_MSK, 
DC_DISPLAY_CFG_GDEN|DC_DISPLAY_CFG_TRUP);
 geode_dc_write(DC_GENERAL_CFG, DC_DISPLAY_CFG_VGAE);
 
 geode_dc_write(DC_UNLOCK, DC_LOCK_LOCK);
-
-u32 fb_size = framebuffer_size(); // in byte
-dprintf(1, "%d KB of video memory at 0x%08x\n", fb_size / 1024, fb);
-
-/* update VBE variables */
-SET_VGA(VBE_framebuffer, fb);
-SET_VGA(VBE_total_memory, fb_size / 1024 / 64); // number of 64K blocks
 }
 
 /* Setup the vp (video processor) portion of the geodelx
@@ -408,6 +396,23 @@ int geodevga_setup(void)
 dprintf(1, "dc addr: 0x%08x\n", GET_GLOBAL(GeodeDC));
 dprintf(1, "vp addr: 0x%08x\n", GET_GLOBAL(GeodeVP));
 
+/* setup framebuffer */
+geode_dc_write(DC_UNLOCK, DC_LOCK_UNLOCK);
+
+/* read fb-bar from pci, then point dc to the fb base */
+u32 fb = GET_GLOBAL(GeodeFB);
+if (geode_dc_read(DC_GLIU0_MEM_OFFSET) != fb)
+geode_dc_write(DC_GLIU0_MEM_OFFSET, fb);
+
+geode_dc_write(DC_UNLOCK, DC_LOCK_LOCK);
+
+u32 fb_size = framebuffer_size(); // in byte
+dprintf(1, "%d KB of video memory at 0x%08x\n", fb_size / 1024, fb);
+
+/* update VBE variables */
+SET_VGA(VBE_framebuffer, fb);
+SET_VGA(VBE_total_memory, fb_size / 1024 / 64); // number of 64K blocks
+
 vp_setup();
 dc_setup();
 
-- 
1.7.12.2.421.g261b511


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[Fred .]

I oppose the name runningOnXen() !
I propose the name running_on_Xen()
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 12:53 +, Ian Campbell wrote:
> 
> I had observed once upon a time that turning up the limit caused odd
> failures, but I'd never associated it with the size. I spent ages
> trying
> to track down a NULL pointer in some level>3 message and the like...
> 
> In hvmloader I see:
> #define SEABIOS_PHYSICAL_ADDRESS0x000E
> which would have to change if the image grew >128K. Really hvmloader
> should check the size dynamically and DTRT. I can't remember why I did
> it this way.

No idea. If I just set .bios_address = 0x10U - sizeof(seabios),
it works just fine.

> Sorry about this, crapness on our end I think :-(

Ahem, you also have
//BUILD_BUG_ON(sizeof(seabios) > (0x0010U - SEABIOS_PHYSICAL_ADDRESS));

Now *that* would have been a time-saver... 

Another observation: 'xl -c seabios.cfg' misses the first output of the
domain. Starting it *paused*, then running 'xl unpause seabios' in
another terminal, lets me catch even the first 'Start bios ...' message.

If it *had* been crashing early in SeaBIOS, I'd have been cursing you
for that one too :)

Anyway, I appear to have established that the qemu fw_cfg *doesn't*
exist in your domains — so how you pass bootorder to the guest, if you
successfully do so at all, I have no idea. And the patch at
http://git.infradead.org/users/dwmw2/seabios.git/commitdiff/e62d1720f
appears to work fine — at least in the case of a domain with nothing to
actually boot from anyway, where we expect it just to die with 'no
bootable device'.

I'll probably have a look at OVMF under Xen now, and making sure that my
CSM code works there. Then you shouldn't need to offer people the choice
between OVMF and SeaBIOS because you'll have one image that handles
everything (which is what people get on real hardware, and expect).

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[Ian Campbell]

On Thu, 2013-02-14 at 12:29 +, David Woodhouse wrote:
> On Thu, 2013-02-14 at 11:27 +, Ian Campbell wrote:
> > I've attached an hvmloader which I just built from the 4.2 stable branch
> > and have smoke tested, does it work for you?
> 
> FFS. Is it too early to start drinking yet? A 256KiB ROM image fails as
> I have described, while a 128KiB image works fine. So turning up the
> debug level — as I had done in all my builds — basically makes it fail.
> 
> If I only turn it up to 3 and then keep turning off the unused
> default-enabled drivers until the image fits in 128KiB again, it works.
> So I'm fairly sure it *is* the size limit.
> 
> Is that a known issue?

I had observed once upon a time that turning up the limit caused odd
failures, but I'd never associated it with the size. I spent ages trying
to track down a NULL pointer in some level>3 message and the like...

In hvmloader I see:
#define SEABIOS_PHYSICAL_ADDRESS0x000E
which would have to change if the image grew >128K. Really hvmloader
should check the size dynamically and DTRT. I can't remember why I did
it this way.

Sorry about this, crapness on our end I think :-(

I've added this to my TODO list.
Ian.
-- 
Ian Campbell

Most people in this society who aren't actively mad are, at best,
reformed or potential lunatics.
-- Susan Sontag


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCHv2 0/6] Improved multi-platform support

[David Woodhouse]

On Thu, 2013-02-14 at 11:27 +, Ian Campbell wrote:
> I've attached an hvmloader which I just built from the 4.2 stable branch
> and have smoke tested, does it work for you?

FFS. Is it too early to start drinking yet? A 256KiB ROM image fails as
I have described, while a 128KiB image works fine. So turning up the
debug level — as I had done in all my builds — basically makes it fail.

If I only turn it up to 3 and then keep turning off the unused
default-enabled drivers until the image fits in 128KiB again, it works.
So I'm fairly sure it *is* the size limit.

Is that a known issue?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 4/5] geodevga: add debug to msr functions

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 vgasrc/geodevga.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index 50216b6..42e2eeb 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -33,6 +33,9 @@ static u64 geode_msr_read(u32 msrAddr)
 : "c"(msrAddr)
 : "cc"
 );
+
+dprintf(4, "%s(0x%08x) = 0x%08x-0x%08x\n"
+, __func__, msrAddr, val.hi, val.lo);
 return val.val;
 }
 
@@ -41,6 +44,10 @@ static void geode_msr_mask(u32 msrAddr, u64 off, u64 on)
 union u64_u32_u uand, uor;
 uand.val = ~off;
 uor.val = on;
+
+dprintf(4, "%s(0x%08x, 0x%016llx, 0x%016llx)\n"
+, __func__, msrAddr, off, on);
+
 asm __volatile__ (
 "push   %%eax   \n"
 "movw   $0x0AC1C, %%dx  \n"
-- 
1.7.12.2.421.g261b511


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH] geodevga: fix wrong define name

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 vgasrc/geodevga.c | 2 +-
 vgasrc/geodevga.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index 42e2eeb..e508cbd 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -258,7 +258,7 @@ static void dc_setup(void)
 geode_dc_write(DC_CURS_ST_OFFSET, 0x0);
 
 geode_dc_mask(DC_DISPLAY_CFG, ~DC_CFG_MSK, 
DC_DISPLAY_CFG_GDEN|DC_DISPLAY_CFG_TRUP);
-geode_dc_write(DC_GENERAL_CFG, DC_DISPLAY_CFG_VGAE);
+geode_dc_write(DC_GENERAL_CFG, DC_GENERAL_CFG_VGAE);
 
 geode_dc_write(DC_UNLOCK, DC_LOCK_LOCK);
 }
diff --git a/vgasrc/geodevga.h b/vgasrc/geodevga.h
index 180bd05..067b4f8 100644
--- a/vgasrc/geodevga.h
+++ b/vgasrc/geodevga.h
@@ -65,7 +65,7 @@
 
 
 /* DC bits */
-#define DC_DISPLAY_CFG_VGAE (1 << 7)
+#define DC_GENERAL_CFG_VGAE (1 << 7)
 #define DC_DISPLAY_CFG_GDEN (1 << 3)
 #define DC_DISPLAY_CFG_TRUP (1 << 6)
 
-- 
1.7.12.2.421.g261b511


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 5/5] geodevga: fix wrong define name

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 vgasrc/geodevga.c | 2 +-
 vgasrc/geodevga.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index 42e2eeb..e508cbd 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -258,7 +258,7 @@ static void dc_setup(void)
 geode_dc_write(DC_CURS_ST_OFFSET, 0x0);
 
 geode_dc_mask(DC_DISPLAY_CFG, ~DC_CFG_MSK, 
DC_DISPLAY_CFG_GDEN|DC_DISPLAY_CFG_TRUP);
-geode_dc_write(DC_GENERAL_CFG, DC_DISPLAY_CFG_VGAE);
+geode_dc_write(DC_GENERAL_CFG, DC_GENERAL_CFG_VGAE);
 
 geode_dc_write(DC_UNLOCK, DC_LOCK_LOCK);
 }
diff --git a/vgasrc/geodevga.h b/vgasrc/geodevga.h
index 180bd05..067b4f8 100644
--- a/vgasrc/geodevga.h
+++ b/vgasrc/geodevga.h
@@ -65,7 +65,7 @@
 
 
 /* DC bits */
-#define DC_DISPLAY_CFG_VGAE (1 << 7)
+#define DC_GENERAL_CFG_VGAE (1 << 7)
 #define DC_DISPLAY_CFG_GDEN (1 << 3)
 #define DC_DISPLAY_CFG_TRUP (1 << 6)
 
-- 
1.7.12.2.421.g261b511


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 1/5] geodevga: fix errors in geode_fp_* functions

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 vgasrc/geodevga.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index c2dabf5..ef840a4 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -140,7 +140,7 @@ static u32 geode_fp_read(int reg)
 {
 u32 val = geode_mem_read(GET_GLOBAL(GeodeVP) + VP_FP_START + reg);
 dprintf(4, "%s(0x%08x) = 0x%08x\n"
-, __func__, GET_GLOBAL(GeodeVP) + reg, val);
+, __func__, GET_GLOBAL(GeodeVP) + VP_FP_START + reg, val);
 return val;
 }
 
@@ -148,7 +148,7 @@ static void geode_fp_write(int reg, u32 val)
 {
 dprintf(4, "%s(0x%08x, 0x%08x)\n"
 , __func__, GET_GLOBAL(GeodeVP) + VP_FP_START + reg, val);
-geode_mem_mask(GET_GLOBAL(GeodeVP) + reg, ~0, val);
+geode_mem_mask(GET_GLOBAL(GeodeVP) + VP_FP_START + reg, ~0, val);
 }
 
 /
-- 
1.7.12.2.421.g261b511


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 3/5] geodevga: move output setup to own function

[Christian Gmeiner]

Signed-off-by: Christian Gmeiner 
---
 vgasrc/geodevga.c | 64 ++-
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
index e96698c..50216b6 100644
--- a/vgasrc/geodevga.c
+++ b/vgasrc/geodevga.c
@@ -204,6 +204,38 @@ static u32 framebuffer_size(void)
 * Init Functions
 /
 
+static void geodevga_set_output_mode(void)
+{
+u64 msr_addr;
+u64 msr;
+
+/* set output to crt and RGB/YUV */
+if (CONFIG_VGA_GEODEGX2)
+msr_addr = VP_MSR_CONFIG_GX2;
+else
+msr_addr = VP_MSR_CONFIG_LX;
+
+/* set output mode (RGB/YUV) */
+msr = geode_msr_read(msr_addr);
+msr &= ~VP_MSR_CONFIG_FMT; // mask out FMT (bits 5:3)
+
+if (CONFIG_VGA_OUTPUT_PANEL || CONFIG_VGA_OUTPUT_CRT_PANEL) {
+msr |= VP_MSR_CONFIG_FMT_FP;   // flat panel
+
+if (CONFIG_VGA_OUTPUT_CRT_PANEL) {
+msr |= VP_MSR_CONFIG_FPC;  // simultaneous Flat Panel and CRT
+dprintf(1, "output: simultaneous Flat Panel and CRT\n");
+} else {
+msr &= ~VP_MSR_CONFIG_FPC; // no simultaneous Flat Panel and CRT
+dprintf(1, "ouput: flat panel\n");
+}
+} else {
+msr |= VP_MSR_CONFIG_FMT_CRT;  // CRT only
+   dprintf(1, "output: CRT\n");
+}
+geode_msr_mask(msr_addr, ~msr, msr);
+}
+
 /* Set up the dc (display controller) portion of the geodelx
 *  The dc provides hardware support for VGA graphics.
 */
@@ -232,37 +264,9 @@ static void dc_setup(void)
 */
 static void vp_setup(void)
 {
-u32 msr_addr;
-u64 msr;
-
 dprintf(2,"VP_SETUP\n");
 
-/* set output to crt and RGB/YUV */
-if (CONFIG_VGA_GEODEGX2)
-msr_addr = VP_MSR_CONFIG_GX2;
-else
-msr_addr = VP_MSR_CONFIG_LX;
-
-/* set output mode (RGB/YUV) */
-msr = geode_msr_read(msr_addr);
-msr &= ~VP_MSR_CONFIG_FMT; // mask out FMT (bits 5:3)
-
-if (CONFIG_VGA_OUTPUT_PANEL || CONFIG_VGA_OUTPUT_CRT_PANEL) {
-msr |= VP_MSR_CONFIG_FMT_FP;   // flat panel
-
-if (CONFIG_VGA_OUTPUT_CRT_PANEL) {
-msr |= VP_MSR_CONFIG_FPC;  // simultaneous Flat Panel and CRT
-dprintf(1, "output: simultaneous Flat Panel and CRT\n");
-} else {
-msr &= ~VP_MSR_CONFIG_FPC; // no simultaneous Flat Panel and CRT
-dprintf(1, "ouput: flat panel\n");
-}
-} else {
-msr |= VP_MSR_CONFIG_FMT_CRT;  // CRT only
-   dprintf(1, "output: CRT\n");
-}
-geode_msr_mask(msr_addr, ~msr, msr);
-
+geodevga_set_output_mode();
 
 /* Set mmio registers
 * there may be some timing issues here, the reads seem
@@ -283,6 +287,8 @@ static void vp_setup(void)
 
 /* setup flat panel */
 if (CONFIG_VGA_OUTPUT_PANEL || CONFIG_VGA_OUTPUT_CRT_PANEL) {
+u64 msr;
+
 dprintf(1, "Setting up flat panel\n");
 /* write timing register */
 geode_fp_write(FP_PT1, 0x0);
-- 
1.7.12.2.421.g261b511


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[Gerd Hoffmann]

  Hi,

> Granted, CONFIG_OPTIONROMS_DEPLOYED isn't terribly useful - it's
> probably about time all that code was just removed.  (Or at least set
> to depends on QEMU.)

IMO it can go away.  The corresponding code in qemu is gone since 0.12,
so you'll break seabios for qemu 0.11 + older (that are those releases
which ship with bochs bios ...).

cheers,
  Gerd


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios