SeaBIOS October 2012

seabios@seabios.org

27 participants
89 discussions

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

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

16 Oct '12

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

2 1

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

16 Oct '12

ron minnich wrote: > next problem: If the seabios build fails, and you do a make again, > it fails with this kind of error > > CC cbfs/fallback/coreboot_ram.debug > OBJCOPY cbfs/fallback/coreboot_ram.elf > Checking out SeaBIOS revision 385a7d0dec28841a05531cba96c62138c3959fef > error: Your local changes to the following files would be overwritten > by checkout: > src/acpi-dsdt.hex > Please, commit your changes or stash them before you can switch branches. > Aborting > fatal: A branch named 'coreboot' already exists. > make[1]: *** [checkout] Error 128 > make: *** [seabios] Error 2 I've seen this happen. The coreboot Makefile stuff that builds SeaBIOS assumes that there are never uncommitted changes in the SeaBIOS directory, and you get the above error when there are. It is easy to forcefully overwrite any uncommitted changes in the SeaBIOS build directory, but I am not sure if we want to do that. I would very much appreciate an explanation why the src/acpi-dsdt.hex file gets modified as part of the build. It is in the src/ directory, but .hex does not suggest that it is in a source format? It's confusing why it has been added to the repo if it is not a source file. Can someone explain, so that we can fix the build commands? Thanks! //Peter

3 6

Re: [SeaBIOS] great things are coming your way :-)
by Kevin O'Connor 16 Oct '12

16 Oct '12

On Mon, Oct 15, 2012 at 06:53:16AM -0700, ron minnich wrote: > In the event handler your have returns, which are invalid in an event > handler. Every single return now gets an error. Must have been ignored > before? > > See, e.g., acp-dsdt.dsl.i, at the end. (the _GPE block). Hrmm - I put together a patch for this, but it looks like I never committed it. I'll resend. -Kevin

1 0

Git over http
by Christian Gmeiner 15 Oct '12

15 Oct '12

Hi all At the moment seabios is only available via git clone git://git.seabios.org/seabios.git seabios It would be really cool if it would be also accessible via git clone http://git.seabios.org/seabios.git seabios For build-servers etc. behind a firewall. thanks --- Christian Gmeiner, MSc

1 0

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

15 Oct '12

ron minnich wrote: > we're going a tutorial at CISL here in buenos aires tomorrow, > so would be very cool if we can fix this before then :-) It is simple to work around the modified src/acpi-dsdt.hex error, but I don't know if blindly overwriting changed files including whatever the user has done is really sane. I need to know why the file is being modified during SeaBIOS build. I tend to think that it should just be removed from the SeaBIOS repository, then the error goes away, and users' modifications will not silently be deleted by building coreboot. //Peter

1 0

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

15 Oct '12

Thanks Idwer, I completely forgot the Python 2 dependency ... ron

1 0

Re: [SeaBIOS] great things are coming your way :-)
by Idwer Vollering 15 Oct '12

15 Oct '12

2012/10/15 ron minnich <rminnich(a)gmail.com>: > finally, on the master branch, there are python problems. I've stopped > using Python; did the way prints work change? > > Compilation complete. 0 Errors, 31 Warnings, 0 Remarks, 3 Optimizations > Compiling whole program /root/coreboot/build/seabios/out/ccode32flat.o > Compiling whole program /root/coreboot/build/seabios/out/code32seg.o > Compiling whole program /root/coreboot/build/seabios/out/ccode16.o > Compiling to assembler /root/coreboot/build/seabios/out/asm-offsets.s > Generating offset file /root/coreboot/build/seabios/out/asm-offsets.h > Compiling (16bit) /root/coreboot/build/seabios/out/romlayout.o > Building ld scripts > Version: rel-1.7.0-91-g7a39e72-20121015_065847-chromix > File "./tools/layoutrom.py", line 76 > print "Error: Fixed section %s has non-zero alignment (%d)" % ( tools/layoutrom.py (and possibly tools/*.py are) is assuming that python2 is installed. > > > ron > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios

1 0

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

15 Oct '12

finally, on the master branch, there are python problems. I've stopped using Python; did the way prints work change? Compilation complete. 0 Errors, 31 Warnings, 0 Remarks, 3 Optimizations Compiling whole program /root/coreboot/build/seabios/out/ccode32flat.o Compiling whole program /root/coreboot/build/seabios/out/code32seg.o Compiling whole program /root/coreboot/build/seabios/out/ccode16.o Compiling to assembler /root/coreboot/build/seabios/out/asm-offsets.s Generating offset file /root/coreboot/build/seabios/out/asm-offsets.h Compiling (16bit) /root/coreboot/build/seabios/out/romlayout.o Building ld scripts Version: rel-1.7.0-91-g7a39e72-20121015_065847-chromix File "./tools/layoutrom.py", line 76 print "Error: Fixed section %s has non-zero alignment (%d)" % ( ron

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