SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

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

Re: [SeaBIOS] [RFC PATCH v3 06/19] Implement "-dimm" command line option
by Vasilis Liaskovitis 17 Oct '12

17 Oct '12

On Sat, Oct 13, 2012 at 08:57:19AM +0000, Blue Swirl wrote: > On Tue, Oct 9, 2012 at 5:04 PM, Vasilis Liaskovitis > <vasilis.liaskovitis(a)profitbricks.com> wrote: > >> snip > >> Maybe even the dimmbus device shouldn't exist by itself after all, or > >> it should be pretty much invisible to users. On real HW, the memory > >> controller or south bridge handles the memory. For i440fx, it's part > >> of the same chipset. So I think we should just add qdev properties to > >> i440fx to specify the sizes, nodes etc. Then i440fx should create the > >> dimmbus device unconditionally using the properties. The default > >> properties should create a sane configuration, otherwise -global > >> i440fx.dimm_size=512M etc. could be used. Then the bus would be > >> populated as before or with device_add. > > > > hmm the problem with using only i440fx properties, is that size/nodes look > > dimm specific to me, not chipset-memcontroller specific. Unless we only allow > > uniform size dimms. Is it possible to have a dynamic list of sizes/nodes pairs as > > properties of a qdev device? > > 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? 2) model and document 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) 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) 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? thanks, - Vasilis

1 0

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

17 Oct '12

On Tue, Oct 16, 2012 at 04:11:08PM +0200, Christian Gmeiner wrote: > 2012/10/15 Kevin O'Connor <kevin(a)koconnor.net>: > > On Sun, Oct 14, 2012 at 07:48:00PM +0000, Christian Gmeiner wrote: > >> On 11 Oct 2012 16:42, "Christian Gmeiner" <christian.gmeiner(a)gmail.com> > >> wrote: > >> > 2012/10/11 Christian Gmeiner <christian.gmeiner(a)gmail.com>: > >> > > 2012/10/11 Kevin O'Connor <kevin(a)koconnor.net>: > >> > >> On Tue, Oct 09, 2012 at 02:31:05PM +0200, Christian Gmeiner wrote: > >> > >>> 2012/10/9 Kevin O'Connor <kevin(a)koconnor.net>: > >> > >>> > On Mon, Oct 08, 2012 at 02:14:03PM +0200, Christian Gmeiner wrote: > >> > >>> >> HI all > >> > >>> >> > >> > >>> >> I am running into some usb problems with coreboot & seabios: > >> > >>> > Can you set the debug level to 8 and post the whole log? Also, for > >> > >>> > timeout issues, having timestamps (via tools/readserial.py tool) > >> > >>> > sometimes helps. > > [...] > >> Kevin do you have an idea what could be wrong? > > > > I haven't had a chance to take a look at it. Something odd is going > > on, as it appears the transfer that's failing isn't even being > > started. I'll see if I can take a look this week. > > > > -Kevin > > He Kevin, > > 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. -Kevin

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS