SeaBIOS October 2012

seabios@seabios.org

27 participants
89 discussions

Re: [SeaBIOS] [RFC PATCH v3 06/19] Implement "-dimm" command line option
by Avi Kivity 22 Oct '12

22 Oct '12

On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote: > On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote: >> On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote: >> >> >> >> I don't think so, but probably there's a limit of DIMMs that real >> >> controllers have, something like 8 max. >> > >> > In the case of i440fx specifically, do you mean that we should model the DRB >> > (Dram row boundary registers in section 3.2.19 of the i440fx spec) ? >> > >> > The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row >> > maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of >> > memory afaict (bit 31 and above is ignored). >> > >> > I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too >> > restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a >> > waste imho to model an old pc memory controller that only supports 8 DIMMs. >> > >> > There was also an old discussion about i440fx modeling here: >> > https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html >> > the general direction was that i440fx is too old and we don't want to precisely >> > emulate the DRB registers, since they lack flexibility. >> > >> > Possible solutions: >> > >> > 1) is there a newer and more flexible chipset that we could model? >> >> Look for q35 on this list. > > thanks, I 'll take a look. It sounds like the other options below are more > straightforward now, but let me know if you prefer q35 integration as a priority. At least validate that what you're doing fits with how q35 works. >> >> > >> > We could for example model: >> > - an 8-bit non-cumulative register for each DIMM, denoting how many >> > 128MB chunks it contains. This allowes 32GB for each DIMM, and with 255 DIMMs we >> > describe a bit less than 8TB. These registers require 255 bytes. >> > - a 16-bit cumulative register for each DIMM again for 128MB chunks. This allows >> > us to describe 8TB of memory (but the registers take up double the space, because >> > they describe cumulative memory amounts) >> >> There is no reason to save space. Why not have two 64-bit registers per >> DIMM, one describing the size and the other the base address, both in >> bytes? Use a few low order bits for control. > > Do we want this generic scheme above to be tied into the i440fx/pc machine? Yes. q35 should work according to its own specifications. > Or have it as a separate generic memory bus / pmc usable by others (e.g. in > hw/dimm.c)? > The 64-bit values you describe are already part of DimmDevice properties, but > they are not hardware registers described as part of a chipset. > > In terms of control bits, did you want to mimic some other chipset registers? - > any examples would be useful. I don't have any real requirements. Just make it simple and easily accessible to ACPI code. > >> >> > >> > 3) let everything be handled/abstracted by dimmbus - the chipset DRB modelling >> > is not done (at least for i440fx, other machines could). This is the least precise >> > in terms of emulation. On the other hand, if we are not really trying to emulate >> > the real (too restrictive) hardware, does it matter? >> >> We could emulate base memory using the chipset, and extra memory using >> the scheme above. This allows guests that are tied to the chipset to >> work, and guests that have more awareness (seabios) to use the extra >> features. > > But if we use the real i440fx pmc DRBs for base memory, this means base memory > would be <= 2GB, right? > > Sounds like we 'd need to change the DRBs anyway to describe useful amounts of > base memory (e.g. 512MB chunks and check against address lines [36:29] can > describe base memory up to 64GB, though that's still limiting for very large > VMs). But we'd be diverting from the real hardware again. Then there's no point. Modelling real hardware allows guests written to work against that hardware to function correctly. If you diverge, they won't. > > Then we can model base memory with "tweaked" i440fx pmc's DRB registers - we > could only use DRB[0] (one DIMM describing all of base memory) or more. > > DIMMs would be allowed to be hotplugged in the generic mem-controller scheme only > (unless it makes sense to allow hotplug in the remaining pmc DRBs and > start using the generic scheme once we run out of emulated DRBs) > 440fx seems a lost cause, so we can go wild and just implement pv dimms. For q35 I'd like to stay within the spec. -- error compiling committee.c: too many arguments to function

3 2

[PATCH v3 0/8] q35 seabios support
by Jason Baron 22 Oct '12

