Re: [coreboot] Indtast Bcc Indtast Bcc Wyse S10 and coreboot
On 05/21/2010 07:30 AM, and...@jenbo.dk wrote: Yeah I looked at the manual, only difference is between s10-s90 is RAM and hdd size. Ah, didn't even know they had HDD versions too in the S series... oliver -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Indtast Bcc Indtast Bcc Wyse S10 and coreboot
On 05/21/2010 07:50 AM, and...@jenbo.dk wrote: Also check out the required tool chain here coreboot.org/Development_Guidelines I checked those and I have everything on my Ubuntu laptop, except pciutils-dev package. Seems like it doesn't exist. I checked through the sources and there weren't many header files included; Which files from pciutils-dev are needed that wouldn't be in a pciutils package? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot
You will need the developer package of pciutils, use the name on the wiki it is in the ubuntu repository. Yes seabios is the best to start of with, download it via git, and configure it as a payload (se wiki) then make it. For coreboot al you need to do is pick s50 as the board, pick the right Rom size, point to the payload. As for network boot you will need an additional tool (look at the wiki). Mvh Anders - Reply message - Fra: Oliver Schinagl oli...@schinagl.nl Dato: fre., maj 21, 2010 08:08 Emne: [coreboot] Indtast Bcc Indtast Bcc Wyse S10 and coreboot Til: coreboot@coreboot.org On 05/21/2010 07:50 AM, and...@jenbo.dk wrote: Also check out the required tool chain here coreboot.org/Development_Guidelines I checked those and I have everything on my Ubuntu laptop, except pciutils-dev package. Seems like it doesn't exist. I checked through the sources and there weren't many header files included; Which files from pciutils-dev are needed that wouldn't be in a pciutils package? -- 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
Re: [coreboot] Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot
On 05/21/2010 08:28 AM, and...@jenbo.dk wrote: You will need the developer package of pciutils, use the name on the wiki it is in the ubuntu repository. I couldn't find it, well unless it's pciutils and pci-utils-dev :p I'll search more. Yes seabios is the best to start of with, download it via git, and configure it as a payload (se wiki) then make it. All right. For coreboot al you need to do is pick s50 as the board, pick the right Rom size, point to the payload. The romsize defaults to 256k but according to flashrom (And the markings on the chip) it's a 2mb flash unit? Also there's a lot of VGA, VSA and other settings that where very confusing as I read somewhere on the wiki; that the Geode GX2/LX don't support VGA things? And the VSA bit, I found that there is OpenVSA but it's highly experimental? Do I need it at all? As for network boot you will need an additional tool (look at the wiki). GPXE stuff I belive? Thank you for your time so far! Oliver -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Issues with Geos mainboard
On 20/05/2010 10:56 PM, Kevin O'Connor wrote: On Thu, May 20, 2010 at 03:04:01PM +1000, Nathan Williams wrote: On 20/05/2010 11:23 AM, Nathan Williams wrote: This board is similar to the AMD Norwich mainboard. Signed-off-by: Nathan Williams nat...@traverse.com.au Currently I'm having 4 issues with coreboot-v4 on this board: 1. On initial power-on, SeaBIOS doesn't get past Press F12 for boot menu. Can you post the full log? An error in Press F12 is likely a problem with the RTC. -Kevin Ah.. It works if I have the CMOS battery in. Thanks Kevin. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Indtast Bcc Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot
I haven't worked with build in gratis cards, but you will probably need a copy of your vga Rom. I prefer to have seabios load the vga Rom. Mvh Anders - Reply message - Fra: Oliver Schinagl oli...@schinagl.nl Dato: fre., maj 21, 2010 08:36 Emne: [coreboot] Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot Til: coreboot@coreboot.org On 05/21/2010 08:28 AM, and...@jenbo.dk wrote: You will need the developer package of pciutils, use the name on the wiki it is in the ubuntu repository. I couldn't find it, well unless it's pciutils and pci-utils-dev :p I'll search more. Yes seabios is the best to start of with, download it via git, and configure it as a payload (se wiki) then make it. All right. For coreboot al you need to do is pick s50 as the board, pick the right Rom size, point to the payload. The romsize defaults to 256k but according to flashrom (And the markings on the chip) it's a 2mb flash unit? Also there's a lot of VGA, VSA and other settings that where very confusing as I read somewhere on the wiki; that the Geode GX2/LX don't support VGA things? And the VSA bit, I found that there is OpenVSA but it's highly experimental? Do I need it at all? As for network boot you will need an additional tool (look at the wiki). GPXE stuff I belive? Thank you for your time so far! Oliver -- 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] Indtast Bcc Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot
Make sure that it is 2MB and now 2Mb(it = 256KB). And then pick the right size in coreboot. Mvh Anders - Reply message - Fra: Oliver Schinagl oli...@schinagl.nl Dato: fre., maj 21, 2010 08:36 Emne: [coreboot] Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot Til: coreboot@coreboot.org On 05/21/2010 08:28 AM, and...@jenbo.dk wrote: You will need the developer package of pciutils, use the name on the wiki it is in the ubuntu repository. I couldn't find it, well unless it's pciutils and pci-utils-dev :p I'll search more. Yes seabios is the best to start of with, download it via git, and configure it as a payload (se wiki) then make it. All right. For coreboot al you need to do is pick s50 as the board, pick the right Rom size, point to the payload. The romsize defaults to 256k but according to flashrom (And the markings on the chip) it's a 2mb flash unit? Also there's a lot of VGA, VSA and other settings that where very confusing as I read somewhere on the wiki; that the Geode GX2/LX don't support VGA things? And the VSA bit, I found that there is OpenVSA but it's highly experimental? Do I need it at all? As for network boot you will need an additional tool (look at the wiki). GPXE stuff I belive? Thank you for your time so far! Oliver -- 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
Re: [coreboot] [PATCH] reduce the size of devices
Am 20.05.2010 21:16, schrieb Myles Watson: Signed-off-by: Myles Watson myle...@gmail.com resources.diff and sconfig.diff are Acked-by: Patrick Georgi patrick.geo...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] reduce the size of devices
Am 21.05.2010 01:08, schrieb Myles Watson: static void free_resource(device_t dev, struct resource *res, struct resource *prev) ... + res-next = free_resources; + free_resources = res-next; Shouldn't that be + res-next = free_resources; + free_resources = res; to add res to the free_resources? Other than that, this is great! Smaller, cleaner, faster code, that uses less memory to achieve the same result - wonderful! With the above thing cleared up, this is Acked-by: Patrick Georgi patrick.geo...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Indtast Bcc Indtast Bcc Wyse S10 and coreboot
On Fri, May 21, 2010 at 08:08:17AM +0200, Oliver Schinagl wrote: On 05/21/2010 07:50 AM, and...@jenbo.dk wrote: Also check out the required tool chain here coreboot.org/Development_Guidelines I checked those and I have everything on my Ubuntu laptop, except pciutils-dev package. Seems like it doesn't exist. I checked through the sources and there weren't many header files included; Which files from pciutils-dev are needed that wouldn't be in a pciutils package? Hmm, apparently the package has been renamed to libpci-dev since Intrepid, and they dropped the virtual pciutils-dev package that refers to libpci-dev in Lucid. I've put a note to that effect on the wiki, too. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5576 - in trunk: src/devices src/devices/oprom/yabel src/drivers/ati/ragexl src/include/device src/northbridge/amd/amdfam10 src/northbridge/amd/amdk8 src/northbridge/amd/gx2 src/n
Author: myles
Date: Fri May 21 16:33:48 2010
New Revision: 5576
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5576
Log:
Use lists instead of arrays for resources in devices to reduce memory usage.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Patrick Georgi patrick.geo...@coresystems.de
Modified:
trunk/src/devices/device.c
trunk/src/devices/device_util.c
trunk/src/devices/oprom/yabel/device.c
trunk/src/devices/pci_device.c
trunk/src/devices/pnp_device.c
trunk/src/drivers/ati/ragexl/xlinit.c
trunk/src/include/device/device.h
trunk/src/include/device/resource.h
trunk/src/northbridge/amd/amdfam10/northbridge.c
trunk/src/northbridge/amd/amdk8/northbridge.c
trunk/src/northbridge/amd/gx2/northbridge.c
trunk/src/northbridge/amd/lx/northbridge.c
trunk/src/northbridge/intel/e7520/northbridge.c
trunk/src/northbridge/intel/e7525/northbridge.c
trunk/src/northbridge/intel/i3100/northbridge.c
trunk/src/southbridge/amd/sb600/sb600_lpc.c
trunk/src/southbridge/amd/sb700/sb700_lpc.c
trunk/src/southbridge/broadcom/bcm5785/bcm5785_lpc.c
trunk/src/southbridge/nvidia/ck804/ck804_lpc.c
trunk/src/southbridge/nvidia/mcp55/mcp55_lpc.c
trunk/src/southbridge/sis/sis966/sis966_lpc.c
trunk/src/superio/smsc/lpc47n217/superio.c
trunk/src/superio/smsc/lpc47n227/superio.c
trunk/src/superio/via/vt1211/vt1211.c
trunk/util/sconfig/main.c
Modified: trunk/src/devices/device.c
==
--- trunk/src/devices/device.c Thu May 20 17:28:19 2010(r5575)
+++ trunk/src/devices/device.c Fri May 21 16:33:48 2010(r5576)
@@ -43,6 +43,8 @@
struct device *all_devices = dev_root;
/** Pointer to the last device */
extern struct device **last_dev_p;
+/** Linked list of free resources */
+struct resource *free_resources = NULL;
/**
@@ -253,16 +255,15 @@
/* For each child which is a bridge, compute_resource_needs. */
for (dev = bus-children; dev; dev = dev-sibling) {
- unsigned i;
struct resource *child_bridge;
if (!dev-links)
continue;
/* Find the resources with matching type flags. */
- for (i = 0; i dev-resources; i++) {
+ for (child_bridge = dev-resource_list; child_bridge;
+child_bridge = child_bridge-next) {
unsigned link;
- child_bridge = dev-resource[i];
if (!(child_bridge-flags IORESOURCE_BRIDGE) ||
(child_bridge-flags type_mask) != type)
@@ -502,16 +503,15 @@
/* For each child which is a bridge, allocate_resources. */
for (dev = bus-children; dev; dev = dev-sibling) {
- unsigned i;
struct resource *child_bridge;
if (!dev-links)
continue;
/* Find the resources with matching type flags. */
- for (i = 0; i dev-resources; i++) {
+ for (child_bridge = dev-resource_list; child_bridge;
+child_bridge = child_bridge-next) {
unsigned link;
- child_bridge = dev-resource[i];
if (!(child_bridge-flags IORESOURCE_BRIDGE) ||
(child_bridge-flags type_mask) != type)
@@ -556,8 +556,7 @@
printk(BIOS_SPEW, %s: %s\n, __func__, dev_path(dev));
/* Constrain limits based on the fixed resources of this device. */
- for (i = 0; i dev-resources; i++) {
- res = dev-resource[i];
+ for (res = dev-resource_list; res; res = res-next) {
if (!(res-flags IORESOURCE_FIXED))
continue;
if (!res-size) {
@@ -604,7 +603,6 @@
{
struct constraints limits;
struct resource *res;
- int i;
printk(BIOS_SPEW, %s: %s\n, __func__, dev_path(dev));
/* Initialize constraints to maximum size. */
@@ -617,8 +615,7 @@
limits.mem.limit = 0xULL;
/* Constrain the limits to dev's initial resources. */
- for (i = 0; i dev-resources; i++) {
- res = dev-resource[i];
+ for (res = dev-resource_list; res; res = res-next) {
if ((res-flags IORESOURCE_FIXED))
continue;
printk(BIOS_SPEW, %s:@%s %02lx limit %08Lx\n, __func__,
@@ -638,9 +635,8 @@
constrain_resources(dev, limits);
/* Update dev's resources with new limits. */
- for (i = 0; i dev-resources; i++) {
+ for (res = dev-resource_list; res; res = res-next) {
struct resource *lim;
- res = dev-resource[i];
if ((res-flags IORESOURCE_FIXED))
continue;
@@ -764,7 +760,7 @@
dev_path(bus-dev),
Re: [coreboot] [PATCH] reduce the size of devices
On Fri, May 21, 2010 at 8:03 AM, Patrick Georgi patr...@georgi-clan.de wrote: Am 21.05.2010 01:08, schrieb Myles Watson: static void free_resource(device_t dev, struct resource *res, struct resource *prev) ... + res-next = free_resources; + free_resources = res-next; Shouldn't that be + res-next = free_resources; + free_resources = res; to add res to the free_resources? Yes. Thanks for catching it. It's too bad to leak the memory you're saving :) Fixed. Other than that, this is great! Smaller, cleaner, faster code, that uses less memory to achieve the same result - wonderful! Thanks. If we do the same thing with links we could save another ~150 bytes per device. There are 8 links per device when few of them have any at all. With the above thing cleared up, this is Acked-by: Patrick Georgi patrick.geo...@coresystems.de Rev 5576. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Indtast Bcc Wyse S10 and coreboot
Oliver Schinagl wrote: i think there might actually be more to testing erase, then just erasing via the normal flashrom. Well if I dump the flash after the erase again, it should be an empty rom and thus erase worked? flashrom always verifies all operations that change flash chip contents and will generate an error message and exit non-zero if something did not verify successfully. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] How to sent options via FILO
Joop Boonen wrote: I need to sent kernel boot options to the kernel. Does anyone know if this is possible, if so what is the syntax? Add them after the kernel and any initrd on the command line as usual. In GRUB mode I guess there's an append directive you can use. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fam10 error
coreboot-builds/amd_mahogany_fam10/make.log:src/cpu/amd/model_10xxx/fidvid.c:758:
warning: 'fid_max' may be used uninitialized in this function
static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid)
...
u32 fid_max;
...
/* fid setup is handled by the BSP at the end. */
} else {/* ! nb_cof_vid_update */
/* Use max values */
if (pvimode)
UpdateSinglePlaneNbVid();
}
send = (nb_cof_vid_update 16) | (fid_max 8);
send |= (apicid 24); // ap apicid
// Send signal to BSP about this AP max fid
// This also indicates this AP is ready for warm reset (if required).
lapic_write(LAPIC_MSG_REG, send | 1);
So we send garbage to the BSP for fid_max of the AP. What should we
be sending instead if !nb_cof_vid_update?
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FYI Cheap Rioworks HDAMA's
Yes nice but ships to US and Canada only. Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+ work
On May 20, 2010, at 6:48 PM, Eric W. Biederman wrote: ramdisk-base is just where in ram to load the ramdisk. mkelfImage defaults to 8M. You are setting it to 20M. With the change to kernels to default them to running at 16M that only leaves 4M for the kernel which I expect is to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem. 20M is indeed to small. The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk. -- Troy Telford ttelford.gro...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sony vgn-fz21n support
ahmet alper parker wrote: I have a usb to serial device, That is not useful for a target board without serial port. Please read http://www.coreboot.org/EHCI_Debug_Port (Maybe you already found it when searching for info on debug device?) which steps do I need to follow? Is there a link? No, there is no link. You must spend a lot of time learning to do it yourself. You can get help from the coreboot community but then you must ask very specific and detailed questions when you encounter a problem. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Promote heap sizing to first-class Kconfig citizenship.
On Fri, May 14, 2010 at 1:49 PM, Joe Korty joe.ko...@ccur.com wrote: Some background: The reason I'm looking at coreboot is that standard BIOSes (apparently) run out of memory while doing the bus walk, when I plug a PCI-e expansion chassis into the motherboard and populate it. The BIOS will either lock up or the OS will boot but what the OS sees for a PCI Bus (via lspci -tv) is clearly corrupt. So my job was/is to do an experiment to see if our problems are indeed due to out-of-memory issues in standard BIOSes, and if so, if coreboot could be a useful way around this issue. And indeed, the first time I booted coreboot with a populated PCI-e chassis attached, I got an out-of-memory halt from coreboot. Increasing CONFIG_HEAP_SIZE to 0x1 (ie, 4x) got the system to boot, and lspci -tv looks good also. I have yet to try intermediate values. Could you try the latest? Devices now take ~ 1/4 the space that they used to take. Unfortunately we have an even bigger PCI-e loaded expansion chassis (configuration #2), for which coreboot also hangs. It's not an out-of-memory hang; it happens (apparently) during the bus walk. I haven't looked into this hang in detail yet, so I don't have much to report. But I do fear it may be something more fundamental. If you send the log to the list we might be able to help. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] warnings
Fix a couple more warnings:
coreboot-builds/rca_rm4100/make.log:src/southbridge/intel/i82801dx/i82801dx_smihandler.c:452:
warning: redundant redeclaration of 'mainboard_smi_gpi'
coreboot-builds/via_vt8454c/make.log:src/arch/i386/include/arch/acpi.h:402:5:
warning: CONFIG_HAVE_ACPI_SLIC is not defined
coreboot-builds/getac_p470/make.log:src/mainboard/getac/p470/mainboard.c:83:
warning: assignment discards qualifiers from pointer target type
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/Kconfig
===
--- svn.orig/src/Kconfig
+++ svn/src/Kconfig
@@ -164,6 +164,10 @@ config ATI_RAGE_XL
source src/console/Kconfig
+config HAVE_ACPI_SLIC
+ bool
+ default n
+
config HAVE_ACPI_RESUME
bool
default n
Index: svn/src/mainboard/getac/p470/Kconfig
===
--- svn.orig/src/mainboard/getac/p470/Kconfig
+++ svn/src/mainboard/getac/p470/Kconfig
@@ -33,6 +33,7 @@ config BOARD_GETAC_P470
select GENERATE_MP_TABLE
select HAVE_HARD_RESET
select HAVE_ACPI_RESUME
+ select HAVE_ACPI_SLIC
select HAVE_MAINBOARD_RESOURCES
select MMCONF_SUPPORT
select USE_PRINTK_IN_CAR
@@ -88,9 +89,3 @@ config FALLBACK_VGA_BIOS_FILE
string
default getac-pci8086,27a2.rom
depends on BOARD_GETAC_P470
-
-config HAVE_ACPI_SLIC
- bool
- default y
- depends on BOARD_GETAC_P470
-
Index: svn/src/mainboard/intel/d945gclf/Kconfig
===
--- svn.orig/src/mainboard/intel/d945gclf/Kconfig
+++ svn/src/mainboard/intel/d945gclf/Kconfig
@@ -88,9 +88,3 @@ config MAX_PHYSICAL_CPUS
int
default 2
depends on BOARD_INTEL_D945GCLF
-
-config HAVE_ACPI_SLIC
- bool
- default n
- depends on BOARD_INTEL_D945GCLF
-
Index: svn/src/mainboard/kontron/986lcd-m/Kconfig
===
--- svn.orig/src/mainboard/kontron/986lcd-m/Kconfig
+++ svn/src/mainboard/kontron/986lcd-m/Kconfig
@@ -65,9 +65,3 @@ config FALLBACK_VGA_BIOS_FILE
string
default amipci_01.20
depends on BOARD_KONTRON_986LCD_M
-
-config HAVE_ACPI_SLIC
- bool
- default n
- depends on BOARD_KONTRON_986LCD_M
-
Index: svn/src/mainboard/roda/rk886ex/Kconfig
===
--- svn.orig/src/mainboard/roda/rk886ex/Kconfig
+++ svn/src/mainboard/roda/rk886ex/Kconfig
@@ -62,9 +62,3 @@ config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
hex
default 0x6886
depends on BOARD_RODA_RK886EX
-
-config HAVE_ACPI_SLIC
- bool
- default n
- depends on BOARD_RODA_RK886EX
-
Index: svn/src/mainboard/getac/p470/hda_verb.h
===
--- svn.orig/src/mainboard/getac/p470/hda_verb.h
+++ svn/src/mainboard/getac/p470/hda_verb.h
@@ -95,6 +95,6 @@ static const u32 mainboard_cim_verb_data
0x01F71F41,
};
-extern u32 * cim_verb_data;
+extern const u32 * cim_verb_data;
extern u32 cim_verb_data_size;
Index: svn/src/southbridge/intel/i82801gx/i82801gx_azalia.c
===
--- svn.orig/src/southbridge/intel/i82801gx/i82801gx_azalia.c
+++ svn/src/southbridge/intel/i82801gx/i82801gx_azalia.c
@@ -90,10 +90,10 @@ no_codec:
return 0;
}
-u32 * cim_verb_data = NULL;
+const u32 * cim_verb_data = NULL;
u32 cim_verb_data_size = 0;
-static u32 find_verb(struct device *dev, u32 viddid, u32 ** verb)
+static u32 find_verb(struct device *dev, u32 viddid, const u32 ** verb)
{
int idx=0;
@@ -166,7 +166,7 @@ static int wait_for_valid(u32 base)
static void codec_init(struct device *dev, u32 base, int addr)
{
u32 reg32;
- u32 *verb;
+ const u32 *verb;
u32 verb_size;
int i;
Index: svn/src/southbridge/intel/i82801dx/i82801dx_smihandler.c
===
--- svn.orig/src/southbridge/intel/i82801dx/i82801dx_smihandler.c
+++ svn/src/southbridge/intel/i82801dx/i82801dx_smihandler.c
@@ -449,8 +449,6 @@ static void southbridge_smi_gpe0(unsigne
dump_gpe0_status(gpe0_sts);
}
-void __attribute__((weak)) mainboard_smi_gpi(u16 gpi_sts);
-
static void southbridge_smi_gpi(unsigned int node, smm_state_save_area_t *state_save)
{
u16 reg16;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Improve i82830 MBI SMI Handler
Joseph Smith wrote: This patch improves the i82830 MBI SMI Handler. It is now able to load Intel vbios VBT and Flexaim modules. Build and boot tested. Signed-off-by: Joseph Smith j...@settoplinux.org One issue, but other than that it is Acked-by: Peter Stuge pe...@stuge.se +++ src/northbridge/intel/i82830/i82830_smihandler.c (working copy) @@ -32,7 +32,7 @@ extern unsigned char *mbi; extern u32 mbi_len; -// #define DEBUG_SMI_I82830 +#define DEBUG_SMI_I82830 Really enable debugging here by default? Should this maybe come from Kconfig somehow. It could e.g. depend on some existing value in Kconfig. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Indtast Bcc Indtast Bcc Indtast Bcc Wyse S10 and coreboot
Oliver Schinagl wrote: For coreboot al you need to do is pick s50 as the board, pick the right Rom size, point to the payload. The romsize defaults to 256k but according to flashrom (And the markings on the chip) it's a 2mb flash unit? On component level all storage is counted in bits. 2MBits=256Kbyte. flashrom should always use the byte size, where did it report Mbit? Also there's a lot of VGA, VSA and other settings that where very confusing as I read somewhere on the wiki; that the Geode GX2/LX don't support VGA things? And the VSA bit, I found that there is OpenVSA but it's highly experimental? Do I need it at all? Get the gplvsa blob from Marc. I don't recall if OpenVSA has been verified to work yet. Searching for vsa on the coreboot wiki gives hits for other systems using Geode, and one of them has the link to this latest version of gplvsa: http://marcjonesconsulting.com/gplvsa/gpl_vsa_lx_102.bin.gz (The older version 1.01 is at AMD: http://www.amd.com/files/connectivitysolutions/geode/geode_lx/amd_vsa_lx_1.01.bin.gz this was also linked from the wiki.) //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work
ramdisk-base is just where in ram to load the ramdisk. mkelfImage defaults to 8M. You are setting it to 20M. With the change to kernels to default them to running at 16M that only leaves 4M for the kernel which I expect is to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem. 20M is indeed to small. My understanding is that 20M is a location, not a size. The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk. Because the kernel is looking at 20M and you moved it to 32M? It seems like you need to adjust something else in your process to move the location of the kernel or initrd, or make the kernel smaller so that 16M + kernel 20M. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fam10 error
It should be initialized to 0. The !nb_cof_vid_update would mean that
the fidmax shouldn't change so the value isn't important, but 0 would
be the safest if there is another hole in the logic and CPUs are not
matched.
Marc
On Fri, May 21, 2010 at 9:41 AM, Myles Watson myle...@gmail.com wrote:
coreboot-builds/amd_mahogany_fam10/make.log:src/cpu/amd/model_10xxx/fidvid.c:758:
warning: 'fid_max' may be used uninitialized in this function
static void init_fidvid_ap(u32 bsp_apicid, u32 apicid, u32 nodeid, u32 coreid)
...
u32 fid_max;
...
/* fid setup is handled by the BSP at the end. */
} else { /* ! nb_cof_vid_update */
/* Use max values */
if (pvimode)
UpdateSinglePlaneNbVid();
}
send = (nb_cof_vid_update 16) | (fid_max 8);
send |= (apicid 24); // ap apicid
// Send signal to BSP about this AP max fid
// This also indicates this AP is ready for warm reset (if required).
lapic_write(LAPIC_MSG_REG, send | 1);
So we send garbage to the BSP for fid_max of the AP. What should we
be sending instead if !nb_cof_vid_update?
Thanks,
Myles
--
http://se-eng.com
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5576 - in trunk: src/devices src/devices/oprom/yabel src/drivers/ati/ragexl src/include/device src/northbridge/amd/amdfam10 src/northbridge/amd/amdk8 src/northbridge/amd/gx2 s
repository service wrote: Author: myles Log: Use lists instead of arrays for resources in devices to reduce memory usage. Great work! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5577 - trunk/src/cpu/amd/model_10xxx
Author: myles Date: Fri May 21 19:15:55 2010 New Revision: 5577 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5577 Log: Get rid of this warning: src/cpu/amd/model_10xxx/fidvid.c:758: warning: 'fid_max' may be used uninitialized in this function Quoting Marc: It [fid_max] should be initialized to 0. The !nb_cof_vid_update would mean that the fidmax shouldn't change so the value isn't important, but 0 would be the safest if there is another hole in the logic and CPUs are not matched. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Myles Watson myle...@gmail.com Modified: trunk/src/cpu/amd/model_10xxx/fidvid.c Modified: trunk/src/cpu/amd/model_10xxx/fidvid.c == --- trunk/src/cpu/amd/model_10xxx/fidvid.c Fri May 21 16:33:48 2010 (r5576) +++ trunk/src/cpu/amd/model_10xxx/fidvid.c Fri May 21 19:15:55 2010 (r5577) @@ -755,7 +755,7 @@ struct fidvid_st fv; device_t dev; u32 vid_max; - u32 fid_max; + u32 fid_max=0; u8 nb_cof_vid_update; u32 reg1fc; u8 pvimode; -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fam10 error
On Fri, May 21, 2010 at 11:08 AM, Marc Jones marcj...@gmail.com wrote: It should be initialized to 0. The !nb_cof_vid_update would mean that the fidmax shouldn't change so the value isn't important, but 0 would be the safest if there is another hole in the logic and CPUs are not matched . Rev 5577. Thanks, Myles On Fri, May 21, 2010 at 9:41 AM, Myles Watson myle...@gmail.com wrote: coreboot-builds/amd_mahogany_fam10/make.log:src/cpu/amd/model_10xxx/fidvid.c:758: warning: 'fid_max' may be used uninitialized in this function So we send garbage to the BSP for fid_max of the AP. What should we be sending instead if !nb_cof_vid_update? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Improve i82830 MBI SMI Handler
On 5/21/10 7:25 AM, Joseph Smith wrote: This patch improves the i82830 MBI SMI Handler. It is now able to load Intel vbios VBT and Flexaim modules. Build and boot tested. Signed-off-by: Joseph Smith j...@settoplinux.org God catch... However, please don't commit this... it breaks the implementation of MBI, the code should stay completely module agnostic. There should be a solution that works without adding an exception for every module supported (plus, I think the rules are based on the length of the name, so any module 203 and 204 with different names will break your assumptions. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work
Myles Watson myle...@gmail.com writes: ramdisk-base is just where in ram to load the ramdisk. mkelfImage defaults to 8M. You are setting it to 20M. With the change to kernels to default them to running at 16M that only leaves 4M for the kernel which I expect is to little. Because mkelfImage is old and the hack is crude I don't mkelfImage is to stupid to realize that we have a problem. 20M is indeed to small. My understanding is that 20M is a location, not a size. Yes. The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk. Because the kernel is looking at 20M and you moved it to 32M? No. These are the parameters passed to the kernel. What I have seen in the past is the ramdisk being loaded close enough to the kernel that the kernel stomps it, and corrupts it in early startup. This should be diagnosable by looking at the boot up messages from the kernel startup. Eric -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work
20M is indeed to small. My understanding is that 20M is a location, not a size. Yes. The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk. Because the kernel is looking at 20M and you moved it to 32M? No. These are the parameters passed to the kernel. What I have seen in the past is the ramdisk being loaded close enough to the kernel that the kernel stomps it, and corrupts it in early startup. This should be diagnosable by looking at the boot up messages from the kernel startup. Sorry I misunderstood. I'm surprised that 16M wasn't enough room to keep the kernel from overwriting the initrd. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Indtast Bcc Indtast Bcc Wyse S10 and coreboot
On 05/21/10 16:31, Ward Vandewege wrote: On Fri, May 21, 2010 at 08:08:17AM +0200, Oliver Schinagl wrote: On 05/21/2010 07:50 AM, and...@jenbo.dk wrote: Also check out the required tool chain here coreboot.org/Development_Guidelines I checked those and I have everything on my Ubuntu laptop, except pciutils-dev package. Seems like it doesn't exist. I checked through the sources and there weren't many header files included; Which files from pciutils-dev are needed that wouldn't be in a pciutils package? Hmm, apparently the package has been renamed to libpci-dev since Intrepid, and they dropped the virtual pciutils-dev package that refers to libpci-dev in Lucid. I've put a note to that effect on the wiki, too. Thanks, Ward. yeah, I found it and installed it :) Thanks! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] PCI IO Address space over 0xffff
On Fri, May 21, 2010 at 12:10:51PM -0400, Myles Watson wrote: On Fri, May 14, 2010 at 1:49 PM, Joe Korty joe.ko...@ccur.com wrote: Unfortunately we have an even bigger PCI-e loaded expansion chassis (configuration #2), for which coreboot also hangs. It's not an out-of-memory hang; it happens (apparently) during the bus walk. ?I haven't looked into this hang in detail yet, so I don't have much to report. ?But I do fear it may be something more fundamental. If you send the log to the list we might be able to help. Hi Myles, I've solved this one, kind of. It is PCI IO Space overflow, we are going over 0x which apparently is a hard limit. I image this is there so that inb, outw, etc instructions can be used to reference these devices. But if one doesn't use such instructions (instead using memory mapped PCI IO space), I see no reason why Linux and coreboot couldn't work with PCI IO Space addresses 0x. Regards, Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Improve i82830 MBI SMI Handler
On 05/21/2010 03:17 PM, Stefan Reinauer wrote: On 5/21/10 7:25 AM, Joseph Smith wrote: This patch improves the i82830 MBI SMI Handler. It is now able to load Intel vbios VBT and Flexaim modules. Build and boot tested. Signed-off-by: Joseph Smith j...@settoplinux.org God catch... However, please don't commit this... it breaks the implementation of MBI, the code should stay completely module agnostic. There should be a solution that works without adding an exception for every module supported (plus, I think the rules are based on the length of the name, so any module 203 and 204 with different names will break your assumptions. Hmm. I have gone through a bunch of VBT's (type 203) and dozens of Flexaims (type 204) (every version available). All the VBT's (type 203) have the same data structure of a certain size and all the Flexaims (type 204) have the same data structures of a certain size. The sizes of the data structures are different. With the existing code you can get one or the other working but not both. Hence the type switch to distinguish between the two data structure sizes. As far as I have seen for the i830 these are the only two types of MBI modules, VBT's (type 203) and Flexaims (type 204). Unfortunately i don't know what the implementation of MBI is supposed to look like, I am just going by what works (thinking outside the box). If you have a completely module agnostic way to determine the different data structure sizes, I am all ears. I think the rules are based on the length of the name, so any module 203 and 204 with different names will break your assumptions. No, it shouldn't. All VBT's (type 203) only have VBT as the name and The way I setup the name for Flexaims (type 204) is based on the name_len so it is actually module agnostic. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work
Myles Watson myle...@gmail.com writes: 20M is indeed to small. My understanding is that 20M is a location, not a size. Yes. The ramdisk (incl. kernel modules) is on the order of 26M; I've tried setting it to 32M - this setting is what allows the kernel to actually start; however (as previously mentioned), the kernel is unable to mount the ramdisk. Because the kernel is looking at 20M and you moved it to 32M? No. These are the parameters passed to the kernel. What I have seen in the past is the ramdisk being loaded close enough to the kernel that the kernel stomps it, and corrupts it in early startup. This should be diagnosable by looking at the boot up messages from the kernel startup. Sorry I misunderstood. I'm surprised that 16M wasn't enough room to keep the kernel from overwriting the initrd. I am a bit surprised as well. It smells a bit like a kernel bug. To the wider audience I have a question. How do most folks making coreboot images use mkelfImage? With an uncompressed vmlinux? With a bzImage? At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot. Eric -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI IO Address space over 0xffff
If you send the log to the list we might be able to help. Hi Myles, I've solved this one, kind of. It is PCI IO Space overflow, we are going over 0x which apparently is a hard limit. I image this is there so that inb, outw, etc instructions can be used to reference these devices. But if one doesn't use such instructions (instead using memory mapped PCI IO space), I see no reason why Linux and coreboot couldn't work with PCI IO Space addresses 0x. The resource allocator doesn't care. Just find the places where the I/O flag is checked and the limit is set to 0x and try setting it larger. I would look in src/devices/pci_device.c and src/northbridge/your_northbridge/northbridge.c first. I'm not sure what will break, but we should be able to fix it pretty easily. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5578 - trunk/src/northbridge/amd/amdk8
Author: oxygene
Date: Fri May 21 22:36:47 2010
New Revision: 5578
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5578
Log:
Fix amdk8_util.asl and explain behaviour a bit.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Patrick Georgi patrick.geo...@coresystems.de
Modified:
trunk/src/northbridge/amd/amdk8/amdk8_util.asl
Modified: trunk/src/northbridge/amd/amdk8/amdk8_util.asl
==
--- trunk/src/northbridge/amd/amdk8/amdk8_util.asl Fri May 21 19:15:55
2010(r5577)
+++ trunk/src/northbridge/amd/amdk8/amdk8_util.asl Fri May 21 22:36:47
2010(r5578)
@@ -84,6 +84,7 @@
Return (Local0)
}
+ /* GetBus(Node, Link) */
Method (GBUS, 2, NotSerialized)
{
Store (0x00, Local0)
@@ -107,6 +108,7 @@
Return (0x00)
}
+ /* GetBusResources(Node, Link) */
Method (GWBN, 2, NotSerialized)
{
Name (BUF0, ResourceTemplate ()
@@ -146,6 +148,7 @@
Return (RTAG (BUF0))
}
+ /* GetMemoryResources(Node, Link) */
Method (GMEM, 2, NotSerialized)
{
Name (BUF0, ResourceTemplate ()
@@ -166,22 +169,25 @@
Store (0x00, Local3)
While (LLess (Local0, 0x10))
{
+ /* Get value of the first register */
Store (DerefOf (Index (\_SB.PCI0.MMIO, Local0)), Local1)
Increment (Local0)
Store (DerefOf (Index (\_SB.PCI0.MMIO, Local0)), Local2)
- If (LEqual (And (Local1, 0x03), 0x03))
+ If (LEqual (And (Local1, 0x03), 0x03)) /* Pair enabled?
*/
{
- If (LEqual (Arg0, And (Local2, 0x07)))
+ If (LEqual (Arg0, And (Local2, 0x07))) /* Node
matches? */
{
+ /* If Link Matches (or we got passed
0xFF) */
If (LOr (LEqual (Arg1, 0xFF), LEqual
(Arg1, ShiftRight (And (Local2, 0x30), 0x04
{
+ /* Extract the Base and Limit
values */
Store (ShiftLeft (And (Local1,
0xFF00), 0x08), MMIN)
Store (ShiftLeft (And (Local2,
0xFF00), 0x08), MMAX)
Or (MMAX, 0x, MMAX)
Subtract (MMAX, MMIN, MLEN)
Increment (MLEN)
- If (Local4)
+ If (Local4) /* I've already
done this once */
{
Concatenate (RTAG
(BUF0), Local3, Local5)
Store (Local5, Local3)
@@ -199,14 +205,15 @@
Increment (Local0)
}
- If (LNot (Local4))
+ If (LNot (Local4)) /* No resources for this node and link. */
{
- Store (BUF0, Local3)
+ Store (RTAG (BUF0), Local3)
}
Return (Local3)
}
+ /* GetIOResources(Node, Link) */
Method (GIOR, 2, NotSerialized)
{
Name (BUF0, ResourceTemplate ()
@@ -230,19 +237,21 @@
Store (DerefOf (Index (\_SB.PCI0.PCIO, Local0)), Local1)
Increment (Local0)
Store (DerefOf (Index (\_SB.PCI0.PCIO, Local0)), Local2)
- If (LEqual (And (Local1, 0x03), 0x03))
+ If (LEqual (And (Local1, 0x03), 0x03)) /* Pair enabled?
*/
{
- If (LEqual (Arg0, And (Local2, 0x07)))
+ If (LEqual (Arg0, And (Local2, 0x07))) /* Node
matches? */
{
+ /* If Link Matches (or we got passed
0xFF) */
If (LOr (LEqual (Arg1, 0xFF), LEqual
(Arg1, ShiftRight (And (Local2, 0x30), 0x04
{
+ /* Extract the Base and Limit
values */
Store (And (Local1,
0x01FFF000), PMIN)
Store (And (Local2,
0x01FFF000), PMAX)
Or (PMAX, 0x0FFF, PMAX)
Subtract (PMAX, PMIN, PLEN)
[coreboot] [commit] r5579 - in trunk/src/mainboard: amd/dbm690t amd/mahogany amd/mahogany_fam10 amd/pistachio amd/serengeti_cheetah amd/serengeti_cheetah/acpi amd/serengeti_cheetah_fam10 amd/serengeti
Author: oxygene
Date: Fri May 21 22:40:38 2010
New Revision: 5579
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5579
Log:
Add reasonable values in ASL at places we overwrite from
coreboot later. Current ASL compilers check for validity
and complain about the dummy values.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Patrick Georgi patrick.geo...@coresystems.de
Modified:
trunk/src/mainboard/amd/dbm690t/dsdt.asl
trunk/src/mainboard/amd/mahogany/dsdt.asl
trunk/src/mainboard/amd/mahogany_fam10/dsdt.asl
trunk/src/mainboard/amd/pistachio/dsdt.asl
trunk/src/mainboard/amd/serengeti_cheetah/acpi/amd8111_isa.asl
trunk/src/mainboard/amd/serengeti_cheetah/dsdt.asl
trunk/src/mainboard/amd/serengeti_cheetah_fam10/acpi/amd8111_isa.asl
trunk/src/mainboard/amd/serengeti_cheetah_fam10/dsdt.asl
trunk/src/mainboard/amd/tilapia_fam10/dsdt.asl
trunk/src/mainboard/asrock/939a785gmh/dsdt.asl
trunk/src/mainboard/iwill/dk8_htx/acpi/amd8111_isa.asl
trunk/src/mainboard/iwill/dk8_htx/dsdt.asl
trunk/src/mainboard/kontron/kt690/dsdt.asl
trunk/src/mainboard/technexion/tim5690/dsdt.asl
trunk/src/mainboard/technexion/tim8690/dsdt.asl
Modified: trunk/src/mainboard/amd/dbm690t/dsdt.asl
==
--- trunk/src/mainboard/amd/dbm690t/dsdt.aslFri May 21 22:36:47 2010
(r5578)
+++ trunk/src/mainboard/amd/dbm690t/dsdt.aslFri May 21 22:40:38 2010
(r5579)
@@ -1348,10 +1348,10 @@
Name(_CRS, ResourceTemplate() {
DMA(Compatibility,BusMaster,Transfer8){4}
IO(Decode16, 0x, 0x,
0x10, 0x10)
- IO(Decode16, 0x0081, 0x0081,
0x10, 0x03)
- IO(Decode16, 0x0087, 0x0087,
0x10, 0x01)
- IO(Decode16, 0x0089, 0x0089,
0x10, 0x03)
- IO(Decode16, 0x008F, 0x008F,
0x10, 0x01)
+ IO(Decode16, 0x0081, 0x0081,
0x01, 0x03)
+ IO(Decode16, 0x0087, 0x0087,
0x01, 0x01)
+ IO(Decode16, 0x0089, 0x0089,
0x01, 0x03)
+ IO(Decode16, 0x008F, 0x008F,
0x01, 0x01)
IO(Decode16, 0x00C0, 0x00C0,
0x10, 0x20)
}) /* End
Name(_SB.PCI0.LpcIsaBr.MAD._CRS) */
} /* End Device(_SB.PCI0.LpcIsaBr.MAD) */
@@ -1502,29 +1502,29 @@
0x, /* Min */
0x, /* Max */
0x, /* Translation
*/
- 0x, /* Max-Min,
RLEN */
+ 0x0001, /* Max-Min,
RLEN */
,,
PCBM
)
/* DRAM memory from 4GB to TopMem2 */
QWORDMemory(ResourceProducer, PosDecode,
MinFixed, MaxFixed, Cacheable, ReadWrite,
- 0x, /* Granularity
*/
- 0x, /* Min */
+ 0x, /* Granularity
*/
+ 0x, /* Min */
0x, /* Max */
0x, /* Translation
*/
- 0x, /* Max-Min,
RLEN */
+ 0x0001, /* Max-Min,
RLEN */
,,
DMHI
)
/* BIOS space just below 16EB */
QWORDMemory(ResourceProducer, PosDecode,
MinFixed, MaxFixed, Cacheable, ReadWrite,
- 0x, /* Granularity
*/
+ 0x, /* Granularity
*/
0x, /* Min */
- 0x, /* Max */
+ 0x, /* Max */
0x, /* Translation
*/
- 0x, /* Max-Min,
RLEN */
+
Re: [coreboot] [PATCH] Improve i82830 MBI SMI Handler
On 05/21/2010 03:17 PM, Stefan Reinauer wrote: On 5/21/10 7:25 AM, Joseph Smith wrote: This patch improves the i82830 MBI SMI Handler. It is now able to load Intel vbios VBT and Flexaim modules. Build and boot tested. Signed-off-by: Joseph Smith j...@settoplinux.org God catch... However, please don't commit this... it breaks the implementation of MBI, the code should stay completely module agnostic. There should be a solution that works without adding an exception for every module supported (plus, I think the rules are based on the length of the name, so any module 203 and 204 with different names will break your assumptions. Even the existing code is not completely module agnostic. There are little + _some_number_ through out the code to adjust the data structure sizes... -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Improve i82830 MBI SMI Handler
On 05/21/2010 12:27 PM, Peter Stuge wrote: Joseph Smith wrote: This patch improves the i82830 MBI SMI Handler. It is now able to load Intel vbios VBT and Flexaim modules. Build and boot tested. Signed-off-by: Joseph Smithj...@settoplinux.org One issue, but other than that it is Acked-by: Peter Stugepe...@stuge.se +++ src/northbridge/intel/i82830/i82830_smihandler.c(working copy) @@ -32,7 +32,7 @@ extern unsigned char *mbi; extern u32 mbi_len; -// #define DEBUG_SMI_I82830 +#define DEBUG_SMI_I82830 Really enable debugging here by default? Should this maybe come from Kconfig somehow. It could e.g. depend on some existing value in Kconfig. Oops, thanks for the catch. I was actually going to use Kconfig to enable it in the next patch. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI IO Address space over 0xffff
Hi Joe, On 21.05.2010 22:07, Joe Korty wrote: On Fri, May 21, 2010 at 12:10:51PM -0400, Myles Watson wrote: On Fri, May 14, 2010 at 1:49 PM, Joe Korty joe.ko...@ccur.com wrote: Unfortunately we have an even bigger PCI-e loaded expansion chassis (configuration #2), for which coreboot also hangs. It's not an out-of-memory hang; it happens (apparently) during the bus walk. ?I haven't looked into this hang in detail yet, so I don't have much to report. ?But I do fear it may be something more fundamental. If you send the log to the list we might be able to help. I've solved this one, kind of. It is PCI IO Space overflow, we are going over 0x which apparently is a hard limit. I image this is there so that inb, outw, etc instructions can be used to reference these devices. But if one doesn't use such instructions (instead using memory mapped PCI IO space), I see no reason why Linux and coreboot couldn't work with PCI IO Space addresses 0x. I'm interested in how you want to map port IO space to memory. Please explain. AFAIK PCI register space is totally independent of port IO space which is totally independent of memory space. You can access PCI register space via CF8/CFC port IO and via MMCONFIG memory, but I'm unaware of any mechanisms to map IO ports to memory or the other way round. Thanks, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work
On Fri, May 21, 2010 at 1:22 PM, Eric W. Biederman ebied...@xmission.com wrote: Myles Watson myle...@gmail.com writes: At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot. The last time I used it I used vmlinux, because we can lzma compress the whole elfimage when done merging in the other its (initrd etc.). I can't see any reason that your mandate would cause trouble, but it might slow things down a bit with two uncompress steps, one not needed. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Which machine is good for developing on coreboot?
Hi all, I am a PhD student at a university and working on a research project which needs to modify the BIOS. Since most BIOS are close sourced, I choose the coreboot as the developing environment and thanks for providing such a good open source “BIOS”. Most of the existing computers in my lab are kind of new and Intel CPU based DELL desktop or servers. I guess they are not supported by coreboot. Therefore, I want to buy a new machine (my advisor will pay for that :) ) which is already well-supported by coreboot for developing, and I need your suggestions of which machine(x86 based desktop or workstation) is a good candidate. (Another reason I don’t like Intel based machine is that their documentation is poor compared to AMD. ) I have following requirements for the new machine. 1) Fully supported by coreboot. Especially, I want following support 2) Support Windows (XP) and Linux 3) Support ACPI S3 sleep (suspend to RAM) 4) Good documentation about how to detect and configure the memory (because I will modify this part for our project). I read coreboot Wiki and found out most supported parts are separated, such as CPU, motherboard, NB, SB, etc. Does that mean I need to buy all the parts and assemble the machine by myself? It is OK, but if there is some vendor providing a whole computer would be better. Or I guess I just need a good motherboard, any suggestions? Also, I prefer to buy an AMD K8 or K10 machine. Could someone recommend which main board should I use? I see “Pistachio” and “Tilapia” in the supported motherboard wiki, but I don’t know where I can buy those boards? Thanks. PS: I am new to BIOS development but have some experience in Linux and Window device driver. Regards, Jiang -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] mkelfImage: set kernel_alignment so 2.6.31+work
ron minnich rminn...@gmail.com writes: On Fri, May 21, 2010 at 1:22 PM, Eric W. Biederman ebied...@xmission.com wrote: Myles Watson myle...@gmail.com writes: At the moment I want to mandate a bzImage for x86, but I'm not certain if that is practical the way we build images for coreboot. The last time I used it I used vmlinux, because we can lzma compress the whole elfimage when done merging in the other its (initrd etc.). I can't see any reason that your mandate would cause trouble, but it might slow things down a bit with two uncompress steps, one not needed. There are also size issues. I think I need to ensure that linux builds a bImage. So that you can have an uncompress bzImage. For this embedded case. Eric -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Promote heap sizing to first-class Kconfig citizenship.
I wrote: Unfortunately, the latest coreboot still gets an out-of-mem condition when the large pci-e chassis is attached. I've attached two coreboot logs, both are the latest svn but the second one has heap size at 0x1 so that I can send you the log of what a good boot might look like. On Fri, May 21, 2010 at 04:33:12PM -0400, Myles Watson wrote: That's a lot of devices. So maybe we need a Kconfig option called ADDITIONAL_HEAP that's available on the EXPERT menu. It's possible that making links into lists will make you fit, but I'd expect someone to shrink the default heap when there's that much extra space for everyone else. I certainly think that that would be OK. It is impractical to come up with a default heap size to cover the largest possible IO configuration, since that would be very large indeed. Heck, even my failing large IO configuration is not really very large. I am putting only one expansion chassis on the system. I expect that we will eventually get customers that will want two or even three expansion chassis (each chassis holds 20 PCI-e cards). In one sense this is kinda exciting. Mainframes have always been about large IO. That's what distinguishes them from PCs. With these tweaks, PC-like machines can start to eat away at the bottom of that market. Regards, Joe Joe -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PCI IO Address space over 0xffff
Joe Korty wrote: I've solved this one, kind of. It is PCI IO Space overflow, we are going over 0x which apparently is a hard limit. On x86 it is very much a hard limit. Not so on other architectures. I image this is there so that inb, outw, etc instructions can be used to reference these devices. But if one doesn't use such instructions (instead using memory mapped PCI IO space), The feasibility of that is totally device dependent. PCI devices can expose all combinations of I/O and memory, and only the device driver knows which one to use how. I see no reason why Linux and coreboot couldn't work with PCI IO Space addresses 0x. The I/O opcodes on x86 are limited to 16 bit addresses. Since this is part of the architecture, both Linux and coreboot make this assumption on x86 systems. Joe Korty wrote: Heck, even my failing large IO configuration is not really very large. I am putting only one expansion chassis on the system. Either you are just totally out of luck with the I/O space situation, or there is room for improvement in coreboot. Not at all impossible. What cards did you have in this expansion chassis? Would it be possible for you to provide lspci -vv output on that system? Does the system boot if the chassis is completely empty? I expect that we will eventually get customers that will want two or even three expansion chassis (each chassis holds 20 PCI-e cards). How do the chassis connect upstream, on PCI level? How does that upstream-facing component divide address space? Does it reserve a chunk for everything that can connect downstream? How big a chunk? In one sense this is kinda exciting. Mainframes have always been about large IO. That's what distinguishes them from PCs. With these tweaks, PC-like machines can start to eat away at the bottom of that market. Only if 16 bits is enough for all I/O BARs that the plugged-in cards need. Maybe the allocation algorithm in coreboot can be optimized to pack things better into those 16 bits, but worst case you've simply hit an architecture limitation with x86. :\ //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
