[SeaBIOS] Check if Wikipedia is correct and not outdated
Hi Please check if Wikipedia is correct and not outdated. The SeaBIOS article. https://en.wikipedia.org/wiki/SeaBIOS The BIOS comparison which includes SeaBIOS. https://en.wikipedia.org/wiki/BIOS#Vendors_and_products Thanks! ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Merge the SLIC patch
Ok, thanks. On Thu, Feb 13, 2020 at 3:31 PM Gerd Hoffmann wrote: > > On Thu, Feb 13, 2020 at 03:01:21PM +0100, Fred .Flintstone wrote: > > But what about when you run SeaBIOS on a real machine instead of in a > > virtual machine? > > acpi tables come from coreboot then. > ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Merge the SLIC patch
But what about when you run SeaBIOS on a real machine instead of in a virtual machine? On Thu, Feb 13, 2020 at 2:59 PM Gerd Hoffmann wrote: > > On Thu, Feb 13, 2020 at 10:41:57AM +0100, Fred .Flintstone wrote: > > There is a patch for ACPI Table Extraction / SeaBIOS SLIC Integration. > > > > https://github.com/ghuntley/seaslic > > > > Why isn't the SLIC patch merged into upstreams SeaBIOS? > > I doubt you need that. seabios loads the acpi tables from qemu these > days. Probably "qemu-system-x86_64 -acpitable > file=/sys/firmware/acpi/tables/SLIC" just works. > > cheers, > Gerd > ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Is Wikipedia correct?
Since there are exports on this mailing lists on SeaBIOS and BIOS in general, please check if Wikipedia is correct, if any information is wrong or outdated or missing. https://en.wikipedia.org/wiki/SeaBIOS https://en.wikipedia.org/wiki/BIOS#Vendors_and_products ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Merge the SLIC patch
There is a patch for ACPI Table Extraction / SeaBIOS SLIC Integration. https://github.com/ghuntley/seaslic Why isn't the SLIC patch merged into upstreams SeaBIOS? ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
Re: [SeaBIOS] [PATCH] vgasrc: add HDTV resolutions (1280x768, 1280x720, 1920x1080)
Well now would be a good time for someone to write that 4K patch while this
is being done anyway.
Dell is now launching their new Ultrasharp UP2414Q which is a 24" screen
with 4K resolution. It will feature 3 840 x 2 160 resolution.
While preparing for that, take a look at 8K too.
https://en.wikipedia.org/wiki/8K_resolution
https://en.wikipedia.org/wiki/Ultra_high_definition_television
On Sat, Nov 30, 2013 at 10:29 AM, Michael Tokarev wrote:
> 30.11.2013 03:18, Kevin O'Connor wrote:
> []
> >> { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
> >> +{ 0x18d, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
> >> +{ 0x18d, { MM_DIRECT, 1280, 720, 24, 8, 16, SEG_GRAPH } },
> >> +{ 0x18e, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
> >> +{ 0x18f, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
> >
> > Something's not right here (two 0x18d, 0x18f has 16bit bpp).
>
> Duh. I fixed it in the working tree but forgot to commit--amend the fix.
> I'll send a v2. Thank you!
>
> /mjt
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgasrc: add HDTV resolutions (1280x768, 1280x720, 1920x1080)
1920 × 1200 is a pretty common resolution.
On computers, not on TVs.
Also, now there is UHD TV resolutions. The 4K resolutions.
Like 3840 × 2160 and 4096 × 2160.
On Sat, Nov 30, 2013 at 12:18 AM, Kevin O'Connor wrote:
> On Fri, Nov 29, 2013 at 11:12:32PM +0400, Michael Tokarev wrote:
> > The same set were added to vgabios at version 0.7a.
>
> Thanks. See below.
>
> > --- a/vgasrc/bochsvga.c
> > +++ b/vgasrc/bochsvga.c
> > @@ -68,6 +68,9 @@ static struct bochsvga_mode
> > { 0x14a, { MM_DIRECT, 1152, 864, 16, 8, 16, SEG_GRAPH } },
> > { 0x14b, { MM_DIRECT, 1152, 864, 24, 8, 16, SEG_GRAPH } },
> > { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
> > +{ 0x175, { MM_DIRECT, 1280, 768, 16, 8, 16, SEG_GRAPH } },
> > +{ 0x176, { MM_DIRECT, 1280, 768, 24, 8, 16, SEG_GRAPH } },
> > +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
> > { 0x178, { MM_DIRECT, 1280, 800, 16, 8, 16, SEG_GRAPH } },
> > { 0x179, { MM_DIRECT, 1280, 800, 24, 8, 16, SEG_GRAPH } },
> > { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
> > @@ -89,6 +92,14 @@ static struct bochsvga_mode
> > { 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } },
> > { 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } },
> > { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
> > +{ 0x18d, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
> > +{ 0x18d, { MM_DIRECT, 1280, 720, 24, 8, 16, SEG_GRAPH } },
> > +{ 0x18e, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
> > +{ 0x18f, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
>
> Something's not right here (two 0x18d, 0x18f has 16bit bpp).
>
> > +{ 0x190, { MM_DIRECT, 1920, 1080, 16 8, 16, SEG_GRAPH } },
> > +{ 0x191, { MM_DIRECT, 1920, 1080, 24 8, 16, SEG_GRAPH } },
> > +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> > +
>
> Extra blank line.
>
> -Kevin
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] build: explicitly set rom size
Maybe QEMU live migration could be improved to handle ROM changing size? On Tue, Sep 24, 2013 at 2:01 PM, Kevin O'Connor wrote: > On Tue, Sep 24, 2013 at 10:12:36AM +0200, Gerd Hoffmann wrote: > > Replace the automatic rom sizing with an explicit kconfig option. > > ROM changing size is a problem for qemu live migration, therefore > > an explicit size is prefered. > > > > Make the default rom size 256k, with the recent xhci support merge > > seabios doesn't fit into 128k any more. > > If you want to add a size override then that's fine, but I think the > default should remain auto-sizing. > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3 0/3] usb: add xhci support
Many motherboards come with 64 megabit (8 megabyte) firmware chips. So it should be able to handle more than just 128k, preferably more than 256k too. On Tue, Sep 24, 2013 at 10:31 AM, Michael S. Tsirkin wrote: > On Tue, Sep 24, 2013 at 10:19:39AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > > > > > > > With this applied, we crossed over the 128K boundary. > > > > > So it won't be easy to put this bios into qemu. > > > > > Thoughts? > > > > > > > > Guess we finally have to deal with the 128k -> 256k jump in qemu > then. > > > > CONFIG_USB_XHCI=n should to the trick until this is done. > > > > > > > > cheers, > > > > Gerd > > > > > > > > > > > > > > One simple way is to have two bios binaries > > > built with different flags, and use > > > the stripped ones for the old machine type. > > > > Yep, that'll work. Your acpi patch series with ACPI_BUILTIN=n might > > bring us under 128k too. But that will most likely not last forever, so > > I guess I'll go for one 128k and one 256k seabios binary with the next > > feature update (aka master branch release). > > > > cheers, > > Gerd > > > > Both built from same source with different flags, right? > Nod. We'll do this for QEMU 1.7. > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] acpi: hide 64-bit PCI hole for Windows XP
Maybe rename Windows 2001, 2006, and 2009 to their real names? Or use their NT kernel name instead, like NT 6.1, NT 6.2, etc. Or add a comment in the source code like: “Windows 2009” /* Windows 7 */ || "Windows 2012" /* Windows Server 2012 */ || On Mon, Aug 5, 2013 at 9:11 PM, Paolo Bonzini wrote: > > > > From my quick research, it looks like "Windows 2006" || "Windows > > > 2006.1" || "Linux" would work, but I have not tested it. > > > > > > Paolo > > > > This doesn't work in that it matches linux. > > Note that the above was meant to be a condition for when to _show_ > the PCI hole, i.e. negated compared to your example. > > > ATM it looks like we should test > > "Windows 2000" || > > "Windows 2001" || > > "Windows 2001 SP1" || > > "Windows 2001.1 SP1" > > Including this may be too strict, what about 98/ME? > > > && !( > > "Windows 2006" || > > "Windows 2006.1" || > > We know that these are all implied by the following four: > > > "Windows 2006 SP1" || > > "Windows 2006 SP2" || > > "Windows 2009" || > > "Windows 2012" || > > So it is not necessary to test these four. > > > "Linux" || > > "FreeBSD" > > ) && > > _OS == "Microsoft Windows NT" > > && > > _REV == 0x1 > > Testing _OS and _REV is probably too strict. > > > This should match XP and 2003 as tightly as possible. > > Please note "Linux" is there just in case, modern > > Linux OSPM does not identify itself as "Linux". > > Yeah, I know. I didn't know about FreeBSD, and I agree it is > better to include it just in case. > > Paolo > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Support custom boot menu prompt and custom boot menu key.
Can the message have some color codes?
"\nPress F12 for boot menu.\n\n"
So that it is possible to brighten/darken/highlight/emphasize certain parts
of text strings.
Also with the boot being so fast, it is easy to miss the window of press.
I hope it is possible to hold down the F12 key and that should work too, so
you don't have to repeatedly press it 10 times a second. :p
On Fri, Aug 2, 2013 at 8:18 PM, Kevin O'Connor wrote:
> Allow configuration of the boot menu prompt and boot menu key (via the
> romfile interface). Some machines don't have an F12 key, so make this
> configurable.
>
> Signed-off-by: Kevin O'Connor
> ---
> src/boot.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/boot.c b/src/boot.c
> index d421a65..7bcb4b6 100644
> --- a/src/boot.c
> +++ b/src/boot.c
> @@ -413,14 +413,16 @@ interactive_bootmenu(void)
> while (get_keystroke(0) >= 0)
> ;
>
> -printf("\nPress F12 for boot menu.\n\n");
> +char *bootmsg = romfile_loadfile("etc/boot-menu-message", NULL);
> +int menukey = romfile_loadint("etc/boot-menu-key", 0x86);
> +printf(bootmsg ?: "\nPress F12 for boot menu.\n\n");
> +free(bootmsg);
>
> u32 menutime = romfile_loadint("etc/boot-menu-wait",
> DEFAULT_BOOTMENU_WAIT);
> enable_bootsplash();
> int scan_code = get_keystroke(menutime);
> disable_bootsplash();
> -if (scan_code != 0x86)
> -/* not F12 */
> +if (scan_code != menukey)
> return;
>
> while (get_keystroke(0) >= 0)
> --
> 1.7.11.7
>
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Open Firmware path on boot selection screen.
Wow, that is a really cool feature! :) On Thu, Aug 1, 2013 at 4:37 PM, Gerd Hoffmann wrote: > On 07/31/13 14:18, Weinz Christian wrote: > > Hello, > > > > I suggest adding the Open Firmware paths for devices SeaBIOS can boot > from > > (example: /pci@i0cf8/usb@12,2/usb-*@4) to the boot selection screen. I > > needed > > to buy a serial adapter and a null modem just to get that string. That > > string > > is important since you cannot modify the default boot sequence without > it. > > Latest seabios (aka git master, 1.7.3 isn't new enough) can append the > seabios log to the coreboot logbuffer. So you can use "cbmem -c" to > read the logs once the system is up'n'running and find the strings there. > > cheers, > Gerd > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] [wip] add xhci support
Release early, release often. Push to git head! On Tue, Jun 11, 2013 at 7:54 AM, Gerd Hoffmann wrote: > On 06/09/13 04:31, Kevin O'Connor wrote: > > On Fri, Jun 07, 2013 at 02:16:10PM +0200, Gerd Hoffmann wrote: > >> Very first revision doing something useful. Initializes xhci host > >> controller, detects devices, can handle control and bulk transfers. > >> Good enougth to boot from usb storage devices. > >> > >> To be done: > >> * Add support for interrupt transfers (needed for kbd+mouse). > >> * Add support for streams (needed for uas devices on usb3 ports). > >> * Add support for usb hubs. > >> > >> Tested on qemu only. > > > > Very nice! > > > > Did you wish to target the next release for this feature? > > Depends on how long it takes to finish it off, it's not ready for merge > yet. Posted this for (a) early code reviews and (b) to make people > aware I'm working on this. > > > If so, I > > think it would need to default to disabled. > > Sure. > > cheers, > Gerd > > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Running privilege code on hidden O.S.
Sounds like a rootkit. On Thu, Jun 6, 2013 at 9:35 PM, Jerry Backer wrote: > Hi, > > The idea is to run some security and packet inspection codes on the hidden > core. > There is a typo on the title, it should be 'Running privilege code on > hidden core'. > > Thanks, > > > On Thu, Jun 6, 2013 at 3:04 PM, Fred . wrote: > >> I am curious as to why you would want to do such a thing... >> >> >> On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer wrote: >> >>> Hello, >>> >>> I am using seaBIOS with QEMU and am attempting to hide a processor core >>> (on an smp system) from the O.S. and then load a dedicated code on that >>> core before boot. I have managed to hide one of the cores by decreasing >>> CountCPUs (within smp.c) after running the ap core code, hence the BIOS >>> load info for 1 less core on the mp table. >>> >>> However, I have not been able to figure out how to load the privileged >>> code. My intuition was to load it when the hidden core enters protected >>> mode before running kernel code. But I don't see where in the code the >>> cores go into protected mode during boot. >>> >>> Can anyone give me some insight on how to proceed? >>> >>> Thanks, >>> >>> -- >>> Jerry >>> >>> ___ >>> SeaBIOS mailing list >>> SeaBIOS@seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >>> >>> >> > > > -- > Jerry Backer > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Running privilege code on hidden O.S.
I am curious as to why you would want to do such a thing... On Thu, Jun 6, 2013 at 6:52 PM, Jerry Backer wrote: > Hello, > > I am using seaBIOS with QEMU and am attempting to hide a processor core > (on an smp system) from the O.S. and then load a dedicated code on that > core before boot. I have managed to hide one of the cores by decreasing > CountCPUs (within smp.c) after running the ap core code, hence the BIOS > load info for 1 less core on the mp table. > > However, I have not been able to figure out how to load the privileged > code. My intuition was to load it when the hidden core enters protected > mode before running kernel code. But I don't see where in the code the > cores go into protected mode during boot. > > Can anyone give me some insight on how to proceed? > > Thanks, > > -- > Jerry > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] What's the impact of enlarging IDE_TIMEOUT ?
Sounds like something that should be commented in the source code. IDE_TIMEOUT = 32; // 30 seconds per ATA specification +2 seconds thrown in for safety On Sat, Jun 1, 2013 at 3:21 PM, Kevin O'Connor wrote: > On Fri, May 31, 2013 at 03:18:56AM +, Gonglei (Arei) wrote: > >IDE_TIMEOUT is defined 32s. But we encountered its timeout in > >some cases, and then loading disk failed in VM. In order to > >reduce the probability of timeout, we want to enlarge the > >IDE_TIMEOUT, such as 120s. We verified this modification worked > >for us. But we are wondering if this modification may cause other > >potential issues. Why set IDE_TIMEOUT to 32s? Thanks! > > The ATA specification specifies the maximum response time for many > commands to be 30 seconds. The extra 2 seconds were thrown in for > safety. > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH RFC 0/3] seabios: move acpi table formatting out of bios
With ACPI moved out of SeaBIOS to QEMU, how will ACPI work when using SeaBIOS without QEMU? Like if using SeaBIOS with Boch, KVM or Coreboot? On Thu, Apr 25, 2013 at 11:02 AM, Michael S. Tsirkin wrote: > Untested yet, but I thought I'd share the > BIOS bits so we can agree on direction. > > In particular check out ROM sizes: > - Before patchset with DSDT enabled > Total size: 127880 Fixed: 59060 Free: 3192 (used 97.6% of 128KiB rom) > - Before patchset with DSDT disabled > Total size: 122844 Fixed: 58884 Free: 8228 (used 93.7% of 128KiB rom) > - After patchset: > Total size: 128776 Fixed: 59100 Free: 2296 (used 98.2% of 128KiB rom) > - Legacy disabled at build time: > Total size: 119836 Fixed: 58996 Free: 11236 (used 91.4% of 128KiB > rom) > > As can be seen from this, most size savings come > from dropping DSDT, but we do save a bit by removing > other tables. Of course the real reason to move tables to QEMU > is so that ACPI can better match hardware. > > This patchset adds an option to move all code for formatting acpi tables > out of BIOS. With this, QEMU has full control over the table layout. > All tables are loaded from the new "/etc/acpi/" directory. > Any entries in this directory cause BIOS to disable > ACPI table generation completely. > A generic linker script, controlled by QEMU, is > loaded from "/etc/linker-script". It is used to > patch in table pointers and checksums. > > BIOS still has limited ability to parse the tables, > for the following purposes: > - locate resume vector > - allocate RSDP in FSEG > - allocate FACS at an aligned address > > -- > MST > > > Michael S. Tsirkin (3): > linker: utility to patch in-memory ROM files > acpi: load and link tables from /etc/acpi/ > acpi: add an option to disable builtin tables > > Makefile | 2 +- > src/Kconfig | 12 +++- > src/acpi.c | 67 +++- > src/linker.c | 90 > > src/linker.h | 50 + > src/util.h | 1 + > 6 files changed, 219 insertions(+), 3 deletions(-) > create mode 100644 src/linker.c > create mode 100644 src/linker.h > > -- > MST > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC][PATCH 0/2] Embedded Controller chip emulation
HECI ? http://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface On Wed, Apr 17, 2013 at 9:32 AM, li guang wrote: > Embedded Controller chip could commonly be found > at platforms for laptop, it generally does > power management, keyboard and mouse simulation, > ACPI defined operation, low-speed devices handling ... > It talks with OS via io-port 0x60/0x54, 0x62/0x66, > the first pair is for i8042 compatible, the last > pair is for ACPI functions. > As QEMU has done power management, i8042 emulation, > this RFC patch will only focus on ACPI functions. > you can find standard description a ACPI SPEC > "ACPI Embedded Controller Interface Specification" > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Add note that boot interface is needed
If SeaBIOS is useless without this, then maybe the option to disable it should be removed? On Tue, Mar 19, 2013 at 11:00 AM, Paul Menzel < paulepan...@users.sourceforge.net> wrote: > Date: Tue, 19 Mar 2013 10:36:15 +0100 > > Without the boot interface , GRUB 2 (package grub-pc 1.99-7 from Debian > Sid/unstable) is not loaded when running coreboot with SeaBIOS 1.7.2.1 > as payload on the ASRock E350M1. Only the SeaBIOS banner is shown and > nothing else happens afterward. > > Signed-off-by: Paul Menzel > --- > More or less a request for comments, as I still do not understand how > SeaBIOS uses the interfaces itself and how SeaBIOS is of any use at all > without being able to boot something. At least I do not know of such a > use case. > > src/Kconfig |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/Kconfig b/src/Kconfig > index 3141069..c7ea23c 100644 > --- a/src/Kconfig > +++ b/src/Kconfig > @@ -327,6 +327,8 @@ menu "BIOS interfaces" > default y > help > Support int 19/18 system bootup support. > + > +You have to select this, if you want to boot from some media. > config KEYBOARD > bool "Keyboard interface" > default y > -- > 1.7.10.4 > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Spell »Option ROMs« uniformly as in Wikipedia [1]
Wikipedia titles start with a capital letter, hence it is "Option ROM" but in the article, most references are "option ROM" and probably all references should be "option ROM". option being lowercase because it is an English word, and ROM being uppercase because it is an acronym. On Mon, Mar 18, 2013 at 2:44 PM, Paul Menzel < paulepan...@users.sourceforge.net> wrote: > Date: Mon, 18 Mar 2013 14:42:12 +0100 > > [1] http://en.wikipedia.org/wiki/Option_ROM > > Signed-off-by: Paul Menzel > --- > src/Kconfig | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/src/Kconfig b/src/Kconfig > index 3141069..5816cb4 100644 > --- a/src/Kconfig > +++ b/src/Kconfig > @@ -48,14 +48,14 @@ endchoice > Support running hardware initialization in parallel. > config THREAD_OPTIONROMS > depends on THREADS && !CSM > -bool "Hardware init during option ROM execution" > +bool "Hardware init during Option ROM execution" > default n > help > -Allow hardware init to run in parallel with optionrom > execution. > +Allow hardware init to run in parallel with Option ROM > execution. > > This can reduce boot time, but can cause some timing > -variations during option ROM code execution. It is not > -known if all option ROMs will behave properly with this > +variations during Option ROM code execution. It is not > +known if all Option ROMs will behave properly with this > option. > > config RELOCATE_INIT > @@ -304,16 +304,16 @@ menu "BIOS interfaces" > help > Support PnP BIOS entry point. > config OPTIONROMS > -bool "Option ROMS" > +bool "Option ROMs" > default y > help > -Support finding and running option roms during POST. > +Support finding and running Option ROMs during POST. > config OPTIONROMS_DEPLOYED > depends on OPTIONROMS && QEMU > -bool "Option roms are already at 0xc-0xf" > +bool "Option ROMs are already at 0xc-0xf" > default n > help > -Select this if option ROMs are already copied to > +Select this if Option ROMs are already copied to > 0xc-0xf. This must only be selected when using > Bochs or QEMU versions older than 0.12. > config PMM > -- > 1.7.10.4 > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support
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] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
On Wed, Feb 13, 2013 at 5:15 PM, David Woodhouse wrote: > What user experience do you actually expect to achieve, from the changes > that you're suggesting? > > Bootloaders like Grub these days will already use graphical modes. The > SeaBIOS splash screen can also be graphical, and you can go seamlessly > from one to the other. What is it that you actually *want*, in real > terms? I'm not even sure you know... > Yeah, I was thinking along the lines of using a splash screen then GRUB use the same resolution and the same splash screen and it would transition smoothly without any flicker or resetting of the screen mode, and then it would go from there to Plymouth which would use the same splash screen, and it would transition smoothly to the login manager. >From boot to desktop, always in 1900x1200. Smooth experience. No flicker. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
I was wondering if it could power-up in high resolution mode. Didn't know nothing would work as expected. I thought maybe bootloaders could use the same mode without reset the display and set a new mode, and then the operating system does the same. So the computer boots up and passes it to the bootloader which passes it to the operating system all without ever changing screen mode or flicking anything. Doesn't Apple's computers do that? I don't know. Would it be possible to boot in a resolution any more modern than the old IBM PC BIOS of 1980? Which probably used same resolution as something from 1960 or 1970. Maybe 132*60 instead of 40*25 or 80*25 rows/columns of text? On Wed, Feb 13, 2013 at 11:10 AM, David Woodhouse wrote: > On Wed, 2013-02-13 at 10:44 +0100, Fred . wrote: > > Can SeaBIOS init to a high resolution video mode such as 1920x1200? > > I'm not entirely sure what you're asking. Can SeaVGABIOS initialise a > high-resolution mode? Yes. It supports 1920x1200 and 2560x1600 modes. > All you have to do is call INT 10h with the appropriate mode-setting > request. > > Or are you asking if it can do so *power-up*, setting a graphical mode > so that nothing displays as expected, because operating systems and > bootloaders expect the screen to be in *text* mode? To which the answer > would be that yes it *can* be patched to do so, but that would be bad. > > Or are you asking if it can do so for the OVMF/CSM case? In which case > again it *could* but OVMF is about to set the mode for itself anyway so > it would be pointless. > > -- > dwmw2 > > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
Can SeaBIOS init to a high resolution video mode such as 1920x1200? On Wed, Feb 13, 2013 at 3:24 AM, Kevin O'Connor wrote: > On Fri, Feb 08, 2013 at 03:19:19PM +, David Woodhouse wrote: > > On Fri, 2013-02-08 at 15:06 +, David Woodhouse wrote: > > > When booting with OVMF+CSM, the first video mode that we ask for is > mode > > > 0x143. This doesn't seem to work; the qemu display window doesn't > change > > > size, and remains blank. > > > > > > If the first thing we ask for is a *text* mode, then things work fine. > > > This is arguably a bug, but I'm not about to go chasing it. > > > > I should know never to say things like that; if I'm offended by > > something it's almost always a lie to say that I won't actually go and > > hunt it down. This patch is more minimal and highlights the actual > > problem. Not sure what *else* is missing... > > Thanks. The patch looks fine to me. However, "-vga std" has stopped > working for me (both before and after your patch) and I still need to > track that down. > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 3/6] Add runningOnQEMU() and runningOnXEN() ror runtime platform detection.
Maybe time to get a naming standard before it gets too messy? Perhaps adapt the current naming standard used by the Linux kernel or something? Either way, there is no reason for Xen to be named XEN. On Mon, Feb 11, 2013 at 4:27 AM, Kevin O'Connor wrote: > On Sat, Feb 09, 2013 at 08:42:31PM +0100, Fred . wrote: > > runningOnXEN() > > > > It is Xen not XEN. It is not capitalized. > > I've updated the Kconfig comments in my tree. > > > Also, hypercall_xen_version() has underscore, but runningOnXEN() has > > camelcase. > > Maybe runningOnXEN() should be named running_on_Xen() ? > > For better or worse, SeaBIOS has no standard wrt camelcase names. > > -Kevin > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 3/6] Add runningOnQEMU() and runningOnXEN() ror runtime platform detection.
runningOnXEN()
It is Xen not XEN. It is not capitalized.
Also, hypercall_xen_version() has underscore, but runningOnXEN() has
camelcase.
Maybe runningOnXEN() should be named running_on_Xen() ?
On Sat, Feb 9, 2013 at 8:08 PM, Kevin O'Connor wrote:
> Introduce standard for performing and inspecting the run-time
> detection of para-virtualized environments.
>
> Signed-off-by: Kevin O'Connor
> ---
> src/Kconfig| 14 +++---
> src/misc.c | 2 ++
> src/paravirt.c | 5 +
> src/paravirt.h | 20 ++--
> src/xen.c | 7 +--
> 5 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/src/Kconfig b/src/Kconfig
> index bbcefe0..6fd45b4 100644
> --- a/src/Kconfig
> +++ b/src/Kconfig
> @@ -14,9 +14,10 @@ choice
> Configure as a coreboot payload.
>
> config QEMU
> -bool "Build for QEMU"
> +bool "Build for QEMU/XEN/KVM/Bochs"
> +select QEMU_HARDWARE
> help
> -Configure as QEMU bios.
> +Configure for an emulated machine (QEMU, XEN, KVM, or Bochs).
>
> config CSM
> bool "Build as Compatibilty Support Module for EFI BIOS"
> @@ -26,9 +27,16 @@ choice
>
> endchoice
>
> +config QEMU_HARDWARE
> +bool "Support hardware found on emulators (QEMU/XEN/KVM/Bochs)"
> if !QEMU
> +default n
> +help
> +Support virtual hardware when the code detects it is
> +running on an emulator.
> +
> config XEN
> depends on QEMU
> -bool "Build for Xen HVM"
> +bool "Support Xen HVM"
> default y
> help
> Configure to be used by xen hvmloader, for a HVM guest.
> diff --git a/src/misc.c b/src/misc.c
> index bcc450a..3b2ffc1 100644
> --- a/src/misc.c
> +++ b/src/misc.c
> @@ -16,6 +16,8 @@ u32 RamSize VAR16VISIBLE;
> u64 RamSizeOver4G;
> // Space for bios tables built an run-time.
> char BiosTableSpace[CONFIG_MAX_BIOSTABLE] __aligned(MALLOC_MIN_ALIGN)
> VAR16VISIBLE;
> +// Type of emulator platform.
> +int PlatformRunningOn VAR16VISIBLE;
>
>
> /
> diff --git a/src/paravirt.c b/src/paravirt.c
> index 9022186..6e230ee 100644
> --- a/src/paravirt.c
> +++ b/src/paravirt.c
> @@ -24,6 +24,11 @@ int qemu_cfg_present;
> void
> qemu_ramsize_preinit(void)
> {
> +if (!CONFIG_QEMU)
> +return;
> +
> +PlatformRunningOn = PF_QEMU;
> +
> // On emulators, get memory size from nvram.
> u32 rs = ((inb_cmos(CMOS_MEM_EXTMEM2_LOW) << 16)
>| (inb_cmos(CMOS_MEM_EXTMEM2_HIGH) << 24));
> diff --git a/src/paravirt.h b/src/paravirt.h
> index 4f2d5b8..d32ca13 100644
> --- a/src/paravirt.h
> +++ b/src/paravirt.h
> @@ -1,8 +1,24 @@
> #ifndef __PV_H
> #define __PV_H
>
> -#include "config.h" // CONFIG_COREBOOT
> -#include "util.h"
> +#include "config.h" // CONFIG_*
> +#include "util.h" // memcpy
> +#include "biosvar.h" // GET_GLOBAL
> +
> +// Types of paravirtualized platforms.
> +#define PF_QEMU (1<<0)
> +#define PF_XEN (1<<1)
> +
> +// misc.c
> +extern int PlatformRunningOn;
> +
> +static inline int runningOnQEMU(void) {
> +return CONFIG_QEMU || (
> +CONFIG_QEMU_HARDWARE && GET_GLOBAL(PlatformRunningOn) & PF_QEMU);
> +}
> +static inline int runningOnXen(void) {
> +return CONFIG_XEN && GET_GLOBAL(PlatformRunningOn) & PF_XEN;
> +}
>
> /* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
> * should be used to determine that a VM is running under KVM.
> diff --git a/src/xen.c b/src/xen.c
> index c9759f0..e075af2 100644
> --- a/src/xen.c
> +++ b/src/xen.c
> @@ -6,7 +6,7 @@
>
> #include "config.h"
> #include "xen.h"
> -
> +#include "paravirt.h" // PlatformRunningOn
> #include "memmap.h" // add_e820
> #include "types.h" // ASM32FLAT
> #include "util.h" // copy_acpi_rsdp
> @@ -76,8 +76,11 @@ void xen_preinit(void)
> break;
> }
> }
> -if (!xen_cpuid_base)
> +if (!xen_cpuid_base) {
> dprintf(1, "No Xen hypervisor found.\n");
> +return;
> +}
> +PlatformRunningOn = PF_QEMU|PF_XEN;
> }
>
> static int hypercall_xen_version( int cmd, void *arg)
> --
> 1.7.11.7
>
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 2/5] Introduce framework for detecting what platform SeaBIOS is running on.
Maybe would be nice with a:
int get_platform();
0 = QEMU
1 = Xen
2 = Coreboot
3 = CSM
Then you have one get_platform() function, instead of four separate
startedOnQEMU(), startedOnCoreboot, startedOnCSM, etc functions.
On Fri, Feb 8, 2013 at 6:07 AM, Kevin O'Connor wrote:
> Introduce startedOnQEMU()/startedOnCoreboot()/etc. calls to enable
> code to determine what platform invoked the initial SeaBIOS startup.
> Also introduce runningOnQEMU()/etc. calls for cases where SeaBIOS can
> detect it is running on a platform even though it wasn't directly
> launched by that platform (eg, Xen may have started SeaBIOS, but Xen
> may be running under qemu).
>
> Signed-off-by: Kevin O'Connor
> ---
> src/coreboot.c | 3 ++
> src/csm.c | 2 ++
> src/paravirt.c | 10 +--
> src/paravirt.h | 93
> --
> src/xen.c | 1 +
> 5 files changed, 104 insertions(+), 5 deletions(-)
>
> diff --git a/src/coreboot.c b/src/coreboot.c
> index 57c9737..40a7e72 100644
> --- a/src/coreboot.c
> +++ b/src/coreboot.c
> @@ -12,6 +12,7 @@
> #include "boot.h" // boot_add_cbfs
> #include "disk.h" // MAXDESCSIZE
> #include "config.h" // CONFIG_*
> +#include "paravirt.h" // PlatformStartedOn
>
>
> /
> @@ -145,6 +146,8 @@ coreboot_preinit(void)
> if (!cbm)
> goto fail;
>
> +PlatformStartedOn = PlatformRunningOn = PF_COREBOOT;
> +
> u64 maxram = 0, maxram_over4G = 0;
> int i, count = MEM_RANGE_COUNT(cbm);
> for (i=0; i diff --git a/src/csm.c b/src/csm.c
> index 169b608..c8069d2 100644
> --- a/src/csm.c
> +++ b/src/csm.c
> @@ -17,6 +17,7 @@
> #include "boot.h"
> #include "smbios.h"
> #include "pic.h"
> +#include "paravirt.h" // PlatformStartedOn
>
> struct rsdp_descriptor VAR32FLATVISIBLE __aligned(16) csm_rsdp;
>
> @@ -74,6 +75,7 @@ handle_csm_(struct bregs *regs)
> dprintf(3, "LoPmmMemory %08x\n", csm_init_table->LowPmmMemory);
> dprintf(3, "LoPmmMemorySize %08x\n",
> csm_init_table->LowPmmMemorySizeInBytes);
>
> +PlatformStartedOn = PlatformRunningOn = PF_CSM;
> csm_malloc_preinit(csm_init_table->LowPmmMemory,
> csm_init_table->LowPmmMemorySizeInBytes,
> csm_init_table->HiPmmMemory,
> diff --git a/src/paravirt.c b/src/paravirt.c
> index ebab256..35b7c11 100644
> --- a/src/paravirt.c
> +++ b/src/paravirt.c
> @@ -19,6 +19,8 @@
> #include "mptable.h" // mptable_setup
> #include "pci.h" // create_pirtable
>
> +int PlatformStartedOn, PlatformRunningOn;
> +
> int qemu_cfg_present;
>
> void
> @@ -27,6 +29,7 @@ qemu_preinit(void)
> if (!CONFIG_QEMU)
> return;
>
> +PlatformStartedOn = PlatformRunningOn = PF_QEMU;
> qemu_cfg_preinit();
>
> // On emulators, get memory size from nvram.
> @@ -108,12 +111,13 @@ qemu_cfg_read_entry(void *buf, int e, int len)
>
> void qemu_cfg_preinit(void)
> {
> +if (!CONFIG_QEMU)
> +return;
> +PlatformRunningOn |= PF_QEMU;
> +
> char *sig = "QEMU";
> int i;
>
> -if (CONFIG_COREBOOT)
> -return;
> -
> qemu_cfg_present = 1;
>
> qemu_cfg_select(QEMU_CFG_SIGNATURE);
> diff --git a/src/paravirt.h b/src/paravirt.h
> index 2448993..3b00697 100644
> --- a/src/paravirt.h
> +++ b/src/paravirt.h
> @@ -1,8 +1,97 @@
> #ifndef __PV_H
> #define __PV_H
>
> -#include "config.h" // CONFIG_COREBOOT
> -#include "util.h"
> +#include "config.h" // CONFIG_*
> +#include "util.h" // memcpy
> +
> +
> +/
> + * Current platform detection
> + /
> +
> +#define PF_QEMU (1<<0)
> +#define PF_COREBOOT (1<<1)
> +#define PF_XEN (1<<2)
> +#define PF_CSM (1<<3)
> +
> +extern int PlatformStartedOn, PlatformRunningOn;
> +
> +static inline int startedOnQEMU(void)
> +{
> +if (!CONFIG_QEMU)
> +return 0;
> +if (!CONFIG_COREBOOT && !CONFIG_XEN && !CONFIG_CSM)
> +return 1;
> +return PlatformStartedOn == PF_QEMU;
> +}
> +
> +static inline int startedOnCoreboot(void)
> +{
> +if (!CONFIG_COREBOOT)
> +return 0;
> +if (!CONFIG_QEMU && !CONFIG_XEN && !CONFIG_CSM)
> +return 1;
> +return PlatformStartedOn == PF_COREBOOT;
> +}
> +
> +static inline int startedOnXen(void)
> +{
> +if (!CONFIG_XEN)
> +return 0;
> +if (!CONFIG_QEMU && !CONFIG_COREBOOT && !CONFIG_CSM)
> +return 1;
> +return PlatformStartedOn == PF_XEN;
> +}
> +
> +static inline int startedOnCSM(void)
> +{
> +if (!CONFIG_CSM)
> +return 0;
> +if (!CONFIG_QEMU && !CONFIG_COREBOOT && !CONFIG_XEN)
> +return 1;
> +return PlatformStartedOn == PF_CSM;
> +}
> +
> +static inline int runningOnQEMU(void)
> +{
> +if (!CONFIG_QEMU)
> +return 0;
> +if (!CONFIG_COREBOOT && !CONFIG_XEN && !CONFIG_CSM)
> +return 1;
> +return Plat
Re: [SeaBIOS] [PATCH 2/5] Introduce framework for detecting what platform SeaBIOS is running on.
I see functions named coreboot_preinit() with underscore.
Then I see functions named runningOnCoreboot() with camelcase.
This is inconsistent naming.
Shouldn't you be sticking to some coding convention or naming guideline?
On Fri, Feb 8, 2013 at 1:56 PM, Fred . wrote:
> Maybe would be nice with a:
> int get_platform();
> 0 = QEMU
> 1 = Xen
> 2 = Coreboot
> 3 = CSM
>
> Then you have one get_platform() function, instead of four separate
> startedOnQEMU(), startedOnCoreboot, startedOnCSM, etc functions.
>
>
> On Fri, Feb 8, 2013 at 6:07 AM, Kevin O'Connor wrote:
>
>> Introduce startedOnQEMU()/startedOnCoreboot()/etc. calls to enable
>> code to determine what platform invoked the initial SeaBIOS startup.
>> Also introduce runningOnQEMU()/etc. calls for cases where SeaBIOS can
>> detect it is running on a platform even though it wasn't directly
>> launched by that platform (eg, Xen may have started SeaBIOS, but Xen
>> may be running under qemu).
>>
>> Signed-off-by: Kevin O'Connor
>> ---
>> src/coreboot.c | 3 ++
>> src/csm.c | 2 ++
>> src/paravirt.c | 10 +--
>> src/paravirt.h | 93
>> --
>> src/xen.c | 1 +
>> 5 files changed, 104 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/coreboot.c b/src/coreboot.c
>> index 57c9737..40a7e72 100644
>> --- a/src/coreboot.c
>> +++ b/src/coreboot.c
>> @@ -12,6 +12,7 @@
>> #include "boot.h" // boot_add_cbfs
>> #include "disk.h" // MAXDESCSIZE
>> #include "config.h" // CONFIG_*
>> +#include "paravirt.h" // PlatformStartedOn
>>
>>
>> /
>> @@ -145,6 +146,8 @@ coreboot_preinit(void)
>> if (!cbm)
>> goto fail;
>>
>> +PlatformStartedOn = PlatformRunningOn = PF_COREBOOT;
>> +
>> u64 maxram = 0, maxram_over4G = 0;
>> int i, count = MEM_RANGE_COUNT(cbm);
>> for (i=0; i> diff --git a/src/csm.c b/src/csm.c
>> index 169b608..c8069d2 100644
>> --- a/src/csm.c
>> +++ b/src/csm.c
>> @@ -17,6 +17,7 @@
>> #include "boot.h"
>> #include "smbios.h"
>> #include "pic.h"
>> +#include "paravirt.h" // PlatformStartedOn
>>
>> struct rsdp_descriptor VAR32FLATVISIBLE __aligned(16) csm_rsdp;
>>
>> @@ -74,6 +75,7 @@ handle_csm_(struct bregs *regs)
>> dprintf(3, "LoPmmMemory %08x\n", csm_init_table->LowPmmMemory);
>> dprintf(3, "LoPmmMemorySize %08x\n",
>> csm_init_table->LowPmmMemorySizeInBytes);
>>
>> +PlatformStartedOn = PlatformRunningOn = PF_CSM;
>> csm_malloc_preinit(csm_init_table->LowPmmMemory,
>> csm_init_table->LowPmmMemorySizeInBytes,
>> csm_init_table->HiPmmMemory,
>> diff --git a/src/paravirt.c b/src/paravirt.c
>> index ebab256..35b7c11 100644
>> --- a/src/paravirt.c
>> +++ b/src/paravirt.c
>> @@ -19,6 +19,8 @@
>> #include "mptable.h" // mptable_setup
>> #include "pci.h" // create_pirtable
>>
>> +int PlatformStartedOn, PlatformRunningOn;
>> +
>> int qemu_cfg_present;
>>
>> void
>> @@ -27,6 +29,7 @@ qemu_preinit(void)
>> if (!CONFIG_QEMU)
>> return;
>>
>> +PlatformStartedOn = PlatformRunningOn = PF_QEMU;
>> qemu_cfg_preinit();
>>
>> // On emulators, get memory size from nvram.
>> @@ -108,12 +111,13 @@ qemu_cfg_read_entry(void *buf, int e, int len)
>>
>> void qemu_cfg_preinit(void)
>> {
>> +if (!CONFIG_QEMU)
>> +return;
>> +PlatformRunningOn |= PF_QEMU;
>> +
>> char *sig = "QEMU";
>> int i;
>>
>> -if (CONFIG_COREBOOT)
>> -return;
>> -
>> qemu_cfg_present = 1;
>>
>> qemu_cfg_select(QEMU_CFG_SIGNATURE);
>> diff --git a/src/paravirt.h b/src/paravirt.h
>> index 2448993..3b00697 100644
>> --- a/src/paravirt.h
>> +++ b/src/paravirt.h
>> @@ -1,8 +1,97 @@
>> #ifndef __PV_H
>> #define __PV_H
>>
>> -#include "config.h" // CONFIG_COREBOOT
>> -#include "util.h"
>> +#include "config.h" // CONFIG_*
>> +#include "util.h" // memcpy
>> +
>> +
>> +/
>> + * Current platform detection
>> +
Re: [SeaBIOS] [RFC PATCH] VGA BIOS init fails if first mode used is graphical
It would be nice with native resolution video mode. Such as 1920x1200. On Fri, Feb 8, 2013 at 4:06 PM, David Woodhouse wrote: > When booting with OVMF+CSM, the first video mode that we ask for is mode > 0x143. This doesn't seem to work; the qemu display window doesn't change > size, and remains blank. > > If the first thing we ask for is a *text* mode, then things work fine. > This is arguably a bug, but I'm not about to go chasing it. Most video > BIOSes will enter mode 3 for themselves as part of the POST anyway, > won't they? And that's sufficient to work around the problem for me... > > Signed-off-by: David Woodhouse > > diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c > index 3e26e32..82aa5fc 100644 > --- a/vgasrc/vgabios.c > +++ b/vgasrc/vgabios.c > @@ -1320,4 +1320,6 @@ vga_post(struct bregs *regs) > u8 sum = -checksum_far(get_global_seg(), 0, > GET_GLOBAL(_rom_header_size) * 512); > SET_VGA(_rom_header_checksum, sum); > + > +vga_set_mode(3, 0); > } > > > -- > dwmw2 > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Next release
I've seen other BIOS (Award, AMI) have a setting in the menu to enable "Boot sector protection". What would be possible in SeaBIOS to prevent overwrite boot sector, mbr, partition tables? On Wed, Jan 9, 2013 at 4:49 AM, Kevin O'Connor wrote: > On Tue, Jan 08, 2013 at 01:06:31AM +0100, Fred . wrote: > > Boot sector write protection. > > Prevent modify boot sector, master boot record, partition tables. > > > > Less and less computers come with optical disk drivers to run read-only > > Live distributions from. Would be nice with option to set hard disk drive > > read-only. > > So you can use a HDD or USB as a LiveCD/LiveDVD distribution. > > If someone has a patch for this, I'll consider it. I don't think it > is worthwhile to hold up a release if this feature is not ready. > > Separately, there's no way for SeaBIOS to prevent access to the MBR, > so I'm not sure how that would work. > > -Kevin > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Next release
Boot sector write protection. Prevent modify boot sector, master boot record, partition tables. Less and less computers come with optical disk drivers to run read-only Live distributions from. Would be nice with option to set hard disk drive read-only. So you can use a HDD or USB as a LiveCD/LiveDVD distribution. On Tue, Jan 8, 2013 at 12:35 AM, Kevin O'Connor wrote: > It's been a few months since the last SeaBIOS release. I'd like to > start preparing for the next release. If you know of any defects or > critical features that should go into the next release, please let me > know. > > I'd like to target January 18th for the next release. > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Access disk in read-only mode
Before you could boot a OS from a LiveCD and have it secure because CD is read-only and non-writable. Now less and less machines comes with optical drives. It would be nice with a setting to boot disks or USB as read-only so the OS can not write to the disk. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Boot sector protection
Add option to enable boot sector protection to prevent writes to the boot sector and MBR of a hard disk. In order to prevent boot sector viruses and corruption of partition tables. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SEABIOS and DOS compatibility
No, I did not. I just mentioned them as they are DOS 6.22 bootdisks, which was mentioned. So I assumed they would be useful for reproducing the problem. On Mon, Nov 12, 2012 at 11:39 PM, Peter Stuge wrote: > Fred . wrote: > > Anyone wishing to test this, can get a bootdisk from bootdisk.com. > > > > http://bootdisk.com/bootdisk.htm > > Did you verify that those bootdisks do in fact reproduce the problem? > > Doing that would be a good way to help the project. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SEABIOS and DOS compatibility
Anyone wishing to test this, can get a bootdisk from bootdisk.com. http://bootdisk.com/bootdisk.htm On Sun, Nov 11, 2012 at 8:32 PM, Kevin O'Connor wrote: > On Sun, Nov 11, 2012 at 06:44:53PM +0100, Gerhard Wiesinger wrote: > > Hello, > > > > I bisected down 2 DOS 6.22 compatibility issues: > > > > 1.) COMMAND.COM can not be loaded high, > > 9c98517c938d20c38f537d516c71b30bb60c3ea0 is the first bad commit > > Looks like and UMB generated which is not recognizeable ... > > Before: 9E80-9F7F: 4k EBDA, 9F80-9FFF: 2k UNUSED, really unused or > > used for option ROMs? > > After: 9F00-9FFF: 4k EBDA, now the 2k area is somewhere above and > > will be used by memory managers??? > > Thanks. Can you post your qemu command line and the SeaBIOS output > (-chardev stdio,id=seabios -device > isa-debugcon,iobase=0x402,chardev=seabios) from both a working run and > the non-working run? Also, can you provide the exact text reported by > msdos on success and failure. > > > 2.) 59d6ca52a7eba5b1f4f2becf70fd446dccaf0a2e is the first bad commit > > Opening a file and closing a file raises a 386 exception > > That's odd - nothing in this commit impacts the disk code. Maybe a > slightly different memory layout is triggering some other bug. > > I have an MSDOS 6.22 floppy image - but I don't see either of these > issues. Can you provide the steps needed to reproduce them? > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios > ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/9] q35 seabios support
No. On Tue, Oct 9, 2012 at 12:38 PM, Paolo Bonzini wrote: > Il 09/10/2012 12:04, Fred . ha scritto: >> Maybe it could be modified to add support for G31 and G33 too? >> Or maybe for P35? > > Do you have patches for QEMU that implement the host-side support? > > Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/9] q35 seabios support
Maybe it could be modified to add support for G31 and G33 too? Or maybe for P35? On Tue, Oct 9, 2012 at 5:35 AM, Jason Baron wrote: > Hi, > > Seabios bits for q35 support, I'm posting the qemu changes separately. The > patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the > qemu command line. Hopefully, we can make it the default for x86 at some > future > point when we feel comfortable with it. > > Since q35 patches have been posted before I've tried to keep the authorship as > clear as possible. > > The current patches have been tested with basic install testing and memory > testing > on f16, f17, windows 7 and windows 8. They can be run on the various BSD > flavors > by adding a 'piix4-ide' device to the pci bus. ie: -device piix4-ide. > > I'm hoping that we'll come to some agreement on the minimal functionality > required for q35 to be merged. > > Git trees: > > git://github.com/jibaron/q35-qemu.git > git://github.com/jibaron/q35-seabios.git > > Thanks, > > -Jason > > Changes from v1: > -Updated end of low mem from 0xe000 -> 0xb000 (Gerd Hoffmann) > -so 0xb00-0xc00 is memconfig > -0xc00-0xfec0 is 32-bit pci window > -style/various cleanups > -split dsdt out of bios, now passed for piix4 as well (Paolo, Gerd) > -make mtrr setup dynamic > -allow pci windows to be created based on pcimem_* vars (Gerd Hoffmann) > > Isaku Yamahata (5): > seabios: acpi: add mcfg table. > seabios: acpi, fadt: make while fadt initialization chipset specific > seabios: pci: enable SERR of normal device. > seabios: add q35 initialization functions. > seabios: q35: add dsdt > > Jan Kiszka (1): > seabios: q35: Register PCI IRQs as active high in APIC mode > > Jason Baron (3): > seabios: make mttr UC area setup dynamic > seabios: q35: add basic hotplug support > seabios: Build the dsdt separately > > Makefile | 12 +- > src/acpi-dsdt.dsl |3 - > src/acpi.c| 189 -- > src/acpi.h| 17 + > src/config.h |1 - > src/dev-q35.h | 46 +++ > src/mtrr.c|5 +- > src/pci.h |1 + > src/pciinit.c | 88 +- > src/post.c|6 +- > src/q35-acpi-dsdt.dsl | 980 > + > src/shadow.c | 13 + > src/smm.c | 37 ++ > 13 files changed, 1357 insertions(+), 41 deletions(-) > create mode 100644 src/dev-q35.h > create mode 100644 src/q35-acpi-dsdt.dsl > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] FirmwareTestSuiteLive
Use FirmwareTestSuiteLive to check how well SeaBIOS behaves. https://wiki.ubuntu.com/HardwareEnablementTeam/Documentation/FirmwareTestSuiteLive https://wiki.ubuntu.com/Kernel/Reference/fwts ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Bootorder file question regarding USB hubs/devices
The format doesn't look very human friendly. It looks rather cryptic. On Sun, Sep 2, 2012 at 9:55 PM, Kevin O'Connor wrote: > On Thu, Aug 30, 2012 at 11:28:44AM -0500, Dave Frodin wrote: >> Previously (before fetching the latest seabios/master) our bootorder file >> looked like this >> >> /pci@i0cf8/usb@12,2/*@4 >> /pci@i0cf8/usb@12,2/*@5 >> /pci@i0cf8/usb@12,2/*@3 >> /pci@i0cf8/usb@12,2/*@2 >> /pci@i0cf8/usb@12,2/*@1 >> /pci@i0cf8/usb@12,2/*@0 >> >> Now it looks like this. This also includes devices plugged into hubs on two >> of the ports. >> (Thank you to whoever got hubs working) >> >> /pci@i0cf8/usb@12,2/storage@5/*@0/*@0,0 > > The format was changed to support luns on usb drives. Hubs should > have worked before as well. > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [ANNOUNCE] SeaBIOS 1.7.1
Great to see a new release out! :) Now lets merge some new stuff! :D On Fri, Aug 31, 2012 at 7:31 PM, Kevin O'Connor wrote: > The 1.7.1 version of SeaBIOS has now been released. For more > information on the release, please see: > > http://seabios.org/Releases > > > New in this release: > > * Initial support for booting from USB attached scsi (USB UAS) drives > * USB EHCI 64bit controller support > * USB MSC multi-LUN device support > * Support for booting from LSI SCSI controllers on emulators > * Support for booting from AMD PCscsi controllers on emulators > * New PCI allocation code on emulators. Support 64bit PCI bars and mapping > them above 4G. > * Support for non-linear APIC ids on emulators. > * Stack switching for 16bit real mode irq handlers to reduce stack footprint. > * Support for custom storage in the memory at 0xc-0xf. No longer > reserve memory for custom storage in first 640k. > * Improved code generation for 16bit segment register loads > * Boot code will now (by default) reboot after 60 seconds if no boot device > found > * CBFS and FWCFG "files" are now only scanned one time > * Several bug fixes > > > For information on obtaining SeaBIOS, please see: > > http://seabios.org/Download > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] DC Mapping
Can SeaBIOS output colored text? It would be good to highlight keys. such as "Press F12 for menu" then highlight "F12". Other BIOS such as Award and AMI can use colors in text. Example "Press F12 for boot menu", then "F12" is in highlighted color. On Fri, Aug 31, 2012 at 4:21 PM, Christian Gmeiner wrote: > Hi all, > > I posted some patches to the ML and want to discuss a part of if - DC mapping. > > After looking at the patches again, I think I miss understood something :) DC > mapping is used to be able to configure the display controller via the defined > memory region. > > A Graphics Mode > B Monochrome Text Mode > B8000 Color Text Mode > > That would mean that if I map the DC to A I can access its registers via > A + register offset or? If this is the case then drop my last two patches. > > The "bad" thing is that I don't have a "normal" lx800 platform to test all my > patches. > > --- > Christian Gmeiner, MSc > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Failed flash recovery & dual BIOS support
Add support for "dual BIOS" and failed flash recovery. Many motherboards have 2 firmware ICs. Motherboard manufacturers tend to market this as "dual BIOS". It checks the integrity of the BIOS and if it fails the test, then it boots using the other firmware image on the other circuit. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Flash firmware from firmware
Add support for flashing the firmware from the firmware without first loading an operating system and flashing within the OS. This could be implemented as a payload. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] NIST publishes draft guidelines for server BIOS protection
http://paritynews.com/security/item/215-nist-publishes-draft-guidelines-for-server-bios-protection http://csrc.nist.gov/publications/drafts/800-147b/draft-sp800-147b_july2012.pdf ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [CCE 4177-2] The XD/NX processor feature should be enabled or disabled as appropriate in the BIOS
Add setting to enable/disable XD/NX-bit for security. http://nvd.nist.gov/scap/content/stylesheet/scap-rhel5-document.htm ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [CCE 3944-6] Option to disable booting from USB devices
CCE 3944-6 http://nvd.nist.gov/scap/content/stylesheet/scap-rhel5-document.htm "An attacker with physical access could try to boot the system from a USB flash drive and then access any data on the system’s hard drive, circumventing the normal operating system’s access controls. To prevent this, configure the BIOS to disallow booting from USB drives. Also configure the BIOS or firmware password as described in Section 2.3.5.1 to prevent unauthorized configuration changes." ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] tsc: use kvmclock for calibration
Add a comment about it in the source code. -#define PM_TIMER_FREQUENCY 3579545 +#define PM_TIMER_FREQUENCY 3579545 // 3.579545 MHz clock required by ACPI spec. On Mon, Aug 13, 2012 at 12:46 PM, Gleb Natapov wrote: > On Mon, Aug 13, 2012 at 12:37:11PM +0200, Gerd Hoffmann wrote: >> Hi, >> >> > Isnt pmtimer ioport usable? 14MHz. >> >> Can give it a try. 14 MHz looks wrong though, apci.h says: >> >> /* PM Timer ticks per second (HZ) */ >> #define PM_TIMER_FREQUENCY 3579545 >> >> Is this fixed? Or hardware specific? >> > 3.579545 MHz clock required by ACPI spec. > > -- > Gleb. > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
Yeah, but how about on real hardware? Does SeaBIOS have some POST beep codes? On Fri, Aug 10, 2012 at 9:30 PM, Markus Armbruster wrote: > "Fred ." writes: > >> On Fri, Aug 10, 2012 at 5:28 PM, Markus Armbruster wrote: >>> Frediano Ziglio 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 f with extended ROM at e. >>> >>> 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 >>> >>> [...] > >> Some machines also have broken memory modules. >> So some computers have 0 byte RAM in that case. :D > > Yup, be we *can* catch that in QEMU :) ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
Some machines also have broken memory modules. So some computers have 0 byte RAM in that case. :D On Fri, Aug 10, 2012 at 5:28 PM, Markus Armbruster wrote: > Frediano Ziglio 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 f with extended ROM at e. > > 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 > > [...] > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] tsc: use kvmclock for calibration
It should be kHz not khz.
-msr, (u32)khz / 1000);
+msr, (u32)kHz / 1000);
On Thu, Aug 9, 2012 at 2:53 PM, Avi Kivity wrote:
> On 08/09/2012 02:57 PM, Gerd Hoffmann wrote:
>> Use kvmclock for tsc calibration when running on kvm. Without this the
>> tsc frequency calibrated by seabios can be *way* off in case the virtual
>> machine is booted on a loaded host. I've seen seabios calibrating 27
>> instead of ca. 2800 MHz, resulting in timeouts being to short by factor
>> 100. Which in turn leads to disk I/O errors due to timeouts, especially
>> as I/O requests tend to take a bit longer than usual on a loaded box ...
>
>> +
>> +struct pvclock_vcpu_time_info {
>> + u32 version;
>> + u32 pad0;
>> + u64 tsc_timestamp;
>> + u64 system_time;
>> + u32 tsc_to_system_mul;
>> + s8tsc_shift;
>> + u8flags;
>> + u8pad[2];
>> +} PACKED;
>> +
>> +
>> +u64 kvm_tsc_khz(void)
>> +{
>> +u32 eax, ebx, ecx, edx, msr;
>> +struct pvclock_vcpu_time_info time;
>> +u32 addr = (u32)(&time);
>> +u64 khz;
>> +
>> +/* check presence and figure msr number */
>> +cpuid(KVM_CPUID_FEATURES, &eax, &ebx, &ecx, &edx);
>> +if (eax & KVM_FEATURE_CLOCKSOURCE2) {
>> +msr = MSR_KVM_SYSTEM_TIME_NEW;
>> +} else if (eax & KVM_FEATURE_CLOCKSOURCE) {
>> +msr = MSR_KVM_SYSTEM_TIME;
>> +} else {
>> +return 0;
>> +}
>> +
>> +/* ask kvm hypervisor to fill struct */
>> +memset(&time, 0, sizeof(time));
>> +wrmsr(msr, addr | 1);
>
> How can this work? There is a 64-byte alignment requirement.
>
>> +wrmsr(msr, 0);
>> +if (time.version < 2 || time.tsc_to_system_mul == 0)
>> +return 0;
>> +
>> +/* go figure tsc frequency */
>> +khz = pvclock_tsc_khz(&time);
>> +dprintf(1, "Using kvmclock, msr 0x%x, tsc %d MHz\n",
>> +msr, (u32)khz / 1000);
>> +return khz;
>
> That's a meaningless number. You can be migrated to a cpu or a machine
> with very different tsc.
>
> You want accurate time on kvm, don't use the tsc.
>
>
> --
> error compiling committee.c: too many arguments to function
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
No, I am not. But I believe QEMU does have the functionality to load an arbitrary firmware. So the firmware doesn't necessarily have to be SeaBIOS. Don't know if its possible to make QEMU use an UEFI or OpenFirmware image instead, or if such an image exists. On Thu, Aug 9, 2012 at 2:59 PM, Peter Stuge wrote: > 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 > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
But QEMU may use other firmware/payload than SeaBIOS which might require less than 1 MB of RAM. On Thu, Aug 9, 2012 at 10:15 AM, Markus Armbruster wrote: > "Kevin O'Connor" writes: > >> On Wed, Aug 08, 2012 at 01:50:13PM +0200, Markus Armbruster wrote: >>> 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 >>> 0x4000 >>> >>> 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? >> >> SeaBIOS requires a minimum of 1Meg of ram. I didn't even know one >> could request less than 1meg of ram from QEMU. > > I'll cook up a QEMU patch to give it at least that much. > > Thanks! > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
Interesting question. No idea. Try giving it more memory until it doesn't crash then you'll eventually find out. :) On Wed, Aug 8, 2012 at 1:50 PM, Markus Armbruster wrote: > 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 > 0x4000 > > 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? > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Seabois] BSOD during start of Win2003 installation
I think Windows 2003 uses a more modern code base than Windows XP. 2003 is more similar to XP 64-bit. On Mon, Aug 6, 2012 at 8:49 AM, Gerd Hoffmann wrote: > On 07/24/12 19:51, Alexey Korolev wrote: >> Hi, >> >> Win2003 falls to BSOD during early init stage of installer. >> It is ACPI related issue and it appears in any configuration. RAM size is 6GB >> Error code is : >> 0x00A5 (0x02, 0xfADF6A446880, 0x1, 0xFADFAA34690) >> >> The things get broken after commit 2062f2bab81915c5c1f7af12a49ad8d4b3fd23fb >> (update dsdt resources at runtime) >> >> I've tried to debug this issue but haven't succeed yet. >> >> One strange thing here is that the code doesn't reach the _CRS method. We >> have added a debug output but nothing related to CRS was printed. >> May be you have any ideas why it may fail. I would much appreciate any help >> on this. > > DBUG() didn't work for me with winxp (same code base as win2k3 iirc), so > no debug output is *not* an indicator for not reaching _CRS. > > Is this win2k3 with latest service pack? I've used winxp with sp3 for > testing ... > > cheers, > Gerd > > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks
I get the same error. On Sun, Aug 5, 2012 at 8:22 AM, Alec Ari wrote: > 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 > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] IEEE 1394 interface booting
I see. I propose a "things-not-implemented" list and add FireWire and TPM to it. Then people can know what is not implemented, and what could be worked on. On Sat, Aug 4, 2012 at 5:17 PM, Peter Stuge wrote: > Fred . wrote: >> I see. >> It should be added to an TODO list though. >> Or "things-you-work-on" list. > > TODO is for things that existing project participants plan to do. > > FireWire and TPM is not neccessarily planned by anyone. If you plan > to do it, then please just send a patch which introduces something > to the code, even if just documentation about current progress. > > If "you" in "things-you-work-on" means existing project participants > then the same is true. > > If someone was working on these features, there would be sign of that > in the repository or on the mailing list. Neither is true. > > If you want to work on either of these features then I suggest to > send some patches to make your effort visible, even if you are still > nowhere near submitting final patches for inclusion. > > Just like in every other open source project. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] IEEE 1394 interface booting
I see. It should be added to an TODO list though. Or "things-you-work-on" list. On Sat, Aug 4, 2012 at 1:44 PM, Peter Stuge wrote: > Fred . wrote: >> Add support for booting from IEEE 1394 (aka FireWire) interface. > > Same here - noone is likely to do this until they want to have it > themselves. When someone is doing an implementation we can talk about > details. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Stance on TPM?
So such patches would be accepted? If so, then maybe put TPM on the TODO list. On Sat, Aug 4, 2012 at 1:43 PM, Peter Stuge wrote: > Fred . wrote: >> What is SeaBIOS stance on Trusted Platform Module (TPM) ? > > I guess that there is no stance until you or someone else sends > patches that we can discuss. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] IEEE 1394 interface booting
Add support for booting from IEEE 1394 (aka FireWire) interface. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Stance on TPM?
What is SeaBIOS stance on Trusted Platform Module (TPM) ? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [BUG] BSOD on Win2003 Server when 64bit PCI resource is present
Bug Check 0xA5: ACPI_BIOS_ERROR Bug Check 0x2: DEVICE_QUEUE_NOT_BUSY http://msdn.microsoft.com/en-us/library/windows/hardware/ff560114%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff557475%28v=vs.85%29.aspx - at the bottom there is a send comment to Microsoft form http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/cpa002_wh06.ppt -- ACPI In Windows Vista (PowerPoint presentation) https://support.microsoft.com/oas/default.aspx?&ln=en-us&x=14&y=13&sd=gn&gprid=3198&&st=1&wfxredirect=1 -- From here it is possible to file a support request https://www.google.com/?q=0x00A5 On Sat, Jul 28, 2012 at 5:27 PM, Kevin O'Connor wrote: > On Thu, Jul 26, 2012 at 03:38:47PM +, 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: 0x00A5 (0x02, 0xfADF6A446880, 0x1, >> 0xFADFAA34690) >> >> 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 > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
Good luck with it! :) Hope to hear back soon how it goes with it, and patches contributed back upstreams. On Sun, Jul 15, 2012 at 6:14 AM, Darmawan Salihun wrote: > Hi Fred, > > Yes, I need it to test something at work. It's not very urgent at the moment. > > Regards, > > Darmawan > > On 7/15/12, Fred . wrote: >> Darmawan, will you be implementing PnP support in SeaBIOS? >> >> On Sat, Jul 14, 2012 at 9:50 PM, Darmawan Salihun >> wrote: >>> On 7/15/12, Kevin O'Connor wrote: >>>> On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: >>>>> First, I made a mistake, I was actually referring to the PnP support >>>> >>>> On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: >>>>> Is there any plan to add this feature in the near future? >>>>> I have a plan to add the feature if it's not there yet, but I want to >>>>> know first whether >>>>> there's already plan for that. >>>> >>>> I have no plans to implement PnP, and I have not heard of any plans >>>> from anyone else. To the best of my knowledge, nothing really uses >>>> the PnP interface anymore. The stubs are in SeaBIOS to make some >>>> option roms (namely gpxe) recognize that the BBS spec is supported. >>>> >>>> Feel free to send patches. >>>> >>>> -Kevin >>>> >>> >>> OK. Thanks for the info. >>> >>> Regards, >>> >>> Darmawan >>> >>> -- >>> >>> -= Human knowledge belongs to the world =- >>> >>> ___ >>> SeaBIOS mailing list >>> SeaBIOS@seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >> > > > -- > > -= Human knowledge belongs to the world =- ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Plan to add POST memory manager (PMM) support
Darmawan, will you be implementing PnP support in SeaBIOS? On Sat, Jul 14, 2012 at 9:50 PM, Darmawan Salihun wrote: > On 7/15/12, Kevin O'Connor wrote: >> On Sun, Jul 15, 2012 at 02:20:42AM +0700, Darmawan Salihun wrote: >>> First, I made a mistake, I was actually referring to the PnP support >> >> On Sat, Jul 14, 2012 at 10:57:00PM +0700, Darmawan Salihun wrote: >>> Is there any plan to add this feature in the near future? >>> I have a plan to add the feature if it's not there yet, but I want to >>> know first whether >>> there's already plan for that. >> >> I have no plans to implement PnP, and I have not heard of any plans >> from anyone else. To the best of my knowledge, nothing really uses >> the PnP interface anymore. The stubs are in SeaBIOS to make some >> option roms (namely gpxe) recognize that the BBS spec is supported. >> >> Feel free to send patches. >> >> -Kevin >> > > OK. Thanks for the info. > > Regards, > > Darmawan > > -- > > -= Human knowledge belongs to the world =- > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Flat Panel Support
I want it to boot 1920x1200 from the start. Then my Linux kernel loads and its still at 1920x1200 without any mode switch and flickering. On Mon, Jul 9, 2012 at 11:02 AM, Christian Gmeiner wrote: > Hi all, > > I did some more research and came up with the following idea/plan: > > * search for valid edid binary blob (maybe this can be done with cbfs > from coreboot) > * extend vgasrc/geodevga.c to make use of edid information's > * extend vgasrc/vbe.c to support edid calls (104f15) > > What do you think? > --- > Christian Gmeiner, MSc > > > 2012/7/6 Christian Gmeiner : >> Hi all, >> >> I am working to extend geode VBios to support flat panels. During research >> and testing I run into a the following problem. >> In order to support flat panels some technical details about the panel are >> needed to drive them correctly. >> >> I have seen that some vendors are using EPI to solve this problem: >> http://www.epi-standard.org/ >> >> Is this the way to go? Adding support for EPI into seabios and extend >> geode VBios to make use of the informations provided? >> >> thanks >> --- >> Christian Gmeiner, MSc > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Linux-ready Firmware Kit does not work?
I don't have any serial debug log. Maybe someone more can try for themselves to run it? On Sun, Jun 17, 2012 at 1:29 PM, Peter Stuge wrote: > Fred . wrote: >> when I tried it under QEMU it did not work > > So what happens? What does the serial debug log look like? If you > don't provide details about the problem it is impossible to give > any advice. > > Please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Linux-ready Firmware Kit does not work?
http://phoronix.com/forums/showthread.php?59218-DB-BIOS-ACPI-data-collecting A guy collect output of the Linux-ready Firmware Kit and aggregates the results into a online document. https://spreadsheets.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0ArD2Y0QXFND2dGxhQnNjZ2RNLVF4SGtPUnlCajVyOWc&output=html Intel provides a Linux-ready Firmware Kit, available on a LiveCD (79 MB) ( http://linuxfirmwarekit.org/download/firmwarekit-r3.iso ). You only have to launch it, wait 1 or 2 minutes, and there is a summary of the results based on different topics (memory handling, PCI resources, HPET, ACPI tables, and more). The results is a number of "Fail", "Warn" and "Pass" flags. This Linux-ready Firmware Kit seems to not be developed anymore, but I guess it can give us a idea of the quality of the BIOS. But when I tried it under QEMU it did not work. Anyone know why the Linux-ready Firmware Kit does not work? Is it SeaBIOS fault or QEMU fault or KVM fault? Maybe would nice if it worked to assess the quality of SeaBIOS. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/4] update bios date
But its 2012 not 2011 now...
On Thu, Jun 7, 2012 at 10:34 AM, Gerd Hoffmann wrote:
> Linux ignores some information from acpi in case the bios is old
> as acpi support used to be buggy in the early days. This affects
> ressources for example (unless forced with pci=use_crs). So lets
> go for something more recent. With this patch applied the
> ressources for \\SB.PCI0 will show up in /proc/{iomem,ioports},
> tagged as "PCI Bus :00".
>
> Signed-off-by: Gerd Hoffmann
> ---
> src/smbios.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/smbios.c b/src/smbios.c
> index 20d2d47..fc84aad 100644
> --- a/src/smbios.c
> +++ b/src/smbios.c
> @@ -93,7 +93,7 @@ smbios_entry_point_init(u16 max_structure_size,
> } while (0)
>
> /* Type 0 -- BIOS Information */
> -#define RELEASE_DATE_STR "01/01/2007"
> +#define RELEASE_DATE_STR "01/01/2011"
> static void *
> smbios_init_type_0(void *start)
> {
> --
> 1.7.1
>
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] MBR protection?
Does SeaBIOS support MBR protection like commercial BIOS does? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] GPT disks in a BIOS world
On Tue, Jun 5, 2012 at 5:21 AM, Kevin O'Connor wrote: > On Mon, Jun 04, 2012 at 07:11:30PM -0700, Ralf A. Quint wrote: >> At 03:36 PM 6/4/2012, Kevin O'Connor wrote: >> >On Mon, Jun 04, 2012 at 03:33:05PM +0200, Fred . wrote: >> >> http://mjg59.dreamwidth.org/8035.html >> >> >> >> Does SeaBIOS support GPT disk labels? >> >> Does SeaBIOS understand GPT disk labels? Is it aware of GPT? >> > >> >This is a common misunderstanding of the BIOS. The BIOS doesn't do >> >anything with partition tables at all (at least according to the >> >available specs). Thus, the BIOS doesn't care if it's a legacy >> >partition table or a GPT partition table. >> >> Excuse me, but isn't it the BIOS that after POST is initiating the >> boot process from the active partition? > > Not quite. The BIOS loads the first sector of the hard drive (ie, the > MBR) into memory and runs the code found there. It cares nothing > about the partition table. It's quite common for the executable code > in that first sector to analyze the partition table, load yet other > code, and then jump to that code - but that activity is outside the > BIOS and is easily upgradable. But does GPT disks even have a MBR? Isn't the GPT a replacement for MBR? If the disk doesn't have any MBR, does the BIOS load the first sector of GPT? > > At least, that's what SeaBIOS does and what the available BIOS specs > call for (and what every boot loader I've seen expects the bios to > do). But, who knows what crazy things various comercial BIOSes do. > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] GPT disks in a BIOS world
http://mjg59.dreamwidth.org/8035.html Does SeaBIOS support GPT disk labels? Does SeaBIOS understand GPT disk labels? Is it aware of GPT? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Fix winxp boot regression introduced in ecdc655a.
Maybe it should be documented to prevent this bug from being
re-introduced in the future.
Maybe a comment in the code so developers don't get confused.
On Sun, Jun 3, 2012 at 2:40 AM, Kevin O'Connor wrote:
> The winxp boot loader does something curious - it sets an int 0x1c
> handler, records the stack location, and then spins in place with irqs
> enabled. The 0x1c handler alters the memory just past the stack
> pointer so that when the timer irq returns the code jumps to a new
> location and stop spinning. The winxp code relies on the fact that a
> hw irq will always place 6 bytes at a specific location and that it
> can alter those bytes.
>
> The ecdc655a patch does a full backup/restore of the register state.
> Unfortunately, the restore overwrites the changes made by the winxp
> 0x1c handler.
>
> This patch reverts much of ecdc655a. Hardware irqs are still handled
> on the extra stack, but only the essential register state is backed up
> and restored.
>
> Also, stack_hop_back is changed to only use %sp when changing states -
> this enables the entry code to store just %esp instead of both %esp
> and %sp.
>
> Signed-off-by: Kevin O'Connor
> ---
> src/clock.c | 8
> src/disk.c | 4 ++--
> src/floppy.c | 4 ++--
> src/misc.c | 8
> src/output.c | 9 +
> src/ps2port.c | 8
> src/romlayout.S | 53 -
> src/stacks.c | 2 +-
> src/util.h | 5 +
> 9 files changed, 51 insertions(+), 50 deletions(-)
>
> diff --git a/src/clock.c b/src/clock.c
> index 55dde2e..69e9f17 100644
> --- a/src/clock.c
> +++ b/src/clock.c
> @@ -516,9 +516,9 @@ handle_1a(struct bregs *regs)
>
> // INT 08h System Timer ISR Entry Point
> void VISIBLE16
> -handle_08(struct bregs *regs)
> +handle_08(void)
> {
> - debug_enter(regs, DEBUG_ISR_08);
> + debug_isr(DEBUG_ISR_08);
>
> floppy_tick();
>
> @@ -659,9 +659,9 @@ handle_1583(struct bregs *regs)
>
> // int70h: IRQ8 - CMOS RTC
> void VISIBLE16
> -handle_70(struct bregs *regs)
> +handle_70(void)
> {
> - debug_enter(regs, DEBUG_ISR_70);
> + debug_isr(DEBUG_ISR_70);
>
> // Check which modes are enabled and have occurred.
> u8 registerB = inb_cmos(CMOS_STATUS_B);
> diff --git a/src/disk.c b/src/disk.c
> index 3ca5697..8eff464 100644
> --- a/src/disk.c
> +++ b/src/disk.c
> @@ -885,9 +885,9 @@ handle_13(struct bregs *regs)
>
> // record completion in BIOS task complete flag
> void VISIBLE16
> -handle_76(struct bregs *regs)
> +handle_76(void)
> {
> - debug_enter(regs, DEBUG_ISR_76);
> + debug_isr(DEBUG_ISR_76);
> SET_BDA(disk_interrupt_flag, 0xff);
> eoi_pic2();
> }
> diff --git a/src/floppy.c b/src/floppy.c
> index 5400bb0..72bc79b 100644
> --- a/src/floppy.c
> +++ b/src/floppy.c
> @@ -582,9 +582,9 @@ process_floppy_op(struct disk_op_s *op)
>
> // INT 0Eh Diskette Hardware ISR Entry Point
> void VISIBLE16
> -handle_0e(struct bregs *regs)
> +handle_0e(void)
> {
> - debug_enter(regs, DEBUG_ISR_0e);
> + debug_isr(DEBUG_ISR_0e);
> if (! CONFIG_FLOPPY)
> goto done;
>
> diff --git a/src/misc.c b/src/misc.c
> index d0d6665..b948778 100644
> --- a/src/misc.c
> +++ b/src/misc.c
> @@ -55,9 +55,9 @@ handle_10(struct bregs *regs)
>
> // NMI handler
> void VISIBLE16
> -handle_02(struct bregs *regs)
> +handle_02(void)
> {
> - debug_enter(regs, DEBUG_ISR_02);
> + debug_isr(DEBUG_ISR_02);
> }
>
> void
> @@ -71,9 +71,9 @@ mathcp_setup(void)
>
> // INT 75 - IRQ13 - MATH COPROCESSOR EXCEPTION
> void VISIBLE16
> -handle_75(struct bregs *regs)
> +handle_75(void)
> {
> - debug_enter(regs, DEBUG_ISR_75);
> + debug_isr(DEBUG_ISR_75);
>
> // clear irq13
> outb(0, PORT_MATH_CLEAR);
> diff --git a/src/output.c b/src/output.c
> index 1fe5d91..37c4942 100644
> --- a/src/output.c
> +++ b/src/output.c
> @@ -487,6 +487,15 @@ dump_regs(struct bregs *regs)
> , regs->code.seg, regs->code.offset, regs->flags);
> }
>
> +// Report entry to an Interrupt Service Routine (ISR).
> +void
> +__debug_isr(const char *fname)
> +{
> + puts_cs(&debuginfo, fname);
> + putc(&debuginfo, '\n');
> + debug_serial_flush();
> +}
> +
> // Function called on handler startup.
> void
> __debug_enter(struct bregs *regs, const char *fname)
> diff --git a/src/ps2port.c b/src/ps2port.c
> index 601e40d..d4626d6 100644
> --- a/src/ps2port.c
> +++ b/src/ps2port.c
> @@ -356,12 +356,12 @@ ps2_mouse_command(int command, u8 *param)
>
> // INT74h : PS/2 mouse hardware interrupt
> void VISIBLE16
> -handle_74(struct bregs *regs)
> +handle_74(void)
> {
> if (! CONFIG_PS2PORT)
> return;
>
> - debug_enter(regs, DEBUG_ISR_74);
> + debug_isr(DEBUG_ISR_74);
>
> u8 v = inb(PORT_PS2_STATUS);
> if ((v & (I8042_STR_OBF|I8042_STR_AUXDATA))
> @@ -383,12 +383,12 @@ done:
>
> // INT09h : Keyboard Hardware Service Entry Point
> void VISIBLE16
> -handle_09(struct bregs *regs)
> +handle_
Re: [SeaBIOS] OS that don't work?
Why does not Windows 98 work with SeaBIOS? Is it because Windows 98 sucks and is buggy and does not adhere to BIOS? Or is it because SeaBIOS doesn't do what it is supposed to do? On Sun, May 27, 2012 at 12:56 AM, Kevin O'Connor wrote: > On Sat, May 26, 2012 at 10:41:32PM +0200, nap wrote: >> Le 26/05/2012 14:06, Fred . a écrit : >> > Is there any x86 operating system that SeaBIOS can not boot? >> > Why? >> > >> > ___ >> > SeaBIOS mailing list >> > SeaBIOS@seabios.org >> > http://www.seabios.org/mailman/listinfo/seabios >> > >> >> SeaBIOS is not currently (1.6.3) fully able to boot W98SE. >> >> That is just for information, I am in fact quite happy to be able to use >> a new box with W98SE. >> I am currently upgrading from a quite old and deceased box with W98SE on >> it to a QEMU/SeaBIOS brand new box. >> After some expected difficulties mostly linked to get proper >> information, I am now trying to assess the interaction between >> QEMU/Seabios and W98SE. I can say that during the upgrade process, W98SE >> recognize SeaBIOS as "BIOS Plug-and-Play", something new to install but >> W98SE consider it as not functioning properly. > > If you're willing to compile SeaBIOS, you could try disabling the > plug-and-play support (make menuconfig -> BIOS interfaces -> PnP BIOS > interface). > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] OS that don't work?
Is there any x86 operating system that SeaBIOS can not boot? Why? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] VirtualBox BIOS
Can SeaBIOS be used with VirtualBox? Why isn't SeaBIOS the default BIOS in VirtualBox? Since VirtualBox is open source, can or does the SeaBIOS project look at the source code of the BIOS implementation in VirtualBox for hints how things are done? Can SeaBIOS be used with VMware? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Searching for an MS-DOS CD driver
I don't know. http://bootdisk.com/ http://en.wikipedia.org/wiki/MSCDEX On Tue, May 22, 2012 at 11:30 PM, nap wrote: > My old W98SE box has died of a rough handling, but the HDD has survived > the crash. > For continuity of service and fun, I have chosen to try to use QEMU, > with SeaBIOS. > As a validation try, I have created an image of FreeDOS1.1 without any > problem. > Next I booted an image of the HDD. All is going fine, but the MS-DOS of > W98SE > is not able to access the installation CD of W98SE needed to adjust to > the new hardware configuration because of the absence of a proper driver. > SeaBIOS is able to access a CD drive. So my question is: > Do you know if there exist some MS-DOS W98SE CD driver using the SeaBIOS > CD service ? > > Configuration: > Asrock H77Mᯎ㓻솨, Gentoo/Linux stable amd64 (x86_64) Gnome > qemu-kvm-1.0.1 > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Website broken
Database error Jump to: navigation, search A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "Revision::fetchFromConds". Database returned error "1: no such column: rev_sha1". ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
On Mon, May 7, 2012 at 9:40 AM, Gleb Natapov wrote: > On Sun, May 06, 2012 at 10:26:31PM +0200, Fred . wrote: >> And in terms of standards compliance? >> >> I know proprietary BIOS have advantage when it comes to SMBIOS due to >> the implementation in SeaBIOS lagging behind several versions. >> >> On Sun, May 6, 2012 at 8:00 PM, Peter Stuge wrote: >> > Fred . wrote: >> >> How is SeaBIOS working towards the non-technical goals of the project? >> > >> > This is not so clear. I'm not even sure that there are non-technical >> > goals for the project. >> > >> > Competing with commercial BIOS products would require a company to >> > put a SeaBIOS-based PC firmware to market, quite likely in concert >> > with coreboot. I know of one company which offers among other things >> > coreboot services, Sage Engineering, who are quite active in the >> > coreboot community. http://www.se-eng.com/coreboot.html >> > >> > But even so you can see that the business model is different from >> > commercial BIOS products, and already this small difference presents >> > a non-technical challenge. >> >> SeaBIOS lacks documentation. >> It lacks communication. >> The website is not updated with news about the development. >> There is no mention of what's new, whats planned, etc. > Now I am curious what other BIOSes give you all that? In all that points > Seabios in not different from most other open source project. > > -- > Gleb. Perhaps other BIOS have private channels to make such communications directly to their customers. Or perhaps they don't need to due to having been in the BIOS game pretty much since it started. I think information, documentation, roadmaps, public announcements, timely communication would be good. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
On Sun, May 6, 2012 at 10:58 PM, Peter Stuge wrote: > Fred . wrote: >> And in terms of standards compliance? > > The nature of BIOS is that there isn't a standard to comply with. > SMBIOS, PnP BIOS, BIOS Boot Specification, LBA, EDD, APM, PMM, ESCD, MultiProcessor Specification, etc. >> I know proprietary BIOS have advantage when it comes to SMBIOS due >> to the implementation in SeaBIOS lagging behind several versions. > > Do you know of concrete issues because of this lag, or did you notice > a number that is smaller in SeaBIOS than somewhere else? > > Ie. do you see a technical disadvantage because of the difference in > SMBIOS versions? I am not familiar with the technicalities of SMBIOS or the changes to the specification introduced from version to version. I did notice the version number of SMBIOS in SeaBIOS being behind the official specification as well as the implementations of the competition. Assuming the version numbers actually mean something and weren't incremented for fun, I guess the competition is ahead and have a technological advantage in this area. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
And in terms of standards compliance? I know proprietary BIOS have advantage when it comes to SMBIOS due to the implementation in SeaBIOS lagging behind several versions. On Sun, May 6, 2012 at 8:00 PM, Peter Stuge wrote: > Fred . wrote: >> How is SeaBIOS working towards the non-technical goals of the project? > > This is not so clear. I'm not even sure that there are non-technical > goals for the project. > > Competing with commercial BIOS products would require a company to > put a SeaBIOS-based PC firmware to market, quite likely in concert > with coreboot. I know of one company which offers among other things > coreboot services, Sage Engineering, who are quite active in the > coreboot community. http://www.se-eng.com/coreboot.html > > But even so you can see that the business model is different from > commercial BIOS products, and already this small difference presents > a non-technical challenge. SeaBIOS lacks documentation. It lacks communication. The website is not updated with news about the development. There is no mention of what's new, whats planned, etc. > > >> That said, still curious about a technical comparison. > > As far as BIOS goes, SeaBIOS will boot and run I believe any OS that > a commercial BIOS product does. Differences at this point are perhaps > primarily how the build is configured and run, how execution is > configured, and the presentation of SeaBIOS during runtime. > > Because SeaBIOS has a technical goal of not spending more time than > neccessary on any task, there isn't much presentation to talk about. > > Build configuration in SeaBIOS is based on Kconfig, comfortable for > anyone who has built a Linux kernel or busybox, but perhaps not > completely intuitive for developers who primarily have experience > from using Windows systems. > > The build system itself of SeaBIOS relies on the GNU toolchain, > including optionally rather new features, contrary to commercial > BIOS products which typically rely on quite old Microsoft toolchains. > > Runtime configuration in SeaBIOS consists of the F12 menu when > multiple boot sources are found, and the QEMU-specific fwcfg > interface - compared to the classic text-mode setup menu screens in > commercial BIOS products. > > Then there's of course the fact that BIOS is no longer really > relevant for many mainboard vendors, whose customers expect UEFI. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS vs other BIOS?
How is SeaBIOS working towards the non-technical goals of the project? That said, still curious about a technical comparison. On Sun, May 6, 2012 at 4:36 PM, Peter Stuge wrote: > This has very little to do with technical properties, and is much > more about politics which obviously require a different approach > than technicalities. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] SeaBIOS vs other BIOS?
What features and functionality does SeaBIOS have that other BIOS does not? What features and functionality does other BIOS have that is better than what SeaBIOS offers? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [ANNOUNCE] SeaBIOS 1.7.0
Great! :) Nice to see a new release out. Please make a notice about the release on the front page of the seabios website. On Sun, Apr 15, 2012 at 4:48 AM, Kevin O'Connor wrote: > The 1.7.0 version of SeaBIOS has now been released. For more > information on the release, please see: > > http://seabios.org/Releases > > > New in this release: > > * Many enhancements to VGA BIOS code - it should now be feature complete with > LGPL vgabios. > * Support for virtio-scsi. > * Improved USB drive (usb-msc) support. > * Several USB controller bug fixes and improvements. > * Runtime ACPI AML PCI hotplug construction. > * Support for running on i386 and i486 CPUs. > * Enhancements to PCI init when running on emulators. > * Several bug fixes > > > For information on obtaining SeaBIOS, please see: > > http://seabios.org/Download > > -Kevin > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] BEV and bootorder
Why would anyone want to define some devices as unbootable? On Sun, Apr 15, 2012 at 8:57 AM, Gleb Natapov wrote: > On Sat, Apr 14, 2012 at 11:19:31PM -0400, Kevin O'Connor wrote: >> On Thu, Apr 12, 2012 at 01:30:36PM -0600, Steve Goodrich wrote: >> > I'm working towards a goal of having specific devices be bootable, and >> > *only* those devices. For example, if my bootorder file specifies SATA >> > drive 3, I do not want it to try SATA drives 0, 1, and 2, nor any other HDD >> > or floppy that it finds. >> > >> > My first question is: how do I do this? >> >> There is no current way to do this. I suppose one could code support >> for a "stop boot" option to the boot order file - so that if it was >> listed in the file the boot would stop after trying all options prior >> to it. >> > I thought to add skipboot file. If device is in skipboot file it is not > considered for booting from. > >> > If that can't be answered, can someone explain to me the relationship >> > between the bootorder file and the BEV (Boot Execution Vector) configured >> > in >> > boot.c? >> >> All possible boot options (both BEV and BCV) are assembled in a sorted >> list pointed to by boot.c:BootList. The bootorder file alters the >> default sort order of that list. During the latter parts of the POST >> phase, the BCVs are executed and only BEVs remain. The list of BEVs >> is generated from the BootList. So, in a nutshell, the bootorder file >> determines the order of the BEVs that SeaBIOS will attempt to boot >> from. >> >> -Kevin >> >> ___ >> SeaBIOS mailing list >> SeaBIOS@seabios.org >> http://www.seabios.org/mailman/listinfo/seabios > > -- > Gleb. > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] BEV and bootorder
2012/4/15 Gleb Natapov : > On Sun, Apr 15, 2012 at 02:24:05PM +0200, Fred . wrote: >> Why would anyone want to define some devices as unbootable? >> > Because he does not want to boot from them. Then the partition should not be flagged as a boot partition, and it won't be booted from. Then it proceeds to try to boot from the next device. > >> On Sun, Apr 15, 2012 at 8:57 AM, Gleb Natapov wrote: >> > On Sat, Apr 14, 2012 at 11:19:31PM -0400, Kevin O'Connor wrote: >> >> On Thu, Apr 12, 2012 at 01:30:36PM -0600, Steve Goodrich wrote: >> >> > I'm working towards a goal of having specific devices be bootable, and >> >> > *only* those devices. For example, if my bootorder file specifies SATA >> >> > drive 3, I do not want it to try SATA drives 0, 1, and 2, nor any other >> >> > HDD >> >> > or floppy that it finds. >> >> > >> >> > My first question is: how do I do this? >> >> >> >> There is no current way to do this. I suppose one could code support >> >> for a "stop boot" option to the boot order file - so that if it was >> >> listed in the file the boot would stop after trying all options prior >> >> to it. >> >> >> > I thought to add skipboot file. If device is in skipboot file it is not >> > considered for booting from. >> > >> >> > If that can't be answered, can someone explain to me the relationship >> >> > between the bootorder file and the BEV (Boot Execution Vector) >> >> > configured in >> >> > boot.c? >> >> >> >> All possible boot options (both BEV and BCV) are assembled in a sorted >> >> list pointed to by boot.c:BootList. The bootorder file alters the >> >> default sort order of that list. During the latter parts of the POST >> >> phase, the BCVs are executed and only BEVs remain. The list of BEVs >> >> is generated from the BootList. So, in a nutshell, the bootorder file >> >> determines the order of the BEVs that SeaBIOS will attempt to boot >> >> from. >> >> >> >> -Kevin >> >> >> >> ___ >> >> SeaBIOS mailing list >> >> SeaBIOS@seabios.org >> >> http://www.seabios.org/mailman/listinfo/seabios >> > >> > -- >> > Gleb. >> > >> > ___ >> > SeaBIOS mailing list >> > SeaBIOS@seabios.org >> > http://www.seabios.org/mailman/listinfo/seabios > > -- > Gleb. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Version bump?
Yes, I was thinking maybe perhaps it was a mistake. On Sun, Apr 8, 2012 at 8:47 AM, Gleb Natapov wrote: > On Sun, Apr 08, 2012 at 03:37:08AM +0200, Peter Stuge wrote: >> Fred . wrote: >> > Why did the version jump from 0.6.2 to 1.6.3 ? >> >> Who cares - it's just a number. >> > Looks like mistake to me. If it is, why not point it out :) > > -- > Gleb. > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Version bump?
http://www.seabios.org/Releases Why did the version jump from 0.6.2 to 1.6.3 ? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] New packages
Please upload new packages on: http://code.coreboot.org/p/seabios/downloads/ ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] Linux-ready Firmware Kit
Linux-ready Firmware Development Kit r3 segfaults under QEMU 0.14.1 (Ubuntu 11.10 Oneiric) during the SUN duplicate test at 30% with the message: Segmentation fault (core dumped) plugins//acpicompile.exe 2>. On Tue, Mar 6, 2012 at 4:04 AM, Peter Stuge wrote: > Fred . wrote: >> Intel provides a Linux-ready Firmware Kit > > This is well-known in the community since many years. > > If you want to contribute then please *USE* the software and either > just report results, or even better send fixes for any problems which > are found. > > As you know, you can do limited testing completely using software. > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Lots of USB work going on
Lately, there been lots of USB work being done with a patch set of 19 patches. Which gets me wondering about thoughts, plans, and status on xHCI (eXtensible Host Controller Interface) in regards to SeaBIOS. So whats up? http://www.intel.com/technology/usb/download/xHCI_Specification_for_USB.pdf ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Linux-ready Firmware Kit
I haven't actually ran it yet. Just though I'd post it here as I came across it and thought it might be useful for the people here to know about. On Sun, Mar 4, 2012 at 12:34 PM, Peter Stuge wrote: > Fred . wrote: >> Intel provides a Linux-ready Firmware Kit, available on a LiveCD > > Yes. > > >> I guess it can give us a idea of the quality of the BIOS. > > So what were your results? > > > //Peter > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Linux-ready Firmware Kit
# yum install pmtools # acpidump > acpi.dump # acpixtract -l acpi.dump # dmidecode Intel provides a Linux-ready Firmware Kit, available on a LiveCD (79 MB) ( http://linuxfirmwarekit.org/download/firmwarekit-r3.iso ). You only have to launch it, wait 1 or 2 minutes, and there is a summary of the results based on different topics (memory handling, PCI resources, HPET, ACPI tables, and more). The results is a number of "Fail", "Warn" and "Pass" flags. This Linux-ready Firmware Kit seems to not be developed anymore, but I guess it can give us a idea of the quality of the BIOS. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.
Maybe run: lsusb -v and compare the output for the difference SanDisk Cruzer USB devices if they're identical or different. On Thu, Mar 1, 2012 at 12:38 AM, Dave Frodin wrote: > I'm a new subscriber to seabios.org so feel free to straighten me out if > needed. > > I've been debugging an problem we've been seeing with not being able to boot > (Ubuntu specifically) off > of a variety of "newer" USB thumb drives. I've been specifically looking at > an older/newer pair of > Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down the > problem to the blockcmd.c file. > The function scsi_init_drive() queries the USB device to determine stuff like > vendor/device/size/etc. > Near the end of the function is a call to cdb_mode_sense_geom(&dop, > &geomdata) to retrieve the info > related to cyl/head type stuff. On the older/working thumbdrive it returns > zeroes for all of the values > that get used by the code. The newer/failing drive generates a "stall" on the > USB bus, which it never > recovers from. The cdb_mode_sense_geom() function is sending a SCSI CDB Mode > Sense (CMD=0x5A) to the device. > > As a hack of a test, I removed the call to cdb_mode_sense_geom() and filled > the buffer it should have returned > with zeroes and the failing thumbdrive now boots. > > I have some searching I need to do to find out... > 1) Is there a SCSI command to determine what protocols are supported? > 2) Is there another SCSI command that might return similar required data? > > Has anyone out there experienced similar booting difficulties? > Or does anyone have any recommendations on what approach I should take? > > thanks, > Dave > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Boot failure with MS-Dos 6.22 (due to bad BIOS build?)
Modern operating systems does not use BIOS much. DOS use BIOS a lot. SeaBIOS is a BIOS, so should be able to run operating systems that use BIOS. So I think DOS is something that ought to run/work on SeaBIOS if SeaBIOS implements BIOS correctly. Shouldn't DOS be some milestone for SeaBIOS? Perhaps there ought to be a BIOS testsuite to test BIOS compliance. On Wed, Feb 29, 2012 at 10:19 AM, Daniel P. Berrange wrote: > On Wed, Feb 29, 2012 at 03:45:13AM -0500, Kevin O'Connor wrote: >> On Mon, Feb 27, 2012 at 04:25:09PM +0100, Jan Kiszka wrote: >> > On 2012-02-27 10:51, Daniel P. Berrange wrote: >> > > I'm seeing current QEMU GIT fail to boot MS-Dos 6.22 with the following >> > > crash: >> > > >> > > # qemu-system-x86_64 -fda ~/MS-DOS\ 6.22.img -m 1 -curses >> >> Does the error persist when run with "-m 2"? If more memory fixes the >> issue, then it is likely already fixed in upstream (commit 890d9851). >> The bugs fixed in that commit are null pointer derefernce errors - in >> SeaBIOS, a write to "NULL" actually alters the memory at address 0, >> which can corrupt the interrupt table - these can lead to >> unpredictable errors, as the timing between when an irq fires and when >> the corruption occurs can vary. DOS might overwrite the irq entries >> with its own settings, and thus depending on timing may cover up the >> error. In short, I wouldn't assume the problem is the toolchain. > > The error occurs no matter what '-m XX' setting I give it. I did a git > bisect across a Seabios GIT from master down torel-1.6.3.1 and could > not reproduce it with any BIOS I built myself. Hence the only conclusion > I could come to is that the QEMU binary was broken in some way. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > ___ > SeaBIOS mailing list > SeaBIOS@seabios.org > http://www.seabios.org/mailman/listinfo/seabios ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Time for a new release?
I'd like to see the ImageMagick-powered bootsplash.sh image generation script merged in. On Wed, Feb 15, 2012 at 2:45 AM, Kevin O'Connor wrote: > Given the vgabios changes, I think the next release should be > v1.7.0. I agree with the version number. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS and Bochs?
On Wed, Feb 15, 2012 at 3:21 AM, Kevin O'Connor wrote: > The latest SeaBIOS tip will work on 80386 - the 1.6.3 version requires > a 80586. I think PCI may be required (to unlock ram). I think 386 is an ok minimum. How about 286 though? Will SeaBIOS work on 286? If not, why not? Is it possible to make it work? Is it worth it? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 3/5] vgabios: Claim VBE 3 support; minor VBE cleanups.
With the VBE 3.0 support claimed, perhaps it is time for a new release soon?
On Tue, Feb 14, 2012 at 2:35 AM, Kevin O'Connor wrote:
> Claim support for VBE3 - that spec is actually more lenient for
> required minimum support.
>
> Signed-off-by: Kevin O'Connor
> ---
> vgasrc/vbe.c | 18 --
> 1 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/vgasrc/vbe.c b/vgasrc/vbe.c
> index 505cb61..852edbc 100644
> --- a/vgasrc/vbe.c
> +++ b/vgasrc/vbe.c
> @@ -11,7 +11,7 @@
> #include "bregs.h" // struct bregs
> #include "vbe.h" // struct vbe_info
> #include "util.h" // dprintf
> -#include "biosvar.h" // get_global_set
> +#include "biosvar.h" // GET_GLOBAL
> #include "vgahw.h" // vgahw_set_mode
>
> u32 VBE_total_memory VAR16 = 256 * 1024;
> @@ -37,7 +37,7 @@ vbe_104f00(struct bregs *regs)
>
> SET_FARVAR(seg, info->signature, VESA_SIGNATURE);
>
> - SET_FARVAR(seg, info->version, 0x0200);
> + SET_FARVAR(seg, info->version, 0x0300);
>
> SET_FARVAR(seg, info->oem_string,
> SEGOFF(get_global_seg(), (u32)VBE_OEM_STRING));
> @@ -47,7 +47,7 @@ vbe_104f00(struct bregs *regs)
> u16 *destmode = (void*)info->reserved;
> SET_FARVAR(seg, info->video_mode, SEGOFF(seg, (u32)destmode));
>
> - /* Total memory (in 64 blocks) */
> + /* Total memory (in 64k blocks) */
> SET_FARVAR(seg, info->total_memory
> , GET_GLOBAL(VBE_total_memory) / (64*1024));
>
> @@ -77,7 +77,7 @@ vbe_104f01(struct bregs *regs)
> struct vgamode_s *vmode_g = vgahw_find_mode(mode);
> if (! vmode_g) {
> dprintf(1, "VBE mode %x not found\n", mode);
> - regs->ax = 0x0100;
> + regs->ax = 0x014f;
> return;
> }
>
> @@ -88,10 +88,7 @@ vbe_104f01(struct bregs *regs)
> VBE_MODE_ATTRIBUTE_GRAPHICS_MODE |
> VBE_MODE_ATTRIBUTE_NOT_VGA_COMPATIBLE;
> u32 framebuffer = GET_GLOBAL(VBE_framebuffer);
> - int depth = GET_GLOBAL(vmode_g->depth);
> - if (depth == 4)
> - mode_attr |= VBE_MODE_ATTRIBUTE_TTY_BIOS_SUPPORT;
> - else if (framebuffer)
> + if (framebuffer)
> mode_attr |= VBE_MODE_ATTRIBUTE_LINEAR_FRAME_BUFFER_MODE;
> SET_FARVAR(seg, info->mode_attributes, mode_attr);
> SET_FARVAR(seg, info->winA_attributes,
> @@ -114,13 +111,14 @@ vbe_104f01(struct bregs *regs)
> SET_FARVAR(seg, info->yres, height);
> SET_FARVAR(seg, info->xcharsize, GET_GLOBAL(vmode_g->cwidth));
> SET_FARVAR(seg, info->ycharsize, GET_GLOBAL(vmode_g->cheight));
> + int depth = GET_GLOBAL(vmode_g->depth);
> int planes = (depth == 4) ? 4 : 1;
> SET_FARVAR(seg, info->planes, planes);
> SET_FARVAR(seg, info->bits_per_pixel, depth);
> SET_FARVAR(seg, info->banks, 1);
> SET_FARVAR(seg, info->mem_model, GET_GLOBAL(vmode_g->memmodel));
> SET_FARVAR(seg, info->bank_size, 0);
> - u32 pages = GET_GLOBAL(VBE_total_memory) / (height * linesize);
> + u32 pages = GET_GLOBAL(VBE_total_memory) / ALIGN(height * linesize,
> 64*1024);
> SET_FARVAR(seg, info->pages, (pages / planes) - 1);
> SET_FARVAR(seg, info->reserved0, 1);
>
> @@ -259,7 +257,7 @@ vbe_104f05(struct bregs *regs)
> regs->ax = 0x004f;
> return;
> fail:
> - regs->ax = 0x0100;
> + regs->ax = 0x014f;
> }
>
> static void
> --
> 1.7.6.5
>
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] Time for a new release?
Lots of stuff have been happening lately (namely VGA and VBE related stuff). Also some fixes. Perhaps it is time for a new release soon? ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] ImageMagick-based SeaBIOS logo generation script
Kevin wanted the logo to be generated using scripted free and libre tools. ImageMagick is scripted and free. What else can I use? On Wed, Feb 8, 2012 at 11:51 AM, Fred . wrote: > Well, then just execute the file and have it generate the jpg, and > then put the jpg file in the source tree. > ImageMagick is shipped by default on Ubuntu. > > On Wed, Feb 8, 2012 at 8:19 AM, Gleb Natapov wrote: >> On Tue, Feb 07, 2012 at 07:59:04PM +0100, Fred . wrote: >>> Please put this file in the repository. I don't know, but somewhere. >>> So it outputs a bootsplash.jpg file to wherever SeaBIOS is looking for >>> that file. >>> >>> #!/bin/sh >>> convert -background black \ >>> -font /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf \ >> This file is hardly available on all machines where this script might >> run. >> >>> -pointsize 96 -size 320x480 \ >>> -gravity East -fill '#2078cb' label:'Sea' \ >>> -gravity West -fill white label:'BIOS' \ >>> +append bootsplash.jpg >> >> >>> ___ >>> SeaBIOS mailing list >>> SeaBIOS@seabios.org >>> http://www.seabios.org/mailman/listinfo/seabios >> >> >> -- >> Gleb. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] ImageMagick-based SeaBIOS logo generation script
Well, then just execute the file and have it generate the jpg, and then put the jpg file in the source tree. ImageMagick is shipped by default on Ubuntu. On Wed, Feb 8, 2012 at 8:19 AM, Gleb Natapov wrote: > On Tue, Feb 07, 2012 at 07:59:04PM +0100, Fred . wrote: >> Please put this file in the repository. I don't know, but somewhere. >> So it outputs a bootsplash.jpg file to wherever SeaBIOS is looking for >> that file. >> >> #!/bin/sh >> convert -background black \ >> -font /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf \ > This file is hardly available on all machines where this script might > run. > >> -pointsize 96 -size 320x480 \ >> -gravity East -fill '#2078cb' label:'Sea' \ >> -gravity West -fill white label:'BIOS' \ >> +append bootsplash.jpg > > >> ___ >> SeaBIOS mailing list >> SeaBIOS@seabios.org >> http://www.seabios.org/mailman/listinfo/seabios > > > -- > Gleb. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] ImageMagick-based SeaBIOS logo generation script
Please put this file in the repository. I don't know, but somewhere. So it outputs a bootsplash.jpg file to wherever SeaBIOS is looking for that file. #!/bin/sh convert -background black \ -font /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf \ -pointsize 96 -size 320x480 \ -gravity East -fill '#2078cb' label:'Sea' \ -gravity West -fill white label:'BIOS' \ +append bootsplash.jpg bootsplash.sh Description: Bourne shell script ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