22 Oct '12

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. 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. Patches have also been reported to work with a small dsdt change on OSX 10.6 as well. I've dropped the ahci migration bits, which means q35 is not migratable at the moment. I simply haven't had time to make them more complete yet. 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 Notes: I've dropped automatic load of the dsdt table on the piix for now. We can't pull this in until we have snapshot of the dsdt aml, and I wanted it to be done at a clean seabios freeze point (Although I guess that could be the current snapshot). I don't see the harm in pulling this in later though. I've also gone to a model of the pci host being sparse: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Cirrus Logic GD 5446 00:02.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) The idea is only to populate the essential stuff at 1f, and have the rest filled out via command line options. In this way we have minimal bus configuration with 1 slot occupied as in piix. Should make things easier for libvirt. And this way user has complete control over things. For example, I have added support that when '-usb' is passed the usb controllers for ich9 are filled out. Todo: -add ahci migration back (need to cover more fields, but basically works) -add base addr for hpet in LPC device (for osx per agraf) -convert hotplug to use MemoryRegionPortio for hotplug (need an IsaDevice?) Thanks, -Jason Changes from v2: -Patch restructure (broke out ich9 chips + data structures separately) -added passthrough support -add support for -usb to fill out host pci bus -Dropped automatic load of dsdt table for piix -cleanups -dropped wmask on smbus (mst) -sparse host bus Changes from v1: -Updated end of low mem from 0xe0000000 -> 0xb0000000 (Gerd Hoffmann) -so 0xb000000-0xc000000 is memconfig -0xc000000-0xfec00000 is 32-bit pci window -style/various cleanups -introduced IF_AHCI -introduced mach_if -split dsdt out of bios, now passed for piix4 as well (Paolo, Gerd) -Removed add opaque argument to pci_map_irq_fn (Michael S. Tsirkin) -removed patches that were merged in v1 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 (2): seabios: make mttr UC area setup dynamic seabios: q35: add basic hotplug support Makefile | 2 +- src/acpi.c | 176 ++++++++- src/acpi.h | 17 + src/config.h | 1 - src/dev-q35.h | 46 +++ src/mtrr.c | 5 +- src/pci.h | 1 + src/pciinit.c | 87 +++++- src/post.c | 6 +- src/q35-acpi-dsdt.dsl | 980 +++++++++++++++++++++++++++++++++++++++++++++++++ src/shadow.c | 13 + src/smm.c | 37 ++ 12 files changed, 1344 insertions(+), 27 deletions(-) create mode 100644 src/dev-q35.h create mode 100644 src/q35-acpi-dsdt.dsl

2 9

Re: [SeaBIOS] [coreboot] USB Problems geode lx800
by Paul Menzel 18 Oct '12

18 Oct '12

Am Donnerstag, den 18.10.2012, 12:25 +0200 schrieb Christian Gmeiner: […] > USB is finally working :) http://dpaste.com/815054/ Congrats. Please attach such outputs. > But the next problems says hello: handle_hwpic1 irq=0 […] That warrants a new thread, does not it? Thanks, Paul

1 0

Re: [SeaBIOS] [coreboot] USB Problems geode lx800
by Peter Stuge 18 Oct '12

18 Oct '12

Christian Gmeiner wrote: > USB is finally working :) http://dpaste.com/815054/ Very nice! //Peter

1 0

Re: [SeaBIOS] USB Problems geode lx800
by Kevin O'Connor 18 Oct '12

18 Oct '12

On Wed, Oct 17, 2012 at 07:42:33AM +0200, Christian Gmeiner wrote: > 2012/10/17 Kevin O'Connor <kevin(a)koconnor.net>: > > On Tue, Oct 16, 2012 at 04:11:08PM +0200, Christian Gmeiner wrote: > >> I have made some success to get USB working - current SeaBios ehci > >> driver does not support toggling between > >> DATA0 and DATA1. Here is my current patch to get a little bit more running: > > > > The toggle bit should be updated automatically by the controller. It > > should not be necessary to do it manually. If this is impacting your > > results, something subtle must going on. > > > > Maybe you are right (starred at the spec for some minutes), but who > updates the toggle bit in the qh? > > So I think that this line is needed: > pipe->qh.token|= (pipe->pipe.toogle?QTD_TOGGLE:0); The controller is supposed to update the toggle bit in the qh. The same qh is used for all transfers, so it should already be up to date between transfers. It is possible something subtle is going on here. -Kevin

2 1

Re: [SeaBIOS] [RFC PATCH v3 06/19] Implement "-dimm" command line option
by Avi Kivity 18 Oct '12

18 Oct '12

