On Tue, Jul 17, 2012 at 12:08:59PM +0200, Christian Gmeiner wrote:
> This commit just simplifies some code.
>
> Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com>
> ---
> vgasrc/geodevga.c | 48 +++++++++---------------------------------------
> 1 file changed, 9 insertions(+), 39 deletions(-)
>
> diff --git a/vgasrc/geodevga.c b/vgasrc/geodevga.c
> index 5c6caf0..4e3d912 100644
> --- a/vgasrc/geodevga.c
> +++ b/vgasrc/geodevga.c
[...]
> /* Set mmio registers
> * there may be some timing issues here, the reads seem
> * to slow things down enough work reliably
> */
>
> - reg = geode_memRead(vp+VP_MISC);
> + reg = readl(vp+VP_MISC);
The code is run in 16bit "big real" mode. This means all of memory is
available, but one still needs to be careful about segment usage.
SeaBIOS always calls the option roms with a %ss == %ds == 0, but I
don't think it is wise to rely upon that. So, it's better to use
GET_FARVAR(0, *(vp+VP_MISC)).
-Kevin
On Thu, Jul 26, 2012 at 03:38:47PM +0000, Alexey Korolev wrote:
> HI,
>
> Current version of Seabios is causing blue screen on Windows2003 when 64bit PCI resource is present and occupies high memory.
>
> BSOD Error code is: 0x000000A5 (0x02, 0xFFFFfADF6A446880, 0x1, 0xFFFFFADFAA34690)
>
> The issue is localized, it is related to presence of 64bit resource in _CRS method.
>
> If we disable a 64bit region from _CRS the Win2003 load normally but this doesn't allow Windows to use 64bit resources.
>
> At the moment I have no idea how to fix this. Please help!
Unfortunately, it's very difficult to debug acpi issues on Windows.
Gerd's been on vacation this week - so, lets give him a chance to look
at it when he gets back. If it can't be resolved, we'll need to
revert the patch that broke Win2003.
> P/S
> Yet another issue is related to debug messages.
> If I add any DBUG call in acpi-dst it will cause BSOD on win2003 (win2008 works fine)
I've seen this as well (on WinXP - I don't have Win2003).
Unfortunately, I haven't been able to find out why the debug macro
fails on these older versions of Windows.
-Kevin
More than 1kb of data is taken by the 32 copies of the PCI hotplug SSDT
methods. We can build them from a single template like we do for CPUs.
This series does exactly this. Patches 1 and 2 prepare for the change,
by moving other pieces of ssdt-pcihd.dsl out of the way. Patch 3 is also
a simple rename and patch 4 fixes a bug in acpi_extract. Patches 5 and
6 finally do the movement.
Paolo Bonzini (6):
acpi: move PCNT to DSDT
acpi: move s3/s4/s5 to build_ssdt
acpi: rename Processor SSDT constants
acpi_extract: fix off-by-one
acpi_extract: detect DeviceOp
acpi: build PCI hotplug devices from a single template
Makefile | 2 +-
src/acpi-dsdt.dsl | 39 +++++++++++-
src/acpi.c | 161 ++++++++++++++++++++++++++-----------------------
src/ssdt-pcihp.dsl | 124 ++++---------------------------------
src/ssdt-susp.dsl | 41 +++++++++++++
tools/acpi_extract.py | 30 ++++++++-
6 files changed, 206 insertions(+), 191 deletions(-)
create mode 100644 src/ssdt-susp.dsl
--
1.7.10.4
1ms seems to short on my chromebook, increasing that
to 5ms makes EHCI work.
Signed-off-by: Sven Schnelle <svens(a)stackframe.org>
---
src/usb-ehci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/usb-ehci.c b/src/usb-ehci.c
index 3c0be13..b53caa1 100644
--- a/src/usb-ehci.c
+++ b/src/usb-ehci.c
@@ -82,7 +82,7 @@ ehci_hub_detect(struct usbhub_s *hub, u32 port)
writel(portreg, portsc);
msleep(EHCI_TIME_POSTPOWER);
} else {
- msleep(1); // XXX - time for connect to be detected.
+ msleep(5); // XXX - time for connect to be detected.
}
portsc = readl(portreg);
--
1.7.10.4
Yes, for whatever reason, it is definitely an issue with the newer version of bison. None of the code below is output with bison 2.4.2:
#if YYDEBUG
extern int AslCompilerdebug;
#endif
#ifdef YYPARSE_PARAM
#if defined __STDC__ || defined __cplusplus
int AslCompilerparse (void *YYPARSE_PARAM);
#else
int AslCompilerparse ();
#endif
#else /* ! YYPARSE_PARAM */
#if defined __STDC__ || defined __cplusplus
int AslCompilerparse (void);
#else
int AslCompilerparse ();
#endif
#endif /* ! YYPARSE_PARAM */
> -----Original Message-----
> From: Idwer Vollering [mailto:vidwer@gmail.com]
> Sent: Tuesday, July 31, 2012 2:20 PM
> To: Moore, Robert
> Cc: Michael S. Tsirkin; Kevin O'Connor; seabios(a)seabios.org; Tang, Feng
> Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with
> its ACPI code
>
> 2012/7/31 Moore, Robert <robert.moore(a)intel.com>:
> > And, could you please send the bison output file "aslcompilerparse.h"
> >
> > Thanks,
> > Bob
>
> Attached.
2012/7/31 Moore, Robert <robert.moore(a)intel.com>:
> And, could you please send the bison output file "aslcompilerparse.h"
>
> Thanks,
> Bob
Attached.
And, could you please send the bison output file "aslcompilerparse.h"
Thanks,
Bob
> -----Original Message-----
> From: Moore, Robert
> Sent: Tuesday, July 31, 2012 1:37 PM
> To: 'Idwer Vollering'
> Cc: Michael S. Tsirkin; Kevin O'Connor; seabios(a)seabios.org; Tang, Feng
> Subject: RE: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with
> its ACPI code
>
> This looks like it may be a Bison issue, since the file
> "aslcompilerparse.h" is in fact an intermediate file created by Bison.
> With Bison version 2.4.1, there is no declaration of "AslCompilerparse"
> within the aslcompilerparse.h file.
>
> Could you try an earlier version of Bison?
>
>
>
>
> In file included from aslanalyze.c:118:0:
> aslcompilerparse.h:738:5: error: redundant redeclaration of
> 'AslCompilerparse' [-Werror=redundant-decls]
>
> In file included from aslanalyze.c:117:0:
> aslcompiler.h:163:1: note: previous declaration of 'AslCompilerparse'
> was
>
>
>
> > -----Original Message-----
> > From: Idwer Vollering [mailto:vidwer@gmail.com]
> > Sent: Tuesday, July 31, 2012 1:27 PM
> > To: Moore, Robert
> > Cc: Michael S. Tsirkin; Kevin O'Connor; seabios(a)seabios.org; Tang,
> > Feng
> > Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems
> > with its ACPI code
> >
> > 2012/7/31 Moore, Robert <robert.moore(a)intel.com>:
> > > On Debian, we are using
> > >
> > > Flex 2.5.35
> > > Bison 2.4.1
> >
> > My build machine runs 64-bit archlinux and has gcc 4.7.1, flex 2.5.36
> > and bison 2.6 installed.
> >
> > P.S. please use reply-to-all, so everyone is informed.
This looks like it may be a Bison issue, since the file "aslcompilerparse.h" is in fact an intermediate file created by Bison. With Bison version 2.4.1, there is no declaration of "AslCompilerparse" within the aslcompilerparse.h file.
Could you try an earlier version of Bison?
In file included from aslanalyze.c:118:0:
aslcompilerparse.h:738:5: error: redundant redeclaration of 'AslCompilerparse' [-Werror=redundant-decls]
In file included from aslanalyze.c:117:0:
aslcompiler.h:163:1: note: previous declaration of 'AslCompilerparse' was
> -----Original Message-----
> From: Idwer Vollering [mailto:vidwer@gmail.com]
> Sent: Tuesday, July 31, 2012 1:27 PM
> To: Moore, Robert
> Cc: Michael S. Tsirkin; Kevin O'Connor; seabios(a)seabios.org; Tang, Feng
> Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with
> its ACPI code
>
> 2012/7/31 Moore, Robert <robert.moore(a)intel.com>:
> > On Debian, we are using
> >
> > Flex 2.5.35
> > Bison 2.4.1
>
> My build machine runs 64-bit archlinux and has gcc 4.7.1, flex 2.5.36
> and bison 2.6 installed.
>
> P.S. please use reply-to-all, so everyone is informed.