Frediano Ziglio <frediano.ziglio(a)citrix.com> writes:
> On Fri, 2012-08-10 at 16:24 +0200, Peter Stuge wrote:
>> Fred . wrote:
>> > No, I am not.
>>
>> Ok, so there's only a hypothesis.
>>
>>
>> > But I believe QEMU does have the functionality to load an arbitrary
>> > firmware. So the firmware doesn't necessarily have to be SeaBIOS.
>>
>> As you may know the 8086 reset vector is at 1MB-16 so it will be
>> really difficult to run a PC-like machine with less than 1MB of
>> memory. I don't believe one has ever existed.
>>
>
> I remember that my manual of the NEC V20 (a 8086 clone with 10 MHZ!) has
> settings for 256KB of RAM (jumpers of course!)
>
> The ROM was "mapped" (physically!) at f0000 with extended ROM at e0000.
According to Wikipedia, the original IBM PC was sold with as little as
16KiB RAM. IIRC, 64KiB BIOS ROM at the top of the 1MiB address space.
http://en.wikipedia.org/wiki/IBM_PC
[...]
Fred . wrote:
> No, I am not.
Ok, so there's only a hypothesis.
> But I believe QEMU does have the functionality to load an arbitrary
> firmware. So the firmware doesn't necessarily have to be SeaBIOS.
As you may know the 8086 reset vector is at 1MB-16 so it will be
really difficult to run a PC-like machine with less than 1MB of
memory. I don't believe one has ever existed.
> Don't know if its possible to make QEMU use an UEFI or OpenFirmware
> image instead, or if such an image exists.
Sure, but UEFI rather requires 1GB than 1MB.
//Peter
Fred . wrote:
> But QEMU may use other firmware/payload than SeaBIOS which might
> require less than 1 MB of RAM.
Really? Are you working on one?
//Peter
Watch this:
$ qemu-system-x86_64 -nodefaults -vnc :0 -monitor stdio -m 16k
QEMU 1.1.50 monitor - type 'help' for more information
(qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000000004000
Admittedly a silly thing to try. I don't really expect SeaBIOS to work
with 16KiB of RAM. But I'm curious: how much does it require?
On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote:
> This is very interesting. If I understand correctly, you are using a
> utility plus various directives to generate tables of AML offsets --
> presumably in order to dynamically change AML values, correct?
Yes - exactly. We started off completely generating the SSDT
dynamically, but that got awkward when we needed to generate Processor
objects dynamically. So, we compiled an SSDT as template and then
patched it. It was fragile to hard-code the offsets, so a tool was
written to parse the IASL output and generate the offsets
automatically.
I'm CC'ing the coreboot list - they have also been doing SSDT runtime
generation.
> I have to say that I have not seen anything like this, from any BIOS vendor.
>
> > By the way, is there interest in adding some of the functionality that
> > we get by parsing the listing to iasl directly?
>
> We are always interested in adding features to make the compiler
> more useful. What would you suggest?
The tool currently generates offsets and can rename the Amlcode[]
variable to something more unique. I'm sure additional features could
be thought up.
-Kevin
On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote:
> This is very interesting. If I understand correctly, you are using a utility plus various directives to generate tables of AML offsets -- presumably in order to dynamically change AML values, correct?
>
Yes.
> I have to say that I have not seen anything like this, from any BIOS vendor.
>
Physical HW is not as dynamic (if at all) as virtualized one. We do not
want to have separate AML table for each possible HW configuration user
can create while starting QEMU.
> > By the way, is there interest in adding some of the functionality that
> > we get by parsing the listing to iasl directly?
>
> We are always interested in adding features to make the compiler more useful. What would you suggest?
>
The tool depends on the compiler output and thus fragile. It broke with new
compiler version. It would be nice if compiler had a way to generate
offsets for us.
> Bob
>
>
> > -----Original Message-----
> > From: Michael S. Tsirkin [mailto:mst@redhat.com]
> > Sent: Sunday, August 05, 2012 1:45 PM
> > To: Moore, Robert
> > Cc: Idwer Vollering; Kevin O'Connor; seabios(a)seabios.org; Tang, Feng
> > Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with
> > its ACPI code
> >
> > On Sun, Aug 05, 2012 at 11:36:15PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jul 30, 2012 at 07:42:48PM +0000, Moore, Robert wrote:
> > > > Yes, you are correct, the listing no longer includes the comments.
> > > >
> > > > Sorry for causing you a problem.
> > > >
> > > > What is happening is that the preprocessor parser is stripping the
> > comments during the creation of the .i file. Then, the compiler is
> > invoked on the .i file -- thus, the comments are gone.
> > > >
> > > > This is going to take a bit of work to correct, but we will do it.
> > > >
> > > > In the meantime, try using the -Pn flag to disable the
> > preprocessor. When this flag is set, the preprocessor is completely
> > bypassed and the compiler should function as it did previously.
> > >
> > >
> > > So we are doing it this way meanwhile. If you change this
> > > preprocessor behaviour like you indicated you would, please let us
> > > know so e can test.
> > >
> > > Thanks!
> >
> > By the way, is there interest in adding some of the functionality that
> > we get by parsing the listing to iasl directly?
> > Here's what our tool currently supports:
> >
> > # Process mixed ASL/AML listing (.lst file) produced by iasl -l #
> > Locate and execute ACPI_EXTRACT directives, output offset info # #
> > Documentation of ACPI_EXTRACT_* directive tags:
> > #
> > # These directive tags output offset information from AML for BIOS
> > runtime # table generation.
> > # Each directive is of the form:
> > # ACPI_EXTRACT_<TYPE> <array_name> <Operator> (...) # and causes the
> > extractor to create an array # named <array_name> with offset, in the
> > generated AML, # of an object of a given type in the following
> > <Operator>.
> > #
> > # A directive must fit on a single code line.
> > #
> > # Object type in AML is verified, a mismatch causes a build failure.
> > #
> > # Directives and operators currently supported are:
> > # ACPI_EXTRACT_NAME_DWORD_CONST - extract a Dword Const object from
> > Name() # ACPI_EXTRACT_NAME_WORD_CONST - extract a Word Const object
> > from Name() # ACPI_EXTRACT_NAME_BYTE_CONST - extract a Byte Const
> > object from Name() # ACPI_EXTRACT_METHOD_STRING - extract a NameString
> > from Method() # ACPI_EXTRACT_NAME_STRING - extract a NameString from
> > Name() # ACPI_EXTRACT_PROCESSOR_START - start of Processor() block #
> > ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from Processor() #
> > ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processor() + 1 #
> > ACPI_EXTRACT_PKG_START - start of Package block # #
> > ACPI_EXTRACT_ALL_CODE - create an array storing the generated AML
> > bytecode # # ACPI_EXTRACT is not allowed anywhere else in code, except
> > in comments.
> >
> >
> > Example:
> >
> > ACPI_EXTRACT_NAME_DWORD_CONST aml_adr_dword
> > Name (_ADR, 0x00010000)
> >
> > adds the offset of 0x00010000 constant to array aml_adr_dword
> >
> > Example:
> >
> > ACPI_EXTRACT_METHOD_STRING aml_ej0_name
> > Method (_EJ0, 1) { Return(PCEJ(0x0001)) }
> >
> > adds the offset of _EJ0 string to array aml_ej0_name
> >
> > ACPI_EXTRACT_ALL_CODE ssdp_pcihp_aml
> >
> > names the array to include the generated AML code
> >
> > --
> > MST
>
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS(a)seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
--
Gleb.
Hi, I've been wanting to monitor the source code changes to SeaBIOS via web browser and lately I haven't been able to. For the past few months the occasional "unable to allocate memory for pool" error would show up, but generally after hitting the refresh button 10 to 15 times would fix the problem when browsing the following site:
http://code.coreboot.org/p/seabios/
During the past few weeks however, the "latest updates" link has been broken. The error I get is:
PlufErrorHandlerException making GET request to /p/seabios/timeline/all/
8 : Undefined offset: 1
PHP/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Cache/File.php, line 102
URIGET /p/seabios/timeline/all/
Here is the stacktrace:
PlufErrorHandler [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Cache/File.php, line 102]
Pluf_Cache_File->get [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/src/IDF/Scm.php, line 473]
IDF_Scm::syncTimeline [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/src/IDF/Views/Project.php, line 121]
IDF_Views_Project::determineModelClasses [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/src/IDF/Views/Project.php, line 182]
IDF_Views_Project->timeline [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Dispatcher.php, line 202]
Pluf_Dispatcher::send [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Dispatcher.php, line 129]
Pluf_Dispatcher::match [/srv/www/vhosts/code.coreboot.org-private_data/pluf.git/src/Pluf/Dispatcher.php, line 56]
Pluf_Dispatcher::dispatch [/srv/www/vhosts/code.coreboot.org-private_data/indefero.git/www/index.php, line 28]
Is it just me or is this a global problem?
Checking out the source code via git and using "git log" works and has never been an issue for me. I just wanted to point this problem out as I am not sure this is a known issue.
Thanks!
-Alec
On Mon, Jul 30, 2012 at 07:42:48PM +0000, Moore, Robert wrote:
> Yes, you are correct, the listing no longer includes the comments.
>
> Sorry for causing you a problem.
>
> What is happening is that the preprocessor parser is stripping the comments during the creation of the .i file. Then, the compiler is invoked on the .i file -- thus, the comments are gone.
>
> This is going to take a bit of work to correct, but we will do it.
>
> In the meantime, try using the -Pn flag to disable the preprocessor. When this flag is set, the preprocessor is completely bypassed and the compiler should function as it did previously.
So we are doing it this way meanwhile. If you change this preprocessor
behaviour like you indicated you would, please let us know so e can
test.
Thanks!
--
MST
Matthew Millman wrote:
> This line in usb-uhci.c (reset_uhci()) broke it:
>
> pci_config_writew(bdf, USBLEGSUP, USBLEGSUP_RWC);
>
> According to the US15W datasheet, there is no register at this offset,
> there does seem to be something there because it reads 0x0400 after that
> write, but I don't think it's what SeaBIOS is thinking it is...
>
> USB Keyboard is working. Woohoo!
Yay! Please send a patch. It may not go in as-is, but it's a good
help for looking deeper into the issue.
//Peter