On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote: >> >> I don't think so, but probably there's a limit of DIMMs that real >> controllers have, something like 8 max. > > In the case of i440fx specifically, do you mean that we should model the DRB > (Dram row boundary registers in section 3.2.19 of the i440fx spec) ? > > The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row > maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of > memory afaict (bit 31 and above is ignored). > > I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too > restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a > waste imho to model an old pc memory controller that only supports 8 DIMMs. > > There was also an old discussion about i440fx modeling here: > https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html > the general direction was that i440fx is too old and we don't want to precisely > emulate the DRB registers, since they lack flexibility. > > Possible solutions: > > 1) is there a newer and more flexible chipset that we could model? Look for q35 on this list. > > 2) model and document ^--- the critical bit > a generic (non-existent) i440fx that would support more > and larger DIMMs. E.g. support 255 DIMMs. If we want to use a description > similar to the i440fx DRB registers, the registers would take up a lot of space. > In i440fx there is one 8-bit DRB register per DIMM, and DRB[i] describes how > many 8MB chunks are contained in DIMMs 0...i. So, the register values are > cumulative (and total described memory cannot exceed 256x8MB = 2GB) Our i440fx has already been extended by support for pci and cpu hotplug, and I see no reason not to extend it for memory. We can allocate extra mmio space for registers if needed. Usually I'm against this sort of thing, but in this case we don't have much choice. > > We could for example model: > - an 8-bit non-cumulative register for each DIMM, denoting how many > 128MB chunks it contains. This allowes 32GB for each DIMM, and with 255 DIMMs we > describe a bit less than 8TB. These registers require 255 bytes. > - a 16-bit cumulative register for each DIMM again for 128MB chunks. This allows > us to describe 8TB of memory (but the registers take up double the space, because > they describe cumulative memory amounts) There is no reason to save space. Why not have two 64-bit registers per DIMM, one describing the size and the other the base address, both in bytes? Use a few low order bits for control. > > 3) let everything be handled/abstracted by dimmbus - the chipset DRB modelling > is not done (at least for i440fx, other machines could). This is the least precise > in terms of emulation. On the other hand, if we are not really trying to emulate > the real (too restrictive) hardware, does it matter? We could emulate base memory using the chipset, and extra memory using the scheme above. This allows guests that are tied to the chipset to work, and guests that have more awareness (seabios) to use the extra features. -- error compiling committee.c: too many arguments to function

2 1

Re: [SeaBIOS] great things are coming your way :-)
by Peter Stuge 18 Oct '12

18 Oct '12

ron minnich wrote: > I don't even know what to say :-) > > Checking out SeaBIOS revision 51755c3b5ed9dcdfdef8cee56631d68642bde416 > Already on 'master' > fatal: reference is not a tree: 51755c3b5ed9dcdfdef8cee56631d68642bde416 Sorry for not testing more thoroughly, the checkout did work for me, I didn't expect the "regression" caused by: commit eb129bbcb654d90c331b7898222d64f769c08437 Author: Patrick Georgi <patrick(a)georgi-clan.de> Date: Wed May 9 21:07:17 2012 +0200 Update SeaBIOS URL We have a http accessible SeaBIOS mirror at review.coreboot.org. Use it. Apparently our http accessible SeaBIOS mirror isn't getting updated, so the SeaBIOS 1.7.1 release does not exist in what gets cloned. If the above commit is reverted: git revert eb129bbcb654d90c331b7898222d64f769c08437 ..and the build/seabios directory is deleted, then the build will work again. I am not sure that this is the right fix however. I would prefer to have a reliable HTTP URL rather than reverting. Here is an nginx snippet that allows to serve git http: from the same virtual host as a gitweb: location ~* ^/[^/]*\.git { alias /usr/libexec/git-core/git-http-backend; include /etc/nginx/fastcgi_params; fastcgi_param DOCUMENT_ROOT /var/lib/git; fastcgi_param GIT_PROJECT_ROOT /var/lib/git; fastcgi_pass unix:/var/run/spawn-fcgi/git-http; } And here's the fcgiwrap start script, to create that FastCGI socket. All goes on one line of course. #!/bin/sh exec spawn-fcgi -n -s /var/run/spawn-fcgi/git-http -u gitweb -U nginx -d /var/lib/git -f /usr/bin/fcgiwrap Maybe it can help make direct HTTP access available for the actual repository. Please let's not mess with mirroring. If nginx+fastcgi does not fit the current hosting then I guess it will be Apache or lighttpd, in which case the interwebs should have some snippets equivalent to the above. //Peter

1 0

I2C console16/32 segment problems
by Dave Frodin 17 Oct '12

17 Oct '12

