[coreboot] This change is for tidying up some unfinished business in the device code.
This is the beginning of a set of needed changes to get the geode
running. Comments welcome.
I'll hold off on further patches until people get a look at this and
see if it is ok.
Thanks!
ron
This change is for tidying up some unfinished business in the device code.
I just uncovered this problem while trying to get the lx going.
The symptom was that the northbridge ops were never getting run,
in particular the phase 2 ops for the geodelx were not running. The
reason was that the ops struct member for the device was not set.
How is the ops struct member set?
Currently, the ops vector for a static device (i.e. a device created from the
dts) has to be set by hand, as in mainboard/emulation/qemu-x86/dts:
domain0 {
/config/("northbridge/intel/i440bxemulation");
ops = "i440bxemulation_pcidomainops";
This requirement is ridiculous (it's my fault). If we know the part,
and have the dts, we should not have to explicitly name the ops. In fact the
constructors array, defined at the end of the various device files, makes
searching for an ops struct for a dynamic device automatic. We should
support this automatic behavior for static devices too.
Given the function find_constructor
in device/device.c, why don't we just use that? The problem is that we did
not set up the device struct to include a device id, just a device path, and
find_constructor requires a device_id -- which makes sense, I hope,
as the path is its pci path (e.g. 0:1.0) and the constructors are defined by the
device id (i.e. it is the same constructor for a given part, no matter how many
of the part we have).
So, as a start to fixing this limitation (this is going to take several patches),
I've done the following:
1. add a struct device_id to the device struct.
2. extended the dev_init code in device/device.c -- this is the first function
called from lib/stage2.c -- to find a constructor for the dev->id and, if
found, set dev->ops to it.
Result: for static devices with the id set, the ops pointer will be set
automatically. Coreboot builds fine with this change.
The next change will be to add dtc commands to set ids.
Currently, we have commands like pcipath, pcidomain, etc.;
the new commands will look like pciid, domainid, etc. Once we have these
commands, we will have made it possible to set ops automatically. We
can just set the ids in the device dts file, and users will never have to
see any of this complication.
The final change will be a bit more complicated. Right now, if you look in,
e.g., northbridge/amd/geodelx/dts, you'll see that we have one dts, but
the northbridge plays three roles. We can't easily contain those three
roles in one dts (I am open to suggestions showing I am wrong).
I am going to propose that we have more than one dts file
in a directory, so instead of
northbridge/amd/geodelx/dts
we would have
northbridge/amd/geodelx/dtsdomain
northbridge/amd/geodelx/dtsapic
northbridge/amd/geodelx/dtspci
so that we could set the variables for each of these individual components.
There is no need to split geodelx.c into three .c files, however.
Finally, I will be removing the archaic vendor and device unsigned's from
the device struct in future, but as I say, I am trying to stage these changes
to keep them understandable.
Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
Index: include/device/device.h
===
--- include/device/device.h (revision 554)
+++ include/device/device.h (working copy)
@@ -185,6 +185,7 @@
struct device * next; /* chain of all devices */
struct device_path path;
+ struct device_id id;
char dtsname[MAX_DTSNAME_SIZE]; /* the name from the dts */
unsigned vendor;
unsigned device;
Index: device/device.c
===
--- device/device.c (revision 554)
+++ device/device.c (working copy)
@@ -88,21 +88,6 @@
}
/**
- * Initialization tasks for the device tree code.
- *
- * At present, merely sets up last_dev_p, which used to be done by
- * Fucking Magic (FM) in the config tool.
- */
-void dev_init(void)
-{
- struct device *dev;
-
- for (dev = all_devices; dev; dev = dev->next) {
- last_dev_p = &dev->next;
- }
-}
-
-/**
* The default constructor, which simply sets the ops pointer.
*
* Initialize device->ops of a newly allocated device structure.
@@ -149,6 +134,30 @@
}
/**
+ * Initialization tasks for the device tree code.
+ *
+ * Sets up last_dev_p, which used to be done by
+ * Fucking Magic (FM) in the config tool. Also, for each of the
+ * devices, tries to find the constructor, and from there, the ops,
+ * for the device.
+ */
+void dev_init(void)
+{
+ struct device *dev;
+ struct constructor *c;
+
+ for (dev = all_devices; dev; dev = dev->next) {
+ c = find_constructor(&dev->id);
+ /* note the difference from the constructor function below.
+ * we are not allocating the device here, just setting the ops.
Re: [coreboot] [LinuxBIOS] PATCH: lx car that returns from disable_car
On Jan 16, 2008 5:26 PM, Carl-Daniel Hailfinger > Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]> > > Please try to be more verbose in your changelog. Committed revision 555. I tried for a better message. It still did not make it go better :-( Looking at it now. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r555 - in coreboot-v3: mainboard/pcengines/alix1c northbridge/amd/geodelx
Author: rminnich
Date: 2008-01-17 06:37:41 +0100 (Thu, 17 Jan 2008)
New Revision: 555
Added:
coreboot-v3/northbridge/amd/geodelx/dts
Modified:
coreboot-v3/mainboard/pcengines/alix1c/dts
Log:
This change adds a dts file for the amd geodelx northbridge. The
northbridge has several constructors, so it is required, if these
constructors
are to be compiled in to the running image, that a dts be provided.
To use the dts, one must add a /config/ line to the components
that use it, hence the change to the mainboard dts .
This change does not produce a working bios as far as I can tell.
But it is still important to have it in.
Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Modified: coreboot-v3/mainboard/pcengines/alix1c/dts
===
--- coreboot-v3/mainboard/pcengines/alix1c/dts 2008-01-16 16:18:32 UTC (rev
554)
+++ coreboot-v3/mainboard/pcengines/alix1c/dts 2008-01-17 05:37:41 UTC (rev
555)
@@ -26,6 +26,7 @@
enabled;
};
domain0 {
+ /config/("northbridge/amd/geodelx");
enabled;
pcidomain = "0";
device0,0 {
Added: coreboot-v3/northbridge/amd/geodelx/dts
===
--- coreboot-v3/northbridge/amd/geodelx/dts (rev 0)
+++ coreboot-v3/northbridge/amd/geodelx/dts 2008-01-17 05:37:41 UTC (rev
555)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+{
+constructor = "geodelx_north_constructors";
+};
+
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r555 - in coreboot-v3: mainboard/pcengines/alix1c northbridge/amd/geodelx
Author: rminnich
Date: 2008-01-17 06:37:41 +0100 (Thu, 17 Jan 2008)
New Revision: 555
Added:
coreboot-v3/northbridge/amd/geodelx/dts
Modified:
coreboot-v3/mainboard/pcengines/alix1c/dts
Log:
This change adds a dts file for the amd geodelx northbridge. The
northbridge has several constructors, so it is required, if these
constructors
are to be compiled in to the running image, that a dts be provided.
To use the dts, one must add a /config/ line to the components
that use it, hence the change to the mainboard dts .
This change does not produce a working bios as far as I can tell.
But it is still important to have it in.
Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Modified: coreboot-v3/mainboard/pcengines/alix1c/dts
===
--- coreboot-v3/mainboard/pcengines/alix1c/dts 2008-01-16 16:18:32 UTC (rev
554)
+++ coreboot-v3/mainboard/pcengines/alix1c/dts 2008-01-17 05:37:41 UTC (rev
555)
@@ -26,6 +26,7 @@
enabled;
};
domain0 {
+ /config/("northbridge/amd/geodelx");
enabled;
pcidomain = "0";
device0,0 {
Added: coreboot-v3/northbridge/amd/geodelx/dts
===
--- coreboot-v3/northbridge/amd/geodelx/dts (rev 0)
+++ coreboot-v3/northbridge/amd/geodelx/dts 2008-01-17 05:37:41 UTC (rev
555)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+{
+constructor = "geodelx_north_constructors";
+};
+
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] Welcome to coreboot.
On Jan 14, 2008 7:40 AM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > > There is one aspect of the new name that was not discussed yet if I > remember correctly: Capitalization. > It seems "coreboot" is all lowercase. While I agree that it looks nice, > I remember the trouble "openSUSE" had when they insisted on their > particular capitalization, especially in contiguous texts with > "openSUSE" at the beginning of some sentences. Starting a sentence with > a lowercase word makes most word processors complain loudly. Independent > of that, some media outlets don't care about capitalization of project > names at all. > I do like "coreboot" as it is because that capitalization gives me the > impression of "works behind the scenes". I'm starting to update some of the wiki pages (e.g. the FAQ) to use the new 'coreboot' name and I haven't seen a definite answer about the capitalization question. Is there consensus that the name should be lower-cased in all instances (even at the beginning of a sentence) ? Thanks, -- Robinson -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] svn: switching subversion from LinuxBIOS to coreboot
On Jan 16, 2008 8:24 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > WARNING WARNING WARNING WARNING > If you think you see anything that looks like an error message, STOP > IMMEDIATELY. > ... > Write to the list with any questions before your tree is beyond recovery. > !! Here's a quick and easy way to back up your working copy (assuming it has uncommitted changes in it). Because Subversion stores all of its version-control bits in the .svn subdirectories of a checkout, it's really easy to back up your working copy before trying any commands with which you are not familiar. For example: [EMAIL PROTECTED]:~/src$ ls coreboot-v3 superiotool [EMAIL PROTECTED]:~/src$ cp -r coreboot-v3/ coreboot-v3-BACKUP [EMAIL PROTECTED]:~/src$ ls coreboot-v3 coreboot-v3-BACKUP superiotool (... Now that you have a backup, do all of your hairy work on the coreboot-v3/ directory ...) If you have SVN problems and want to start over, just restore from the backup: [EMAIL PROTECTED]:~/src$ rm -rf coreboot-v3 [EMAIL PROTECTED]:~/src$ cp -r coreboot-v3-BACKUP/ coreboot-v3 [EMAIL PROTECTED]:~/src$ ls coreboot-v3 coreboot-v3-BACKUP superiotool I just did a fresh checkout of the coreboot-v3 tree and it looks like it's only 11 MB, so unless you have a lot of uncommitted source files, it should be relatively fast and simple to backup your working copy whenever you need to. --R -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On Thu, Jan 17, 2008 at 03:24:23AM +0100, Peter Stuge wrote: > On Wed, Jan 16, 2008 at 09:09:43PM -0500, Ward Vandewege wrote: > > > > All right. So how about the Atmel AT45DB321D-SU > > > > > > Unfortunately it has a different pinout than the flash chips > > > we've looked at so far. > > > > Oh, you're right, odd. It would work in a socket I guess, if that > > socket is wired up correctly. Hrm. > > If the SPI commands for reading are the same then yeah, it should > work. Hmm, yeah, that's worth investigating I guess. > > Any other suggestions for large SPI/SOIC-8 chips? > > Macronix MX25L8005M2C-15G Mouser/digikeys/jameco don't have this one. > Winbond W25X16VSSI > Winbond W25X32VSSI > > Problem with Winbond is they really only want to sell large > quantities. I haven't even gotten a quote and delivery time > back from my sales rep on a request I made in November. Weird, yeah, minimum purchase is around $500 for those two - 270 units of the 16Mbit, or 180 units of the 32Mbit chip (this is digikeys, the others don't carry them). Maybe a group buy is in order... Thanks, Ward. -- Ward Vandewege <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On Wed, Jan 16, 2008 at 09:09:43PM -0500, Ward Vandewege wrote: > > > All right. So how about the Atmel AT45DB321D-SU > > > > Unfortunately it has a different pinout than the flash chips > > we've looked at so far. > > Oh, you're right, odd. It would work in a socket I guess, if that > socket is wired up correctly. Hrm. If the SPI commands for reading are the same then yeah, it should work. > Any other suggestions for large SPI/SOIC-8 chips? Macronix MX25L8005M2C-15G Winbond W25X16VSSI Winbond W25X32VSSI Winbond will also make a 64Mbit flash but it didn't have a product number a few months ago. Problem with Winbond is they really only want to sell large quantities. I haven't even gotten a quote and delivery time back from my sales rep on a request I made in November. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On 17.01.2008 02:48, Ward Vandewege wrote: > Hi Ronald, > > On Thu, Jan 17, 2008 at 12:13:48AM +0100, Ronald Hoogenboom wrote: > >> Problem1 (for reading) is solved by NOT using the mmap method for >> reading the flash contents, but using outb() for sending the flash read >> commands (using a specific 25vf016 read function). Also the normal read >> command is only supported up to 25MHz by this chip, so I cannot use the >> 33MHz speed as used normally by spi.c. There is also a 'high speed' read >> command (0x0b), which inserts an extra dummy byte between address and >> data, but as the 8716 only allows max. 3 bytes read per io transfer, the >> gain (3 bytes per io transfer @ 16MHz versus 2 bytes per io transfer @ >> 33MHz) is negligible. >> > > Can you elaborate a bit about that - I see the two read speeds in the > datasheet, but how do you get to 16MHz in that last sentence? > 33 MHz /2 (at least that's how the IT8716F datasheet calls it. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On Thu, Jan 17, 2008 at 03:03:48AM +0100, Peter Stuge wrote: > On Wed, Jan 16, 2008 at 08:57:52PM -0500, Ward Vandewege wrote: > > > English translation: > > > > > > SST25VF016B is not really compatible with the IT8716F superio. > > > > All right. So how about the Atmel AT45DB321D-SU > > Unfortunately it has a different pinout than the flash chips we've > looked at so far. Oh, you're right, odd. It would work in a socket I guess, if that socket is wired up correctly. Hrm. Any other suggestions for large SPI/SOIC-8 chips? Thanks, Ward. -- Ward Vandewege <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On Wed, Jan 16, 2008 at 08:57:52PM -0500, Ward Vandewege wrote: > > English translation: > > > > SST25VF016B is not really compatible with the IT8716F superio. > > All right. So how about the Atmel AT45DB321D-SU Unfortunately it has a different pinout than the flash chips we've looked at so far. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On Thu, Jan 17, 2008 at 02:29:16AM +0100, Peter Stuge wrote: > On Thu, Jan 17, 2008 at 01:24:38AM +0100, Carl-Daniel Hailfinger wrote: > > Please be aware that the M57SLI may read the reset vector and other > > really early stuff at 33 MHz, thereby causing read errors > > (sometimes single bit shifts) which are really hard to find. > > English translation: > > SST25VF016B is not really compatible with the IT8716F superio. All right. So how about the Atmel AT45DB321D-SU, which is a 32Mbit (!) chip that seems to be able to do 33MHz reads in slow mode (and 66MHz in fast mode). Only about $3.66 at Mouser.com, and it's in stock. Here's the datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc3597.pdf Good? Bad? Thanks, Ward. -- Ward Vandewege <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
Hi Ronald, On Thu, Jan 17, 2008 at 12:13:48AM +0100, Ronald Hoogenboom wrote: > Problem1 (for reading) is solved by NOT using the mmap method for > reading the flash contents, but using outb() for sending the flash read > commands (using a specific 25vf016 read function). Also the normal read > command is only supported up to 25MHz by this chip, so I cannot use the > 33MHz speed as used normally by spi.c. There is also a 'high speed' read > command (0x0b), which inserts an extra dummy byte between address and > data, but as the 8716 only allows max. 3 bytes read per io transfer, the > gain (3 bytes per io transfer @ 16MHz versus 2 bytes per io transfer @ > 33MHz) is negligible. Can you elaborate a bit about that - I see the two read speeds in the datasheet, but how do you get to 16MHz in that last sentence? Thanks, Ward. -- Ward Vandewege <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On 17.01.2008 02:29, Peter Stuge wrote: > On Thu, Jan 17, 2008 at 01:24:38AM +0100, Carl-Daniel Hailfinger wrote: > >> Please be aware that the M57SLI may read the reset vector and other >> really early stuff at 33 MHz, thereby causing read errors >> (sometimes single bit shifts) which are really hard to find. >> > > English translation: > ;-) > SST25VF016B is not really compatible with the IT8716F superio. > > About right? > Mostly. If the M57SLI uses the IT8716F in 33 MHz mode at startup, the SST25VF016B is indeed incompatible. If IT8716F startup happens at 16 MHz, it will work. I have no idea about the real behaviour of the hardware. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On Thu, Jan 17, 2008 at 01:24:38AM +0100, Carl-Daniel Hailfinger wrote: > Please be aware that the M57SLI may read the reset vector and other > really early stuff at 33 MHz, thereby causing read errors > (sometimes single bit shifts) which are really hard to find. English translation: SST25VF016B is not really compatible with the IT8716F superio. About right? //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] PATCH: lx car that returns from disable_car
On 17.01.2008 02:18, ron minnich wrote: > On Jan 11, 2008 4:01 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > > >> Ron, >> >> I think I am up to the same point you are. It looks like there is a >> problem in the device scanning. >> >> void dev_phase2(void) should call geodelx_pci_domain_phase2() for the >> southbridge device. >> >> Here is the output. Is this the correct order? It seems strange. >> >> Phase 2: Early setup... >> dev_phase2: dev root: >> dev_phase2: dev cpus: >> dev_phase2: dev device0_0: >> dev_phase2: dev southbridge: >> dev_phase2: dev domain0: >> Phase 2: Done. >> > > I just realized there was no dts in northbridge/amd/geodelx ... this > is a possible problem. > > Add a dts for the geode northbridge. > > Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]> > If it works or at least improves the situation, the patch is Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]> Please try to be more verbose in your changelog. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] svn: switching subversion from LinuxBIOS to coreboot
DARK RED BOLD ATOMIC BOMB WARNING! (OK, it's not that bad, but... see below.) On 17.01.2008 01:06, Carl-Daniel Hailfinger wrote: > As you may have noticed, svn up doesn't work anymore for old trees. svn > switch (with or without --relocate) will fail with an error. > You are stuck. But you wanted to keep that tree. Desparation fills your > mind. And then you google for help and all you see is "subversion can't > do such a switch". Before you trash your trees and bang your head > against the wall: > > Use my trick to beat svn into cooperation. Sit back and relax. > WARNING WARNING WARNING WARNING If you think you see anything that looks like an error message, STOP IMMEDIATELY. DO NOT try to be clever and fix up the commands yourself. It will HOSE your tree. The result of the first command should look like a normal "svn up" message. The second command should not produce any output at all. Write to the list with any questions before your tree is beyond recovery. !! > Enter a v3 tree. Type the two commands below and be happy. > > svn switch svn://linuxbios.org/repository/coreboot-v3 . > svn switch --relocate svn://linuxbios.org/repository/coreboot-v3 > svn://coreboot.org/repository/coreboot-v3 . > > > Enter a v2 tree. Type the two commands below and be happy. > > svn switch svn://linuxbios.org/repos/trunk/coreboot-v2 . > svn switch --relocate svn://linuxbios.org/repos/trunk/coreboot-v2 > svn://coreboot.org/repos/trunk/coreboot-v2 . > Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [LinuxBIOS] PATCH: lx car that returns from disable_car
On Jan 11, 2008 4:01 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> Ron,
>
> I think I am up to the same point you are. It looks like there is a
> problem in the device scanning.
>
> void dev_phase2(void) should call geodelx_pci_domain_phase2() for the
> southbridge device.
>
> Here is the output. Is this the correct order? It seems strange.
>
> Phase 2: Early setup...
> dev_phase2: dev root:
> dev_phase2: dev cpus:
> dev_phase2: dev device0_0:
> dev_phase2: dev southbridge:
> dev_phase2: dev domain0:
> Phase 2: Done.
>
I just realized there was no dts in northbridge/amd/geodelx ... this
is a possible problem.
patch attached.
ron
Add a dts for the geode northbridge.
Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
Index: mainboard/pcengines/alix1c/dts
===
--- mainboard/pcengines/alix1c/dts (revision 554)
+++ mainboard/pcengines/alix1c/dts (working copy)
@@ -26,6 +26,7 @@
enabled;
};
domain0 {
+ /config/("northbridge/amd/geodelx");
enabled;
pcidomain = "0";
device0,0 {
Index: northbridge/amd/geodelx/dts
===
--- northbridge/amd/geodelx/dts (revision 0)
+++ northbridge/amd/geodelx/dts (revision 0)
@@ -0,0 +1,24 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2008 Ronald G. Minnich <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+{
+constructor = "geodelx_north_constructors";
+};
+
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] svn: switching subversion from LinuxBIOS to coreboot
On 17.01.2008 01:50, ron minnich wrote: > On Jan 16, 2008 4:06 PM, Carl-Daniel Hailfinger > <[EMAIL PROTECTED]> wrote: > > >> Enter a v3 tree. Type the two commands below and be happy. >> >> svn switch svn://linuxbios.org/repository/coreboot-v3 . >> > > svn switch svn://[EMAIL PROTECTED]/repository/ . > svn: Won't delete locally modified directory '.' > svn: Left locally modified or unversioned files > > So that looked good, but ... > That looked really bad. It should have given you a message similar to the usual message of "svn up" in a working tree. The problem was that you removed the trailing "coreboot-v3" part from the URL and this caused svn to completely hose your tree. > svn switch --relocate svn://linuxbios.org/repository/coreboot-v3 > svn://coreboot.org/repository/coreboot-v3 . > > > I think this second was my mistake: I got this: > [EMAIL PROTECTED] LinuxBIOSv3]$ svn up > Dsouthbridge > [...] > I'd say the repo is now really broken. In the future, I'll add an explicit "if you think you see anything that looks like an error message, STOP IMMEDIATELY" to any mails with subversion commands. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Add some Winbond SPI chips to flashrom (patch).
Hi, On Wed, Jan 16, 2008 at 11:03:25PM +0100, Ronald Hoogenboom wrote: > On my m57sli-rev.2 board, there is a winbond 25X40 SPI flash bios chip, > which flashrom didn't have support for, so I added it (and the > relatives). Patch below: Please add a Signed-off-by line to all patches you submit, otherwise we cannot commit them. See http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] svn: switching subversion from LinuxBIOS to coreboot
On Jan 16, 2008 4:06 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Enter a v3 tree. Type the two commands below and be happy. > > svn switch svn://linuxbios.org/repository/coreboot-v3 . svn switch svn://[EMAIL PROTECTED]/repository/ . svn: Won't delete locally modified directory '.' svn: Left locally modified or unversioned files So that looked good, but ... svn switch --relocate svn://linuxbios.org/repository/coreboot-v3 svn://coreboot.org/repository/coreboot-v3 . I think this second was my mistake: I got this: [EMAIL PROTECTED] LinuxBIOSv3]$ svn up Dsouthbridge DKconfig Dinclude Dsuperio Dmainboard DREADME Ddevice DHACKING Ddoc DRules.make Dlib Dnorthbridge DCOPYING Darch DMakefile Dutil Acoreboot-v3 Yep, it did a full checkout of coreboot-v3. And then said: svn: Directory 'southbridge/.svn' containing working copy admin area is missing Hmm. [EMAIL PROTECTED] coreboot-v3]$ ls -l southbridge/.svn/ total 24 -r--r--r-- 1 rminnich rminnich 267 2008-01-16 16:46 entries -r--r--r-- 1 rminnich rminnich2 2008-01-16 16:46 format drwxrwxr-x 2 rminnich rminnich 4096 2008-01-16 16:46 prop-base drwxrwxr-x 2 rminnich rminnich 4096 2008-01-16 16:46 props drwxrwxr-x 2 rminnich rminnich 4096 2008-01-16 16:46 text-base drwxrwxr-x 5 rminnich rminnich 4096 2008-01-16 16:46 tmp Oh well, I have a coreboot v3 now :-) ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] svn: switching subversion from LinuxBIOS to coreboot
On 17.01.2008 01:32, ron minnich wrote: > On Jan 16, 2008 4:06 PM, Carl-Daniel Hailfinger > <[EMAIL PROTECTED]> wrote: > > >> Enter a v3 tree. Type the two commands below and be happy. >> >> svn switch svn://linuxbios.org/repository/coreboot-v3 . >> > > uh oh. What's this mean? > svn switch svn://linuxbios.org/repository/coreboot-v3 . > svn: 'svn://linuxbios.org/repository/coreboot-v3' > is not the same repository as > 'svn://[EMAIL PROTECTED]/repository' > Subversion is being unfriendly. You used a slightly different repository URL so it complains. Try this: svn switch svn://[EMAIL PROTECTED]/repository/coreboot-v3 . Basically, the first "svn switch" has to conserve the user and domain part. As long as Stefan keeps linuxbios.org, openbios.org and coreboot.org pointing to the same IP, using the command above is sufficient and you don't need the second svn command (with --relocate) at all. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] svn: switching subversion from LinuxBIOS to coreboot
On Jan 16, 2008 4:06 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Enter a v3 tree. Type the two commands below and be happy. > > svn switch svn://linuxbios.org/repository/coreboot-v3 . uh oh. What's this mean? svn switch svn://linuxbios.org/repository/coreboot-v3 . svn: 'svn://linuxbios.org/repository/coreboot-v3' is not the same repository as 'svn://[EMAIL PROTECTED]/repository' ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On 17.01.2008 00:13, Ronald Hoogenboom wrote: > I mounted a SST25VF016B 2MByte flash chip on the second SPI bios > landpattern on the m57sli mobo (as per the m57sli tutorial). > There as some problems with that[...] > > Problem1 (for reading) is solved by NOT using the mmap method for > reading the flash contents, but using outb() for sending the flash read > commands (using a specific 25vf016 read function). Also the normal read > command is only supported up to 25MHz by this chip, so I cannot use the > 33MHz speed as used normally by spi.c. There is also a 'high speed' read > command (0x0b), which inserts an extra dummy byte between address and > data, but as the 8716 only allows max. 3 bytes read per io transfer, the > gain (3 bytes per io transfer @ 16MHz versus 2 bytes per io transfer @ > 33MHz) is negligible. > Please be aware that the M57SLI may read the reset vector and other really early stuff at 33 MHz, thereby causing read errors (sometimes single bit shifts) which are really hard to find. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
On 17.01.2008 01:05, Ward Vandewege wrote: > Hi Ronald and Carl-Daniel, > > Great work - I want to use larger SPI chips on this board myself. > > On Thu, Jan 17, 2008 at 12:56:08AM +0100, Carl-Daniel Hailfinger wrote: > >> I see you invested a lot of time to work around the deficiencies of the >> IT8716F SPI translation function. You even did it the way I described >> the process a few weeks ago (but I had no time to implement it). >> >> >>> Problem1 and Problem2 have impact on the useability of flashrom, which I >>> have sort-of solved (patch below). Problem1 also has impact on the >>> elfboot.c and rom-stream.c in coreboot (linuxbios), which I'm still >>> investigating (suggestions welcome!). >>> >>> >> I'd like to not handle this problem at all in coreboot v3. >> > > What do you propose for v3? > Keep v3 clean, simply refuse to support such horrible interfaces in v3. Especially the lar walk code would explode to about twice the size if we wanted to support flash parts that can not be memmapped completely. There are workarounds for some of that stuff, but I'll keep them secret until someone manages to actually port a board with IT8176F SPI translation to v3. I hope that will never happen. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
Hi Ronald and Carl-Daniel, Great work - I want to use larger SPI chips on this board myself. On Thu, Jan 17, 2008 at 12:56:08AM +0100, Carl-Daniel Hailfinger wrote: > I see you invested a lot of time to work around the deficiencies of the > IT8716F SPI translation function. You even did it the way I described > the process a few weeks ago (but I had no time to implement it). > > > Problem1 and Problem2 have impact on the useability of flashrom, which I > > have sort-of solved (patch below). Problem1 also has impact on the > > elfboot.c and rom-stream.c in coreboot (linuxbios), which I'm still > > investigating (suggestions welcome!). > > > > I'd like to not handle this problem at all in coreboot v3. What do you propose for v3? Thanks, Ward. -- Ward Vandewege <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] svn: switching subversion from LinuxBIOS to coreboot
As you may have noticed, svn up doesn't work anymore for old trees. svn switch (with or without --relocate) will fail with an error. You are stuck. But you wanted to keep that tree. Desparation fills your mind. And then you google for help and all you see is "subversion can't do such a switch". Before you trash your trees and bang your head against the wall: Use my trick to beat svn into cooperation. Sit back and relax. Enter a v3 tree. Type the two commands below and be happy. svn switch svn://linuxbios.org/repository/coreboot-v3 . svn switch --relocate svn://linuxbios.org/repository/coreboot-v3 svn://coreboot.org/repository/coreboot-v3 . Enter a v2 tree. Type the two commands below and be happy. svn switch svn://linuxbios.org/repos/trunk/coreboot-v2 . svn switch --relocate svn://linuxbios.org/repos/trunk/coreboot-v2 svn://coreboot.org/repos/trunk/coreboot-v2 . That's it. Have fun! Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
Hi Ronald,
first of all, welcome to coreboot.
I see you invested a lot of time to work around the deficiencies of the
IT8716F SPI translation function. You even did it the way I described
the process a few weeks ago (but I had no time to implement it).
Please see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
details on patch submission. There are two things that block acceptance
of your patch:
- A "Signed-off-by:" line is missing. Please add one.
- The patch does not apply because Evolution mangled it on your side.
Either fix the configuration or attach the patch as plain text.
On 17.01.2008 00:13, Ronald Hoogenboom wrote:
> I mounted a SST25VF016B 2MByte flash chip on the second SPI bios
> landpattern on the m57sli mobo (as per the m57sli tutorial).
> There as some problems with that, on the one side from the point of the
> LPC memory mapping options of the IT8716F (max. 512KB contiguous) and on
> the other side with the programming method(s) supported by the SST flash
> chip (only the byte-mode programming is compatible with the IT8716).
> Lets call them problem1 and problem2.
>
> The reason why I want the 2MB is that I would like to try direct Linux
> kernel as the payload.
>
Agreed.
> Problem1 and Problem2 have impact on the useability of flashrom, which I
> have sort-of solved (patch below). Problem1 also has impact on the
> elfboot.c and rom-stream.c in coreboot (linuxbios), which I'm still
> investigating (suggestions welcome!).
>
I'd like to not handle this problem at all in coreboot v3. In v2, we can
probably work around this issue by ensuring that all code until RAM is
enabled has to be mapped in the contiguous 512 kByte area (which may
correspond to the first or last 512 kB of the flash chip, nobody really
knows and ITE are not answering my mails.
> Problem1 (for reading) is solved by NOT using the mmap method for
> reading the flash contents, but using outb() for sending the flash read
> commands (using a specific 25vf016 read function). Also the normal read
> command is only supported up to 25MHz by this chip, so I cannot use the
> 33MHz speed as used normally by spi.c. There is also a 'high speed' read
> command (0x0b), which inserts an extra dummy byte between address and
> data, but as the 8716 only allows max. 3 bytes read per io transfer, the
> gain (3 bytes per io transfer @ 16MHz versus 2 bytes per io transfer @
> 33MHz) is negligible.
>
Yes. We have to specify a maximum speed for each SPI chip in
flashchips.c. Suggestions welcome.
> Problem2 (for writing) is solved similarly: The mmap write method cannot
> be used effectively, because the flash chip needs a Write-enable command
> for each Byte-program (no block program concept in byte-program mode).
> The chip has a so-called AAI (auto address increment) programming mode
> instead, but that cannot be used with the 8716 chip, because it needs 6
> byte and 3 byte io transfers, which it doesn't support (bah!). Not using
> the mmap writes also solves the limited LPC memory address window. So,
> there is also a 25vf016 specific write function.
>
The function is probably more specific to IT8716F and chips bigger than
512 kByte. Maybe rename the function and have the IT8716F writing code
switch to you method if the chip is bigger than 512 kB?
> NOTE: there may be some offset because of other changes...
>
> Index: flash.h
> ===
> --- flash.h (revision 3051)
> +++ flash.h (working copy)
> @@ -297,6 +303,8 @@
> void generic_spi_write_disable();
> int generic_spi_chip_erase_c7(struct flashchip *flash);
> int generic_spi_chip_write(struct flashchip *flash, uint8_t *buf);
> +int sst25vf016_spi_chip_write(struct flashchip *flash, uint8_t *buf);
> +int sst25vf016_spi_chip_read(struct flashchip *flash, uint8_t *buf);
>
> /* 82802ab.c */
> int probe_82802ab(struct flashchip *flash);
> Index: flashchips.c
> ===
> --- flashchips.c (revision 3051)
> +++ flashchips.c (working copy)
> @@ -57,7 +57,7 @@
> {"SST25VF040B", SST_ID, SST_25VF040B, 512,256,
> probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write},
> {"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256,
> - probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write},
> + probe_spi, generic_spi_chip_erase_c7,
> sst25vf016_spi_chip_write,
> sst25vf016_spi_chip_read},
> {"SST29EE020A", SST_ID, SST_29EE020A, 256, 128,
>probe_jedec, erase_chip_jedec, write_jedec},
> {"SST28SF040A", SST_ID, SST_28SF040,512, 256,
> Index: spi.c
> ===
> --- spi.c (revision 3051)
> +++ spi.c (working copy)
> @@ -77,6 +77,8 @@
> #define JEDEC_RDSR_BIT_WIP (0x01 << 0)
>
> uint16_t it8716f_flashport = 0;
> +/* use fast 33MHz SP
[coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F).
I mounted a SST25VF016B 2MByte flash chip on the second SPI bios
landpattern on the m57sli mobo (as per the m57sli tutorial).
There as some problems with that, on the one side from the point of the
LPC memory mapping options of the IT8716F (max. 512KB contiguous) and on
the other side with the programming method(s) supported by the SST flash
chip (only the byte-mode programming is compatible with the IT8716).
Lets call them problem1 and problem2.
The reason why I want the 2MB is that I would like to try direct Linux
kernel as the payload.
Problem1 and Problem2 have impact on the useability of flashrom, which I
have sort-of solved (patch below). Problem1 also has impact on the
elfboot.c and rom-stream.c in coreboot (linuxbios), which I'm still
investigating (suggestions welcome!).
Problem1 (for reading) is solved by NOT using the mmap method for
reading the flash contents, but using outb() for sending the flash read
commands (using a specific 25vf016 read function). Also the normal read
command is only supported up to 25MHz by this chip, so I cannot use the
33MHz speed as used normally by spi.c. There is also a 'high speed' read
command (0x0b), which inserts an extra dummy byte between address and
data, but as the 8716 only allows max. 3 bytes read per io transfer, the
gain (3 bytes per io transfer @ 16MHz versus 2 bytes per io transfer @
33MHz) is negligible.
Problem2 (for writing) is solved similarly: The mmap write method cannot
be used effectively, because the flash chip needs a Write-enable command
for each Byte-program (no block program concept in byte-program mode).
The chip has a so-called AAI (auto address increment) programming mode
instead, but that cannot be used with the 8716 chip, because it needs 6
byte and 3 byte io transfers, which it doesn't support (bah!). Not using
the mmap writes also solves the limited LPC memory address window. So,
there is also a 25vf016 specific write function.
NOTE: there may be some offset because of other changes...
Index: flash.h
===
--- flash.h (revision 3051)
+++ flash.h (working copy)
@@ -297,6 +303,8 @@
void generic_spi_write_disable();
int generic_spi_chip_erase_c7(struct flashchip *flash);
int generic_spi_chip_write(struct flashchip *flash, uint8_t *buf);
+int sst25vf016_spi_chip_write(struct flashchip *flash, uint8_t *buf);
+int sst25vf016_spi_chip_read(struct flashchip *flash, uint8_t *buf);
/* 82802ab.c */
int probe_82802ab(struct flashchip *flash);
Index: flashchips.c
===
--- flashchips.c(revision 3051)
+++ flashchips.c(working copy)
@@ -57,7 +57,7 @@
{"SST25VF040B", SST_ID, SST_25VF040B, 512,256,
probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write},
{"SST25VF016B", SST_ID, SST_25VF016B, 2048, 256,
- probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write},
+probe_spi, generic_spi_chip_erase_c7,
sst25vf016_spi_chip_write,
sst25vf016_spi_chip_read},
{"SST29EE020A", SST_ID, SST_29EE020A, 256, 128,
probe_jedec, erase_chip_jedec, write_jedec},
{"SST28SF040A", SST_ID, SST_28SF040,512, 256,
Index: spi.c
===
--- spi.c (revision 3051)
+++ spi.c (working copy)
@@ -77,6 +77,8 @@
#define JEDEC_RDSR_BIT_WIP (0x01 << 0)
uint16_t it8716f_flashport = 0;
+/* use fast 33MHz SPI (<>0) or slow 16MHz (0) */
+int fast_spi=1;
void generic_spi_prettyprint_status_register(struct flashchip *flash);
@@ -203,10 +205,10 @@
__FUNCTION__, writecnt);
return 1;
}
- /* Start IO, 33MHz, readcnt input bytes, writecnt output bytes. Note:
+ /* Start IO, 33MHz (or 16), readcnt input bytes, writecnt output
bytes. Note:
* We can't use writecnt directly, but have to use a strange encoding.
*/
- outb((0x5 << 4) | ((readcnt & 0x3) << 2) | (writeenc), port);
+ outb(((0x4+(fast_spi?1:0)) << 4) | ((readcnt & 0x3) << 2) |
(writeenc), port);
do {
busy = inb(port) & 0x80;
} while (busy);
@@ -314,6 +316,39 @@
"%sset\n", (status & (1 << 0)) ? "" : "not ");
}
+/* Prettyprint the status register. Works for
+ * SST 25VF016
+ */
+void generic_spi_prettyprint_status_register_sst25vf016(uint8_t status)
+{
+ const char *bpt[]={
+ "none",
+ "1FH-1FH",
+ "1EH-1FH",
+ "1CH-1FH",
+ "18H-1FH",
+ "10H-1FH",
+ "all","all"
+ };
+ printf_debug("Chip status register: Block Protect Write Disable "
+ "(BPL) is %sset\n", (status & (1 << 7)) ? "" : "not ");
+ printf_debug("Chip status register: Auto Address
Re: [coreboot] LAR walking madness
On 16.01.2008 23:40, ron minnich wrote: > On Jan 16, 2008 2:12 PM, Carl-Daniel Hailfinger > <[EMAIL PROTECTED]> wrote: > > >> OK, so you both say a full walk is OK as long as it doesn't take too long? >> > > I think it is. I think it's really important that we handle the 'no > such file' case in an extremely efficient, but *general*, manner. If > we get this right, we're going to make very wide use of LAR. > > >> Then we're indeed back to either an end-of-entries LAR member or a >> placeholder LAR member. >> > > I agree. > OK. Placeholder member or end-of-entries member? Can everybody please state his personal opinion and the technical reasons for it, then we proceed? Bonus points if the opinion is delivered as a patch. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIRQ Tables
On Wed, Jan 16, 2008 at 09:38:41AM -0800, ron minnich wrote: > > 2.6.23 .. > > 2.4.24 (or 2.6.13) don't work. > > wow! that's interesting! Are the .23 and .24 configs identical? (6/4) Something must have changed since .13. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LAR walking madness
On Jan 16, 2008 2:12 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > OK, so you both say a full walk is OK as long as it doesn't take too long? I think it is. I think it's really important that we handle the 'no such file' case in an extremely efficient, but *general*, manner. If we get this right, we're going to make very wide use of LAR. > > Then we're indeed back to either an end-of-entries LAR member or a > placeholder LAR member. I agree. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Add some Winbond SPI chips to flashrom (patch).
Hi Ronald,
On 16.01.2008 23:03, Ronald Hoogenboom wrote:
> On my m57sli-rev.2 board, there is a winbond 25X40 SPI flash bios chip,
> which flashrom didn't have support for, so I added it (and the
> relatives). Patch below:
>
Sorry, that's not really a Winbond flash chip, it is a Nexcom/Nexflash
flash chip. Nexcom was acquired by Winbond, but the vendor ID for your
chips is still 0xEF (Nexcom).
I'll post an updated patch tomorrow.
Regards,
Carl-Daniel
> Index: flash.h
> ===
> --- flash.h (revision 3051)
> +++ flash.h (working copy)
> @@ -247,6 +247,12 @@
> #define W_49V002A0xB0
> #define W_49V002FA 0x32
>
> +#define WINBOND_SPI_ID 0xEF/* Winbond serial flash devices
> */
> +#define W_25X100x3011
> +#define W_25X200x3012
> +#define W_25X400x3013
> +#define W_25X800x3014
> +
> /* udelay.c */
> void myusec_delay(int time);
> void myusec_calibrate_delay();
> Index: flashchips.c
> ===
> --- flashchips.c (revision 3051)
> +++ flashchips.c (working copy)
> @@ -122,6 +122,14 @@
>probe_jedec, erase_chip_jedec, write_39sf020},
> {"W39V080A",WINBOND_ID, W_39V080A, 1024, 64*1024,
>probe_jedec, erase_chip_jedec, write_39sf020},
> + {"W25x10", WINBOND_SPI_ID, W_25X10,128, 256,
> + probe_spi, generic_spi_chip_erase_c7,
> generic_spi_chip_write},
> + {"W25x20", WINBOND_SPI_ID, W_25X20,256, 256,
> + probe_spi, generic_spi_chip_erase_c7,
> generic_spi_chip_write},
> + {"W25x40", WINBOND_SPI_ID, W_25X40,512, 256,
> + probe_spi, generic_spi_chip_erase_c7,
> generic_spi_chip_write},
> + {"W25x80", WINBOND_SPI_ID, W_25X80,1024, 256,
> + probe_spi, generic_spi_chip_erase_c7,
> generic_spi_chip_write},
> {"M29F002B",ST_ID, ST_M29F002B,256, 64 * 1024,
>probe_jedec, erase_chip_jedec, write_jedec},
> {"M50FW040",ST_ID, ST_M50FW040,512, 64 * 1024,
>
>
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LAR walking madness
On 16.01.2008 18:53, Jordan Crouse wrote: > On 16/01/08 10:41 -0700, Marc Jones wrote: > >> ron minnich wrote: >> >> >>> It seems like you've added two slightly more complicated ways to do >>> things where one simple one would have done: an end-of-entries LAR >>> header. Limiting payload segments to two is going to cause us trouble >>> now and forever, I think. And I'd still like to have a microcode/ >>> directory, and a rom/ directory, each with an undefined # of entries. >>> I think the LAR is going to be used in the future in ways we can not >>> imagine now. So solving those two cases won't help future uses. >>> >> I agree. I would like to use the LAR for microcode and for Geode VSA for >> starters. >> > > Not to pile on, but I agree 100%. > > The problem is that we've demonstrated conclusively in v2 that understanding > arbitrary blobs of non-payload data is mandatory for nearly architecture > we deal with. The initial design of LAR allowed for unlimited and arbitrary > blobs (either through careful design or luck). If now the limitations of LAR > are starting to outweigh the benefits, then we either have to account for > them, or scratch LAR and start over. > OK, so you both say a full walk is OK as long as it doesn't take too long? Then we're indeed back to either an end-of-entries LAR member or a placeholder LAR member. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Add some Winbond SPI chips to flashrom (patch).
Hi,
On my m57sli-rev.2 board, there is a winbond 25X40 SPI flash bios chip,
which flashrom didn't have support for, so I added it (and the
relatives). Patch below:
Index: flash.h
===
--- flash.h (revision 3051)
+++ flash.h (working copy)
@@ -247,6 +247,12 @@
#define W_49V002A 0xB0
#define W_49V002FA 0x32
+#define WINBOND_SPI_ID 0xEF/* Winbond serial flash devices
*/
+#define W_25X100x3011
+#define W_25X200x3012
+#define W_25X400x3013
+#define W_25X800x3014
+
/* udelay.c */
void myusec_delay(int time);
void myusec_calibrate_delay();
Index: flashchips.c
===
--- flashchips.c(revision 3051)
+++ flashchips.c(working copy)
@@ -122,6 +122,14 @@
probe_jedec, erase_chip_jedec, write_39sf020},
{"W39V080A",WINBOND_ID, W_39V080A, 1024, 64*1024,
probe_jedec, erase_chip_jedec, write_39sf020},
+ {"W25x10", WINBOND_SPI_ID, W_25X10,128, 256,
+probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write},
+ {"W25x20", WINBOND_SPI_ID, W_25X20,256, 256,
+probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write},
+ {"W25x40", WINBOND_SPI_ID, W_25X40,512, 256,
+probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write},
+ {"W25x80", WINBOND_SPI_ID, W_25X80,1024, 256,
+probe_spi, generic_spi_chip_erase_c7,
generic_spi_chip_write},
{"M29F002B",ST_ID, ST_M29F002B,256, 64 * 1024,
probe_jedec, erase_chip_jedec, write_jedec},
{"M50FW040",ST_ID, ST_M50FW040,512, 64 * 1024,
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Family 0Fh CAR and L1 cache tags
On 16.01.2008 21:58, Marc Jones wrote: > Carl-Daniel Hailfinger wrote: >> As I understand the logic of the snippet above, we look for a DQSWrDelay >> which does not give any errors with TrainReadDQS. Then we don't care >> about errors for other values of DQSWrDelay and use the current value of >> DQSWrDelay to run TrainWriteDQS. >> If TrainReadDQS failed for all values of DQSWrDelay, we return the >> bitwise OR of all error conditions we had for all values of DQSWrDelay. >> Does that really make sense? > > Any bit set means fail. Caller checks !=0. I think it is fine. I guess > it could be translated to a pass/fail. If there are no passing case > the reason doesn't really matter. The real errors are reported in > TrainDQSPos(). Does that answer your question? Yes, that indeed does explain the code. Thanks! Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Family 0Fh CAR and L1 cache tags
Carl-Daniel Hailfinger wrote:
> Errors = 0;
> channel = 0;
> while( (channel<2) && (!Errors)) {
> print_debug_dqs("\tTrainDQSRdWrPos: 1 channel ",channel, 1);
> for(DQSWrDelay = 0; DQSWrDelay < 48; DQSWrDelay++) {
> unsigned err;
> SetDQSDelayAllCSR(ctrl, channel, DQS_WRITEDIR, DQSWrDelay);
> print_debug_dqs("\t\tTrainDQSRdWrPos: 21 DQSWrDelay ",
> DQSWrDelay, 2);
> err= TrainReadDQS(ctrl, channel, pattern, buf_a, dqs_delay_a,
> sysinfo);
> print_debug_dqs("\t\tTrainDQSRdWrPos: 22 err ",err, 2);
> if(err == 0) break;
> -> Now we set "Errors"
> Errors |= err;
> }
> print_debug_dqs("\tTrainDQSRdWrPos: 3 DQSWrDelay ", DQSWrDelay, 1);
> if(DQSWrDelay < 48) {
> -> Now we overwrite "Errors" in case the for loop above ever had
> err == 0.
> Errors = TrainWriteDQS(ctrl, channel, pattern, buf_a,
> dqs_delay_a, sysinfo);
> print_debug_dqs("\tTrainDQSRdWrPos: 4 Errors ", Errors, 1);
> }
> channel++;
> if(!is_Width128){
> //FIXME: 64MuxMode??
> channel++; // skip channel if 64-bit mode
> }
> }
>
>
> As I understand the logic of the snippet above, we look for a DQSWrDelay
> which does not give any errors with TrainReadDQS. Then we don't care
> about errors for other values of DQSWrDelay and use the current value of
> DQSWrDelay to run TrainWriteDQS.
> If TrainReadDQS failed for all values of DQSWrDelay, we return the
> bitwise OR of all error conditions we had for all values of DQSWrDelay.
> Does that really make sense?
Any bit set means fail. Caller checks !=0. I think it is fine. I guess
it could be translated to a pass/fail. If there are no passing case the
reason doesn't really matter. The real errors are reported in
TrainDQSPos(). Does that answer your question?
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] CN700 with a KVR533D2N4/512 memory module
If you have read my last message, i comment that
memory works if i change the values of do_ram_command
functions in sdram_enable() written by Corey Osgood for
the CN700 with a C7 CPU. When is used with KVR533D2N4/512
module, the memory not works, but i have finally, changing
the values that works fine, with execution of branch instructions
if i use the values:
. part of src/northbrigde/cn700/raminit.c .
// 6. Mode register set.
PRINT_DEBUG_MEM("RAM Enable 4: Mode register set\r\n");
//safe value for now, BL=8, WR=5, CAS=5
/* (E)MRS values are from the BPG. No direct explanation is given, but
* they should somehow conform to the JEDEC DDR2 SDRAM Specification
* (JESD79-2C). */
// do_ram_command( RAM_COMMAND_MRS, 0x0022d8);//by Corey
do_ram_command( RAM_COMMAND_MRS, 0x1022d8);//With the 20 bit ON.
// 7. Mode register set.
PRINT_DEBUG_MEM("RAM Enable 4: Mode register set\r\n");
// do_ram_command( RAM_COMMAND_MRS, 0x21c20);//default OCD calibration
by Corey
do_ram_command( RAM_COMMAND_MRS, 0x121c20);//With the 20 bit ON.
// do_ram_command( RAM_COMMAND_MRS, 0x20020);//exit calibration mode
do_ram_command( RAM_COMMAND_MRS, 0x120020);//With the 20 bit ON.
// 8. Normal operation
PRINT_DEBUG_MEM("RAM Enable 5: Normal operation\r\n");
do_ram_command( RAM_COMMAND_NORMAL, 0);
.end part of src/borthbrigde/cn700/raminit.c.
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD SimNOW question
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 16, 2008 1:12 PM > To: Jordan Crouse > Cc: [EMAIL PROTECTED]; 'LinuxBIOS' > Subject: Re: AMD SimNOW question > > Can someone send me a rom image they have built and tested using > SimNOW. I want to verify my SimNOW setup. Sure, I'll send it in a few minutes. Myles > > I am thinking it has something to do with the initrd ramdrive and it is > failing when it goes to run the init scripts. > > > /* > Marc Karasek > MTS > Sun Microsystems > mailto:[EMAIL PROTECTED] > ph:770.360.6415 > */ > > > > Jordan Crouse wrote: > > On 11/01/08 16:51 -0500, Marc Karasek wrote: > > > >> No the serial port output looks ok. It is the "vga" ouput I need to > >> capture. The kernel as loader is crashing... > >> > > > > Oh, wow... I don't think there's any way to do that. You can log the > > I/O and memory space accesses, but you can't log the screen. Maybe the > > I/O and memory space accesses would be enough - assuming you can parse > > through the noise to find the strings you want. > > > > Jordan > > > > > > -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD SimNOW question
Can someone send me a rom image they have built and tested using SimNOW. I want to verify my SimNOW setup. I am thinking it has something to do with the initrd ramdrive and it is failing when it goes to run the init scripts. /* Marc Karasek MTS Sun Microsystems mailto:[EMAIL PROTECTED] ph:770.360.6415 */ Jordan Crouse wrote: > On 11/01/08 16:51 -0500, Marc Karasek wrote: > >> No the serial port output looks ok. It is the "vga" ouput I need to >> capture. The kernel as loader is crashing... >> > > Oh, wow... I don't think there's any way to do that. You can log the > I/O and memory space accesses, but you can't log the screen. Maybe the > I/O and memory space accesses would be enough - assuming you can parse > through the noise to find the strings you want. > > Jordan > > > -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] CN700 with a KVR533D2N4/512 memory module.
I have the same module DRAM as more people that have written in the list
that not work with the initialization, and have tested the code of Corey
(1000 thanks Corey), and have the same results, but have found a
aproximation
to the solution:
This DDR2 module works with Corey memory initialization with a little
change
with another values that another mainboard finds with the same DDR2
module, and
then works, with the C7/CN700 but y not known what are the bits that
differ with
the Corey version.
The changes for /src/northbridge/via/cn700/raminit.c (marked with a //by
another mainboard)
..chunk of sdram_enable()..
/* (E)MRS values are from the BPG. No direct explanation is
given, but
* they should somehow conform to the JEDEC DDR2 SDRAM
Specification
* (JESD79-2C). */
// do_ram_command( RAM_COMMAND_MRS, 0x0022d8);//by Corey
do_ram_command( RAM_COMMAND_MRS, 0x101258);//by another
mainboard
// do_ram_command( RAM_COMMAND_MRS, 0x2258);//a second mainboard
// 7. Mode register set.
PRINT_DEBUG_MEM("RAM Enable 4: Mode register set\r\n");
// do_ram_command( RAM_COMMAND_MRS, 0x21c20);//default OCD
calibration by
do_ram_command( RAM_COMMAND_MRS, 0x121c20);//By another
mainboard
// do_ram_command( RAM_COMMAND_MRS, 0x20020);//exit calibration
mode
do_ram_command( RAM_COMMAND_MRS, 0x120020);//by another
mainboard
// 8. Normal operation
PRINT_DEBUG_MEM("RAM Enable 5: Normal operation\r\n");
do_ram_command( RAM_COMMAND_NORMAL, 0);
..chunk of sdram_enable()..
Only have a problem with these values. The RAM works correctly all
511MB, i can write
memory and then test it... but when i jumps
to a program loaded in memory, hangs with the first Branch instruction,
for
example "je". I not wise, if the C7/CN700 can have a optimization system
with
branches, that requires a feature with SDRAM activated. If the code
loaded
not have branches, it works. Is for me absurd
El vie, 21-12-2007 a las 02:44 +0100, [EMAIL PROTECTED]
escribió:
> KVR533D2N4/512,
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH][cbv2]Add serial port information to lbtable
Am Mittwoch, den 16.01.2008, 16:03 +0100 schrieb Uwe Hermann: > Have you checked lxbios continues to work after the changes? No, will do. > I think not all of the boards define it, and even if they did, I'll fix that. Thanks > TTYS0_BASE implies COM1, which is not always what you want. > We need a mechanism to allow other ports here (COM2, COM3, COM4). I won't work on infrastructure improvements for v2 if I can help it. > Yes, I think it's just a name, in theory you could assign any value > to TTYS0_BASE, but you get the point. "ttys0" is rather meaningless by itself. What if it means "0th serial port we use" (emphasis on the last two words)? A stable name would be "COM1" in my opinion... Regards, Patrick Georgi -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LAR walking madness
On 16/01/08 10:41 -0700, Marc Jones wrote: > > > ron minnich wrote: > > > > > It seems like you've added two slightly more complicated ways to do > > things where one simple one would have done: an end-of-entries LAR > > header. Limiting payload segments to two is going to cause us trouble > > now and forever, I think. And I'd still like to have a microcode/ > > directory, and a rom/ directory, each with an undefined # of entries. > > I think the LAR is going to be used in the future in ways we can not > > imagine now. So solving those two cases won't help future uses. > > I agree. I would like to use the LAR for microcode and for Geode VSA for > starters. Not to pile on, but I agree 100%. The problem is that we've demonstrated conclusively in v2 that understanding arbitrary blobs of non-payload data is mandatory for nearly architecture we deal with. The initial design of LAR allowed for unlimited and arbitrary blobs (either through careful design or luck). If now the limitations of LAR are starting to outweigh the benefits, then we either have to account for them, or scratch LAR and start over. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LAR walking madness
ron minnich wrote: > > It seems like you've added two slightly more complicated ways to do > things where one simple one would have done: an end-of-entries LAR > header. Limiting payload segments to two is going to cause us trouble > now and forever, I think. And I'd still like to have a microcode/ > directory, and a rom/ directory, each with an undefined # of entries. > I think the LAR is going to be used in the future in ways we can not > imagine now. So solving those two cases won't help future uses. I agree. I would like to use the LAR for microcode and for Geode VSA for starters. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIRQ Tables
On Jan 16, 2008 4:10 AM, Cimino Vittorio <[EMAIL PROTECTED]> wrote: > I have made a pirq table as show into the web page of the linuxbios.org with > a kernel 2.6.23. The routing table made for the motherboard work, the > request are signaled to the kernel and after to the driver better. > > With the same pirq table a kernel 2.4.24 (or 2.6.13) don't work. > > There are a kernel option for like (MESSAGE SIGNALED INTERRUPTD) that > override a bad pirq table? wow! that's interesting! Are the .23 and .24 configs identical? ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] LAR walking madness
On Jan 16, 2008 5:21 AM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > Basically, to avoid a full walk, you have to avoid requesting a > nonexistant file. How? > We have two sources of for such requests and they are easy to fix: > - Looking for "normal/initram" when we should have looked for > "fallback/initram". Simply make sure check_normal_boot_flag() returns a > value matching the files you stored in the LAR. > - Looking for "stage2" and "payload" segments which are not there. We > can either add a "number of segments" field to the LAR header or we > restrict the number of segments to 2. > It seems like you've added two slightly more complicated ways to do things where one simple one would have done: an end-of-entries LAR header. Limiting payload segments to two is going to cause us trouble now and forever, I think. And I'd still like to have a microcode/ directory, and a rom/ directory, each with an undefined # of entries. I think the LAR is going to be used in the future in ways we can not imagine now. So solving those two cases won't help future uses. So to me, this approach seems to be two special-case solutions to a problem which needs a general solution. And the general problem is this: when searching for an entry, we must know when we are at the last LAR header, so that we do not waste a full second searching all of FLASH for further entries which are not there. I think we need to try again. sorry ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r554 - / coreboot-v3
Author: stepan Date: 2008-01-16 17:18:32 +0100 (Wed, 16 Jan 2008) New Revision: 554 Added: coreboot-v3/ Removed: LinuxBIOSv3/ Log: rename repository from LinuxBIOSv3 to coreboot-v3 Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]> Acked-by: Jordan Crouse <[EMAIL PROTECTED]> Property changes on: coreboot-v3 ___ Name: svn:ignore + .kconfig.d .config .tmpconfig.h .xcompile build .config.old Name: svn:mergeinfo + -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r554 - / coreboot-v3
Author: stepan Date: 2008-01-16 17:18:32 +0100 (Wed, 16 Jan 2008) New Revision: 554 Added: coreboot-v3/ Removed: LinuxBIOSv3/ Log: rename repository from LinuxBIOSv3 to coreboot-v3 Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]> Acked-by: Jordan Crouse <[EMAIL PROTECTED]> Property changes on: coreboot-v3 ___ Name: svn:ignore + .kconfig.d .config .tmpconfig.h .xcompile build .config.old Name: svn:mergeinfo + -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] repository rename
On 14/01/08 20:51 +0100, Stefan Reinauer wrote: > Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]> Acked-by: Jordan Crouse <[EMAIL PROTECTED]> Make it so. > NOTE: After this change you will not be able to "svn update" unless you > switch to the new repository layout with: > > $ cd LinuxBIOSv1 > $ svn switch svn://coreboot.org/repos/trunk/coreboot-v1 > > or > > $ cd LinuxBIOSv2 > $ svn switch svn://coreboot.org/repos/trunk/coreboot-v2 > > or > > $ cd LinuxBIOSv3 > $ svn switch svn://coreboot.org/repository/coreboot-v3 > > Best regards, > Stefan > > -- > coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 • Fax: +49 761 7664613 > Email: [EMAIL PROTECTED] • http://www.coresystems.de/ > Registergericht: Amtsgericht Freiburg • HRB 7656 > Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 > > > -- > coreboot mailing list > coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fixing the flashrom problem on m57sli v2.0 (issue #87?)
Hello,
I propose this patch :
Index: LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/mcp55_lpc.c
===
--- LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/mcp55_lpc.c
(revision
3050)
+++ LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/mcp55_lpc.c (working
copy)
@@ -161,11 +161,15 @@
static void lpc_init(device_t dev)
{
+ struct southbridge_nvidia_mcp55_config *conf;
+ uint32_t dword;
uint8_t byte;
uint8_t byte_old;
int on;
int nmi_option;
+ conf = dev->chip_info;
+
lpc_common_init(dev);
#if 0
@@ -238,6 +242,18 @@
/* Initialize the High Precision Event Timers */
// enable_hpet(dev);
+ /* Enables the decoding of the IO addresses to the flash SPI interface
+(if present into the SIO) */
+ if (conf->spi_sio_enable) {
+ dword = pci_read_config32(dev, 0xa0);
+ dword |= (1<<30);
+ pci_write_config32(dev, 0xa0, dword);
+
+ /* FIXME : really dirty! It seems that the IO addr range for
the SPI IF.
+HAS to be set into the 0xb0 or 0xb4 reg which conflicts
strongly with
+mcp55_lpc_enable_childrens_resources() */
+ pci_write_config32(dev, conf->spi_sio_pcireg,
conf->spi_sio_iorange);
+ }
}
static void mcp55_lpc_read_resources(device_t dev)
Index: LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/chip.h
===
--- LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/chip.h (revision 3050)
+++ LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/chip.h (working copy)
@@ -28,8 +28,11 @@
unsigned int ide1_enable : 1;
unsigned int sata0_enable : 1;
unsigned int sata1_enable : 1;
+ unsigned int spi_sio_enable : 1;
unsigned int mac_eeprom_smbus;
unsigned int mac_eeprom_addr;
+ unsigned int spi_sio_pcireg;
+ unsigned int spi_sio_iorange;
};
struct chip_operations;
extern struct chip_operations southbridge_nvidia_mcp55_ops;
Index: LinuxBIOSv2_spi_debug/src/mainboard/gigabyte/m57sli/Config.lb
===
--- LinuxBIOSv2_spi_debug/src/mainboard/gigabyte/m57sli/Config.lb
(revision
3050)
+++ LinuxBIOSv2_spi_debug/src/mainboard/gigabyte/m57sli/Config.lb
(working copy)
@@ -403,6 +403,9 @@
register "sata1_enable" = "1"
register "mac_eeprom_smbus" = "3" # 1:
smbus under 2e.8, 2: SM0 3: SM1
register "mac_eeprom_addr" = "0x51"
+ register "spi_sio_enable" = "1"
+ register "spi_sio_pcireg" = "0xb0"
+ register "spi_sio_iorange" =
"0x085f0800"
end
end # device pci 18.0
device pci 18.0 on end # Link 1
Btw is this related to the issue #87 in Issuetracker? (should a new ticket be
created especially for this issue?)
Thanks a lot for the help in resolving this issue to all the coreboot team!
Florentin
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH][cbv2]Add serial port information to lbtable
* Uwe Hermann <[EMAIL PROTECTED]> [080116 16:03]:
> Looks good, but a few comments:
>
> On Wed, Jan 16, 2008 at 12:34:14PM +0100, Patrick Georgi wrote:
> > the attached patch makes cbv2 add information about the serial port to
> > lbtable. For this, a new record type is created. Payloads can then parse
> > lbtable to figure out where to find the serial port (which is usually
> > used by lb as console already).
> >
> > A patch for grub2 exists, too, and I'll implement a compatible change
> > for cbv3 once the record format (and overall design etc) is stable.
>
> Have you checked lxbios continues to work after the changes?
>
>
> > Index: src/arch/i386/boot/linuxbios_table.c
> > ===
> > --- src/arch/i386/boot/linuxbios_table.c(Revision 3049)
> > +++ src/arch/i386/boot/linuxbios_table.c(Arbeitskopie)
> > @@ -74,6 +74,18 @@
> > return mem;
> > }
> >
> > +struct lb_serial *lb_serial(struct lb_header *header)
> > +{
> > + struct lb_record *rec;
> > + struct lb_serial *serial;
> > + rec = lb_new_record(header);
> > + serial = (struct lb_serial *)rec;
> > + serial->tag = LB_TAG_SERIAL;
> > + serial->size = sizeof(*serial);
>
> > + serial->ioport = TTYS0_BASE;
>
> This doesn't look generic enough(?) Where does TTYS0_BASE come from?
> Does the code expect it to be defined in auto.c or cache_as_ram_auto.c?
>
> I think not all of the boards define it, and even if they did,
> TTYS0_BASE implies COM1, which is not always what you want.
> We need a mechanism to allow other ports here (COM2, COM3, COM4).
>
> Yes, I think it's just a name, in theory you could assign any value
> to TTYS0_BASE, but you get the point.
yes, the variable should not be named TTYS0 but SERIAL_CONSOLE or
something. But thats something I'd leave for v3.
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED] • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH][cbv2]Add serial port information to lbtable
Looks good, but a few comments:
On Wed, Jan 16, 2008 at 12:34:14PM +0100, Patrick Georgi wrote:
> the attached patch makes cbv2 add information about the serial port to
> lbtable. For this, a new record type is created. Payloads can then parse
> lbtable to figure out where to find the serial port (which is usually
> used by lb as console already).
>
> A patch for grub2 exists, too, and I'll implement a compatible change
> for cbv3 once the record format (and overall design etc) is stable.
Have you checked lxbios continues to work after the changes?
> Index: src/arch/i386/boot/linuxbios_table.c
> ===
> --- src/arch/i386/boot/linuxbios_table.c (Revision 3049)
> +++ src/arch/i386/boot/linuxbios_table.c (Arbeitskopie)
> @@ -74,6 +74,18 @@
> return mem;
> }
>
> +struct lb_serial *lb_serial(struct lb_header *header)
> +{
> + struct lb_record *rec;
> + struct lb_serial *serial;
> + rec = lb_new_record(header);
> + serial = (struct lb_serial *)rec;
> + serial->tag = LB_TAG_SERIAL;
> + serial->size = sizeof(*serial);
> + serial->ioport = TTYS0_BASE;
This doesn't look generic enough(?) Where does TTYS0_BASE come from?
Does the code expect it to be defined in auto.c or cache_as_ram_auto.c?
I think not all of the boards define it, and even if they did,
TTYS0_BASE implies COM1, which is not always what you want.
We need a mechanism to allow other ports here (COM2, COM3, COM4).
Yes, I think it's just a name, in theory you could assign any value
to TTYS0_BASE, but you get the point.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r41 - trunk/filo-0.5/fs
Author: stepan
Date: 2008-01-16 15:40:04 +0100 (Wed, 16 Jan 2008)
New Revision: 41
Modified:
trunk/filo-0.5/fs/filesys.h
trunk/filo-0.5/fs/vfs.c
Log:
hook up cramfs and squashfs
Modified: trunk/filo-0.5/fs/filesys.h
===
--- trunk/filo-0.5/fs/filesys.h 2008-01-16 14:19:17 UTC (rev 40)
+++ trunk/filo-0.5/fs/filesys.h 2008-01-16 14:40:04 UTC (rev 41)
@@ -170,6 +170,18 @@
int iso9660_dir (char *dirname);
#endif
+#ifdef FSYS_CRAMFS
+int cramfs_mount (void);
+int cramfs_read (char *buf, int len);
+int cramfs_dir (char *dirname);
+#endif
+
+#ifdef FSYS_SQUASHFS
+int squashfs_mount (void);
+int squashfs_read (char *buf, int len);
+int squashfs_dir (char *dirname);
+#endif
+
/* This is not a flag actually, but used as if it were a flag. */
#define PC_SLICE_TYPE_HIDDEN_FLAG 0x10
Modified: trunk/filo-0.5/fs/vfs.c
===
--- trunk/filo-0.5/fs/vfs.c 2008-01-16 14:19:17 UTC (rev 40)
+++ trunk/filo-0.5/fs/vfs.c 2008-01-16 14:40:04 UTC (rev 41)
@@ -46,6 +46,12 @@
# ifdef FSYS_ISO9660
{"iso9660", iso9660_mount, iso9660_read, iso9660_dir, 0, 0},
# endif
+# ifdef FSYS_CRAMFS
+{"cramfs", cramfs_mount, cramfs_read, cramfs_dir, 0, 0},
+# endif
+# ifdef FSYS_SQUASHFS
+{"squashfs", squashfs_mount, squashfs_read, squashfs_dir, 0, 0},
+# endif
};
/* NULLFS is used to read images from raw device */
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] r41 - trunk/filo-0.5/fs
Author: stepan
Date: 2008-01-16 15:40:04 +0100 (Wed, 16 Jan 2008)
New Revision: 41
Modified:
trunk/filo-0.5/fs/filesys.h
trunk/filo-0.5/fs/vfs.c
Log:
hook up cramfs and squashfs
Modified: trunk/filo-0.5/fs/filesys.h
===
--- trunk/filo-0.5/fs/filesys.h 2008-01-16 14:19:17 UTC (rev 40)
+++ trunk/filo-0.5/fs/filesys.h 2008-01-16 14:40:04 UTC (rev 41)
@@ -170,6 +170,18 @@
int iso9660_dir (char *dirname);
#endif
+#ifdef FSYS_CRAMFS
+int cramfs_mount (void);
+int cramfs_read (char *buf, int len);
+int cramfs_dir (char *dirname);
+#endif
+
+#ifdef FSYS_SQUASHFS
+int squashfs_mount (void);
+int squashfs_read (char *buf, int len);
+int squashfs_dir (char *dirname);
+#endif
+
/* This is not a flag actually, but used as if it were a flag. */
#define PC_SLICE_TYPE_HIDDEN_FLAG 0x10
Modified: trunk/filo-0.5/fs/vfs.c
===
--- trunk/filo-0.5/fs/vfs.c 2008-01-16 14:19:17 UTC (rev 40)
+++ trunk/filo-0.5/fs/vfs.c 2008-01-16 14:40:04 UTC (rev 41)
@@ -46,6 +46,12 @@
# ifdef FSYS_ISO9660
{"iso9660", iso9660_mount, iso9660_read, iso9660_dir, 0, 0},
# endif
+# ifdef FSYS_CRAMFS
+{"cramfs", cramfs_mount, cramfs_read, cramfs_dir, 0, 0},
+# endif
+# ifdef FSYS_SQUASHFS
+{"squashfs", squashfs_mount, squashfs_read, squashfs_dir, 0, 0},
+# endif
};
/* NULLFS is used to read images from raw device */
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH][cbv2]Add serial port information to lbtable
* Patrick Georgi <[EMAIL PROTECTED]> [080116 12:34]:
> Signed-off-by: Patrick Georgi <[EMAIL PROTECTED]>
I say:
Acked-by: Stefan Reinauer <[EMAIL PROTECTED]>
but lets wait to give someone else the chance to veto this.
Can you make a similar patch for v3 once its in v2?
Thanks,
Stefan
> Index: src/include/boot/linuxbios_tables.h
> ===
> --- src/include/boot/linuxbios_tables.h (Revision 3049)
> +++ src/include/boot/linuxbios_tables.h (Arbeitskopie)
> @@ -138,6 +138,13 @@
> uint8_t string[0];
> };
>
> +#define LB_TAG_SERIAL0x000e
> +struct lb_serial {
> + uint32_t tag;
> + uint32_t size;
> + uint16_t ioport;
> +};
> +
> /* The following structures are for the cmos definitions table */
> #define LB_TAG_CMOS_OPTION_TABLE 200
> /* cmos header record */
> Index: src/arch/i386/boot/linuxbios_table.c
> ===
> --- src/arch/i386/boot/linuxbios_table.c (Revision 3049)
> +++ src/arch/i386/boot/linuxbios_table.c (Arbeitskopie)
> @@ -74,6 +74,18 @@
> return mem;
> }
>
> +struct lb_serial *lb_serial(struct lb_header *header)
> +{
> + struct lb_record *rec;
> + struct lb_serial *serial;
> + rec = lb_new_record(header);
> + serial = (struct lb_serial *)rec;
> + serial->tag = LB_TAG_SERIAL;
> + serial->size = sizeof(*serial);
> + serial->ioport = TTYS0_BASE;
> + return serial;
> +}
> +
> struct lb_mainboard *lb_mainboard(struct lb_header *header)
> {
> struct lb_record *rec;
> @@ -406,8 +418,10 @@
>* size of the linuxbios table.
>*/
>
> - /* Record our motheboard */
> + /* Record our motherboard */
> lb_mainboard(head);
> + /* Record our console */
> + lb_serial(head);
> /* Record our various random string information */
> lb_strings(head);
>
> --
> coreboot mailing list
> coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED] • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] LAR walking madness
Hi, Stefan and I spoke about various v3 stuff yesterday and it seems we have a slightly hackish solution which will avoid full LAR walks completely by changing the header format. Basically, to avoid a full walk, you have to avoid requesting a nonexistant file. How? We have two sources of for such requests and they are easy to fix: - Looking for "normal/initram" when we should have looked for "fallback/initram". Simply make sure check_normal_boot_flag() returns a value matching the files you stored in the LAR. - Looking for "stage2" and "payload" segments which are not there. We can either add a "number of segments" field to the LAR header or we restrict the number of segments to 2. Incremental caching of lookups can still save some time, but avoiding the full walk completely is going to save more time than anything else. I will not be able to write any new code before the end of February (my thesis simply eats up all my time), but both points above should be really reasy to fix. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Family 0Fh CAR and L1 cache tags
On 15.01.2008 18:54, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> The BKDG rev. 3.08 for AMD Family 0Fh states that it is possible to use
>> a CAR area with a size of 64K in section 13.16 "Cache Initialization For
>> General Storage During Boot". It also says that during DRAM training CAR
>> size must be reduced. For DDR training, 256 cache lines with L1 cache
>> tag indexes 00h-FFh are reserved and must not be used as CAR. The text
>> then refers to the AMD64 Arch Programmers Manual Vol. 2 for more details
>> on L1 function. However, I couldn't find any explanation why L1 cache
>> tag indexes 00h-FFh correspond to address space Ch-C3FFFh when fixed
>> size MTRRs are active.
>
> I may be misunderstanding your question but I don't think that tag
> indexes 00h-ffh have to correspond to Ch-C3FFFh. I'm also not
> positive that they must be tag indexes 00h-ffh. I think that they
> could be on the end as long as the tags are contiguous.
Good to know. Can you make sure such a sentence gets added to the BKDG
in its various versions?
> This comment refers DDR training needing the space to hold test
> patterns for dqs eye finding during memory training. See
> northbridge\amd\amdk8\raminit_f_dqs.c TrainDQSRdWrPos().
Thanks. It seems I have to reread the code a few times to fully
understand its structure.
But I have spotted something peculiar in the code of TrainDQSRdWrPos()
in src/northbridge/amd/amdk8/raminit_f_dqs.c
Errors = 0;
channel = 0;
while( (channel<2) && (!Errors)) {
print_debug_dqs("\tTrainDQSRdWrPos: 1 channel ",channel, 1);
for(DQSWrDelay = 0; DQSWrDelay < 48; DQSWrDelay++) {
unsigned err;
SetDQSDelayAllCSR(ctrl, channel, DQS_WRITEDIR, DQSWrDelay);
print_debug_dqs("\t\tTrainDQSRdWrPos: 21 DQSWrDelay ",
DQSWrDelay, 2);
err= TrainReadDQS(ctrl, channel, pattern, buf_a, dqs_delay_a,
sysinfo);
print_debug_dqs("\t\tTrainDQSRdWrPos: 22 err ",err, 2);
if(err == 0) break;
-> Now we set "Errors"
Errors |= err;
}
print_debug_dqs("\tTrainDQSRdWrPos: 3 DQSWrDelay ", DQSWrDelay, 1);
if(DQSWrDelay < 48) {
-> Now we overwrite "Errors" in case the for loop above ever had
err == 0.
Errors = TrainWriteDQS(ctrl, channel, pattern, buf_a,
dqs_delay_a, sysinfo);
print_debug_dqs("\tTrainDQSRdWrPos: 4 Errors ", Errors, 1);
}
channel++;
if(!is_Width128){
//FIXME: 64MuxMode??
channel++; // skip channel if 64-bit mode
}
}
As I understand the logic of the snippet above, we look for a DQSWrDelay
which does not give any errors with TrainReadDQS. Then we don't care
about errors for other values of DQSWrDelay and use the current value of
DQSWrDelay to run TrainWriteDQS.
If TrainReadDQS failed for all values of DQSWrDelay, we return the
bitwise OR of all error conditions we had for all values of DQSWrDelay.
Does that really make sense?
> For coreboot, it looks like the test patterns are just pushed onto the
> stack.
Indeed. So we are completely free to place CAR anywhere we want with any
size we want (subject to L2 size restrictions).
> For AMD BIOS code, this is not the case and they are put into the
> cache at a set location. (I think that this is easier for the AGESA
> asm code to handle that way).
I see.
Thanks for pointing me to the code. I shall add good comments to that
code snippet once I have more time.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PIRQ Tables
tnx but i know this ! I try to explain (sorry for the english) I have made a pirq table as show into the web page of the linuxbios.org with a kernel 2.6.23. The routing table made for the motherboard work, the request are signaled to the kernel and after to the driver better. With the same pirq table a kernel 2.4.24 (or 2.6.13) don't work. There are a kernel option for like (MESSAGE SIGNALED INTERRUPTD) that override a bad pirq table? Tnx - Original Message - From: "ron minnich" <[EMAIL PROTECTED]> To: "Cimino Vittorio" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, January 15, 2008 10:25 PM Subject: Re: [coreboot] PIRQ Tables > I assume you don't want a PIRQ table at all? > > In your TARGET config file, e.g. > targets/iwill/dk8s2/Config.lb > > add the lines > uses HAVE_PIRQ_TABLE > option HAVE_PIRQ_TABLE=0 > > ron > > -- > coreboot mailing list > coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH][cbv2]Add serial port information to lbtable
Hi,
the attached patch makes cbv2 add information about the serial port to
lbtable. For this, a new record type is created. Payloads can then parse
lbtable to figure out where to find the serial port (which is usually
used by lb as console already).
A patch for grub2 exists, too, and I'll implement a compatible change
for cbv3 once the record format (and overall design etc) is stable.
Regards,
Patrick Georgi
Signed-off-by: Patrick Georgi <[EMAIL PROTECTED]>
Index: src/include/boot/linuxbios_tables.h
===
--- src/include/boot/linuxbios_tables.h (Revision 3049)
+++ src/include/boot/linuxbios_tables.h (Arbeitskopie)
@@ -138,6 +138,13 @@
uint8_t string[0];
};
+#define LB_TAG_SERIAL 0x000e
+struct lb_serial {
+ uint32_t tag;
+ uint32_t size;
+ uint16_t ioport;
+};
+
/* The following structures are for the cmos definitions table */
#define LB_TAG_CMOS_OPTION_TABLE 200
/* cmos header record */
Index: src/arch/i386/boot/linuxbios_table.c
===
--- src/arch/i386/boot/linuxbios_table.c(Revision 3049)
+++ src/arch/i386/boot/linuxbios_table.c(Arbeitskopie)
@@ -74,6 +74,18 @@
return mem;
}
+struct lb_serial *lb_serial(struct lb_header *header)
+{
+ struct lb_record *rec;
+ struct lb_serial *serial;
+ rec = lb_new_record(header);
+ serial = (struct lb_serial *)rec;
+ serial->tag = LB_TAG_SERIAL;
+ serial->size = sizeof(*serial);
+ serial->ioport = TTYS0_BASE;
+ return serial;
+}
+
struct lb_mainboard *lb_mainboard(struct lb_header *header)
{
struct lb_record *rec;
@@ -406,8 +418,10 @@
* size of the linuxbios table.
*/
- /* Record our motheboard */
+ /* Record our motherboard */
lb_mainboard(head);
+ /* Record our console */
+ lb_serial(head);
/* Record our various random string information */
lb_strings(head);
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
