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
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
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
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
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
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
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
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