All, I've added code to output.c to implement a I2C console interface. Everything was working great on my AMD/Persimmon until I added additional code to determine what south bridge I was on. I'm evidently not correctly handling the 16/32 bit code segments correctly. It's evident when I run the debugger and watch the disassembly. Not only is the disassembly wrong but it isn't even consistent between runs. The new code is below, along with the modified putc_debug(). Any suggestions would be appreciated. Thanks, Dave #if MODE16 #define FIXUP_CODE_SEG_LOCATION VAR16 #elif MODESEGMENT #define FIXUP_CODE_SEG_LOCATION VAR32SEG #else #define FIXUP_CODE_SEG_LOCATION #endif struct amd_i2c_list{ u16 sb_ven; u16 sb_dev; u8 sb_ver; u8 base_access; }; /* send a debug character to the i2c port */ static void debug_i2c(char data) { static int FIXUP_CODE_SEG_LOCATION i2c_amd_iobase = 0; static int FIXUP_CODE_SEG_LOCATION i2c_inited = 0; static const FIXUP_CODE_SEG_LOCATION struct amd_i2c_list amd_smbus_table[] = { { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, 0x39, 2 }, /* ATI/AMD SB700 base in pci space */ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, 0x42, 1 }, /* ATI/AMD SB800 base in pmreg */ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SB900_SM, 0x14, 1 }, /* ATI/AMD SB900 base in pmreg */ }; volatile u16 rd_vendor, rd_device; volatile u8 rd_ver, base_access; int i; u32 x; if (!CONFIG_DEBUG_I2C) return; /* check to see if we already tried init and it failed */ if (i2c_inited && !i2c_amd_iobase) return; /* check to see if the base address has been initialized */ if (!i2c_inited) { i2c_inited=1; /* check for the AMD/ATI southbridges */ rd_vendor = pci_config_readw(0xA0, 0x00); rd_device = pci_config_readw(0xA0, 0x02); rd_ver = pci_config_readb(0xA0, 0x08); base_access=0; for (i=0;i < sizeof(amd_smbus_table)/sizeof(amd_smbus_table[0]);++i) { if ((amd_smbus_table[i].sb_ven==rd_vendor) && (amd_smbus_table[i].sb_dev==rd_device) && (amd_smbus_table[i].sb_ver==rd_ver)) { base_access = amd_smbus_table[i].base_access; break; } } switch (base_access) { case 1: /* check the PM regs for the SM bus base address */ outb (0x2D, 0xCD6); i2c_amd_iobase = inb(0xCD7)<<8; outb (0x2C, 0xCD6); i2c_amd_iobase |= inb(0xCD7); if ((i2c_amd_iobase!=0) && ((i2c_amd_iobase&0x01)==0x01)) { /* Found a SBx00 base address in PM reg space */ i2c_amd_iobase &= 0xffe0; } else { /* can not find a valid base address */ i2c_amd_iobase = 0; } break; case 2: /* check PCI config space for SM bus base address */ x = pci_config_readl(0xA0, 0x90); if ((x!=0) && ((x&0x01)==0x01)) { /* Found a SBx00 base address in PCI cfg space */ i2c_amd_iobase = (int)(x & 0xffe0); } else { /* can not find a valid base address */ i2c_amd_iobase = 0; } break; default: i2c_amd_iobase = 0; break; } /* add checks for other vendors SMBUS controllers here */ } if (i2c_amd_iobase) { /* this sequence will send out addr/data on the AMD SBx00 smbus */ int timeout=DEBUG_TIMEOUT; /* check to see if the h/w is idle */ do { if (!timeout--) return; // Ran out of time. } while ((inb(i2c_amd_iobase) & 0x01)!=0x00); outb (0xFF, i2c_amd_iobase + 0); // clear error status outb (0x1F, i2c_amd_iobase + 1); // clear error status outb (data, i2c_amd_iobase + 3); // tx index outb (CONFIG_DEBUG_I2C_DEVICE_ADDR, i2c_amd_iobase + 4); // slave address and write bit outb (0x44, i2c_amd_iobase + 2); // command it to go /* check to see if the h/w is done */ do { if (!timeout--) return; // Ran out of time. } while ((inb(i2c_amd_iobase) & 0x01)!=0x00); } } // Write a character to debug port(s). static void putc_debug(struct putcinfo *action, char c) { if (! CONFIG_DEBUG_LEVEL) return; if (CONFIG_DEBUG_IO) // Send character to debug port. outb(c, GET_GLOBAL(DebugOutputPort)); if (CONFIG_DEBUG_I2C) debug_i2c(c); if (c == '\n') debug_serial('\r'); debug_serial(c); }

1 1

[PATCH] add F11 shortcut for network boot
by Paolo Bonzini 17 Oct '12

17 Oct '12

This patch adds a shortcut for network boot, similar to what is present on bare-metal machines. F11 will prioritize BCV/BEV entries over all the other items of the boot list. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- src/boot.c | 89 ++++++++++++++++++++++++++++++++++++++------------------------ 1 file modificato, 55 inserzioni(+), 34 rimozioni(-) diff --git a/src/boot.c b/src/boot.c index 3ca7960..9977c7d 100644 --- a/src/boot.c +++ b/src/boot.c @@ -400,54 +400,75 @@ interactive_bootmenu(void) while (get_keystroke(0) >= 0) ; - printf("Press F12 for boot menu.\n\n"); + wait_threads(); + struct bootentry_s *pos; + for (pos = BootList; pos; pos = pos->next) { + if (pos->type > IPL_TYPE_CBFS) + break; + } + + printf("Press %sF12 for boot menu.\n\n" + , pos ? "F11 for network boot, or " : ""); 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) + if (scan_code != 0x86 && (scan_code != 0x85 || !pos)) /* not F12 */ return; while (get_keystroke(0) >= 0) ; - printf("Select boot device:\n\n"); - wait_threads(); + if (scan_code == 0x85) { + // Prioritize BEV/BCV entries + struct bootentry_s **pprev = &BootList, **pprev_new = &BootList; + while ((pos = *pprev) != NULL) { + if (pos->type > IPL_TYPE_CBFS) { + *pprev = pos->next; + pos->next = *pprev_new; + *pprev_new = pos; + pos->priority = 0; + pprev_new = &pos->next; + } else { + pprev = &pos->next; + } + } + } else { + // Show menu items + printf("Select boot device:\n\n"); + + int maxmenu = 0; + for (pos = BootList; pos; pos = pos->next) { + char desc[60]; + maxmenu++; + printf("%d. %s\n", maxmenu + , strtcpy(desc, pos->description, ARRAY_SIZE(desc))); + } - // Show menu items - struct bootentry_s *pos = BootList; - int maxmenu = 0; - while (pos) { - char desc[60]; - maxmenu++; - printf("%d. %s\n", maxmenu - , strtcpy(desc, pos->description, ARRAY_SIZE(desc))); - pos = pos->next; - } + // Get key press + for (;;) { + scan_code = get_keystroke(1000); + if (scan_code >= 1 && scan_code <= maxmenu+1) + break; + } + printf("\n"); + if (scan_code == 0x01) + // ESC + return; - // Get key press - for (;;) { - scan_code = get_keystroke(1000); - if (scan_code >= 1 && scan_code <= maxmenu+1) - break; + // Find entry and make top priority. + int choice = scan_code - 1; + struct bootentry_s **pprev = &BootList; + while (--choice) + pprev = &(*pprev)->next; + pos = *pprev; + *pprev = pos->next; + pos->next = BootList; + BootList = pos; + pos->priority = 0; } - printf("\n"); - if (scan_code == 0x01) - // ESC - return; - - // Find entry and make top priority. - int choice = scan_code - 1; - struct bootentry_s **pprev = &BootList; - while (--choice) - pprev = &(*pprev)->next; - pos = *pprev; - *pprev = pos->next; - pos->next = BootList; - BootList = pos; - pos->priority = 0; } // BEV (Boot Execution Vector) list -- 1.7.12.1

2 2

Re: [SeaBIOS] great things are coming your way :-)
by ron minnich 17 Oct '12

17 Oct '12

I don't even know what to say :-) Cloning SeaBIOS from Git Cloning into '/root/coreboot.new/build/seabios'... remote: Counting objects: 8297, done remote: Finding sources: 100% (8297/8297) remote: Total 8297 (delta 6606), reused 8297 (delta 6606) Receiving objects: 100% (8297/8297), 1.93 MiB | 225 KiB/s, done. Resolving deltas: 100% (6606/6606), done. Fetching new commits from the SeaBIOS git repo Checking out SeaBIOS revision 51755c3b5ed9dcdfdef8cee56631d68642bde416 Already on 'master' fatal: reference is not a tree: 51755c3b5ed9dcdfdef8cee56631d68642bde416 make[1]: *** [checkout] Error 128 make: *** [seabios] Error 2

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS October 2012