Re: [coreboot] SeaBIOS and USB UHCI keyboard support
Its really a great news!!!. I will test this on my hardware (Intel Atom (Silverthorne) SCH US15W (Poulsbo) chipset) A dumb question here... Why SeaBIOS have constrains? Can't we elaborate SeaBIOS as a driver part of coreboot? I mean a legacy BIOS interrupts part(with constrains) + a driver section (includes support for various drivers like USB keyboard USB mouse USB CDROM Hard disk etc) without any constrains so that we can make use of current implementations from Linux or other open source Do you have any plan to support USB CD-ROM ? -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Kevin O'Connor Sent: Wednesday, September 30, 2009 6:24 AM To: Stefan Reinauer Cc: coreboot Subject: Re: [coreboot] SeaBIOS and USB UHCI keyboard support Hi Stefan, On Tue, Sep 29, 2009 at 04:47:04PM +0200, Stefan Reinauer wrote: Kevin O'Connor wrote: The latest SeaBIOS git has preliminary support for USB keyboards. I've tested this on qemu and on my epia-cn. Would it not make sense to pack USB keyboard functionality into our GSoC project instead, and use one common USB stack for all our projects? Especially since this renders usbrom completely unusable; no two USB stacks can operate the hw reliably at the same time. I'm a bit surprised by such action. I'm sorry you were surprised. I sent a note last month that I was going to look at this. I am truly sorry for the surprise and for any disappointment. SeaBIOS needs USB support in order to be usable on many platforms. I want SeaBIOS to be a turn key solution - that is, I want a vendor to be able to boot up coreboot+seabios and say, hey, this 'just works'. I would prefer to pull in an external solution than implement a new one. Unfortunately, there isn't an external solution that works today. I looked closely at the libpayload code; I felt it would not work well in the constrained environment that SeaBIOS runs in. I believe libpayload could be extended to support that constrained environment, but I worry that would be an unnecessary burden on the other users of libpayload (which aren't so constrained). The support in SeaBIOS is currently 1029 lines of code - it is a direct, no nonsense, just make it work implementation. Are you planning to add USB MSC support as well? Should we stop the OHCI efforts too and wait for your approach on that? If someone steps forward with a solution that just works, then I will happily defer to that person. Otherwise, I will continue to add new features as I get time. The next thing I am planning to look at is basic ohci keyboard support, and then fleshing out the current keyboard support (eg, auto-repeat, keyboard leds). -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot --- DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. -- --- DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. -- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is this motherboard suppo
Hi, On 30.09.2009 11:53, Anonymous bin ich wrote: I do have a serial port, but I lack absolutely all knowledge to recover it something bad happens. Guess I will wait for some more time. Do you know of any laptop, which, while not supported, at least has good parts? (complete noob here) So far, I know of no laptop with completely open/available docs. Either the docs are unavailable or they require NDAs which most of us don't have. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4692 - trunk/coreboot-v2/util/cbfstool
Author: oxygene
Date: 2009-09-30 13:21:18 +0200 (Wed, 30 Sep 2009)
New Revision: 4692
Modified:
trunk/coreboot-v2/util/cbfstool/cbfstool.c
trunk/coreboot-v2/util/cbfstool/common.c
Log:
Fix endless loop when trying to add a too large file to CBFS,
and report the correct error code, and a hopefully helpful
error message.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified: trunk/coreboot-v2/util/cbfstool/cbfstool.c
===
--- trunk/coreboot-v2/util/cbfstool/cbfstool.c 2009-09-29 21:35:48 UTC (rev
4691)
+++ trunk/coreboot-v2/util/cbfstool/cbfstool.c 2009-09-30 11:21:18 UTC (rev
4692)
@@ -80,7 +80,8 @@
}
cbfsfile =
create_cbfs_file(cbfsname, filedata, filesize, type, base);
- add_file_to_cbfs(cbfsfile, filesize, base);
+ if (add_file_to_cbfs(cbfsfile, filesize, base))
+ return 1;
writerom(romname, rom, romsize);
return 0;
}
@@ -127,7 +128,8 @@
cbfsfile =
create_cbfs_file(cbfsname, payload, filesize,
CBFS_COMPONENT_PAYLOAD, base);
- add_file_to_cbfs(cbfsfile, filesize, base);
+ if (add_file_to_cbfs(cbfsfile, filesize, base))
+ return 1;
writerom(romname, rom, romsize);
return 0;
}
@@ -175,7 +177,8 @@
create_cbfs_file(cbfsname, stage, filesize,
CBFS_COMPONENT_STAGE, base);
- add_file_to_cbfs(cbfsfile, filesize, base);
+ if (add_file_to_cbfs(cbfsfile, filesize, base))
+ return 1;
writerom(romname, rom, romsize);
return 0;
}
Modified: trunk/coreboot-v2/util/cbfstool/common.c
===
--- trunk/coreboot-v2/util/cbfstool/common.c2009-09-29 21:35:48 UTC (rev
4691)
+++ trunk/coreboot-v2/util/cbfstool/common.c2009-09-30 11:21:18 UTC (rev
4692)
@@ -40,7 +40,7 @@
content = malloc(*romsize_p);
if (!content) {
printf(Could not get %d bytes for file %s\n,
- *romsize_p, filename);
+ *romsize_p, filename);
exit(1);
}
} else if (place == SEEK_END)
@@ -205,40 +205,42 @@
dprintf(copying data\n);
memcpy(phys_to_virt(current), content,
contentsize);
- break;
+ return 0;
}
- if (location == 0)
- continue;
+ if (location != 0) {
+ /* CBFS has the constraint that the chain
always moves up in memory. so once
+ we're past the place we seek, we don't need
to look any further */
+ if (current location) {
+ printf
+ (the requested space is not
available\n);
+ return 1;
+ }
- /* CBFS has the constraint that the chain always moves
up in memory. so once
- we're past the place we seek, we don't need to look
any further */
- if (current location) {
- printf
- (the requested space is not available\n);
- return 1;
+ /* Is the requested location inside the current
chunk? */
+ if ((current location)
+((location + contentsize) =
+ (current + length))) {
+ /* Split it up. In the next iteration
the code will be at the right place. */
+ dprintf(split up. new length: %x\n,
+ location - current -
+ ntohl(thisfile-offset));
+ thisfile-len =
+ htonl(location - current -
+ ntohl(thisfile-offset));
+ struct cbfs_file *nextfile =
+ cbfs_create_empty_file(location,
+ length -
+ (location -
+ current));
+ }
}
-
-
[coreboot] build service results for r4692
Dear coreboot readers! This is the automatic build system of coreboot. The developer oxygene checked in revision 4692 to the coreboot repository. This caused the following changes: Change Log: Fix endless loop when trying to add a too large file to CBFS, and report the correct error code, and a hopefully helpful error message. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4692device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4692device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4692device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Corebootv2 failing to build
On Wed, Sep 30, 2009 at 7:15 AM, David Houston r...@crankyadmin.net wrote: Not sure why? Believe it has something to do with the bold. I am trying to build a 1mb rom. Where is the best place to set this? This file in targets/gigabyte/m57sli/Config.lb builds for me. - Myles target m57sli mainboard gigabyte/m57sli option CONFIG_HAVE_FAILOVER_BOOT=0 option CONFIG_FAILOVER_SIZE=0 option CONFIG_ROM_SIZE=0x10 romimage fallback option CONFIG_USE_FAILOVER_IMAGE=0 option CONFIG_USE_FALLBACK_IMAGE=1 option CONFIG_ROM_IMAGE_SIZE=0x1 option CONFIG_XIP_ROM_SIZE=0x4 option COREBOOT_EXTRA_VERSION=$(shell cat ../../VERSION)_Fallback payload ../payload.elf end buildrom ./coreboot.rom CONFIG_ROM_SIZE fallback -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resend: [PATCH] add h8dmr fam10 target
On Tue, Sep 22, 2009 at 03:29:05PM +0200, Peter Stuge wrote: Ward Vandewege wrote: Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912 fam10 and h8dmr k8 targets. Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with this, and to Arne for doing the s2912 fam10 port. Build and boot tested. Signed-off-by: Ward Vandewege w...@gnu.org Acked-by: Peter Stuge pe...@stuge.se r4693. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resend: [PATCH] add h8dmr fam10 target
On Tue, Sep 22, 2009 at 06:43:10AM -0700, ron minnich wrote: On Tue, Sep 22, 2009 at 6:42 AM, ron minnich rminn...@gmail.com wrote: I think this description of problems with the port ought to be in the target file in a README. ^^directory, sorry I have done so. I need to do some more testing on this hardware, but it's in production so that's a little hard right now. I'm going to work on a supermicro h8dme fam10 port now, which is a very similar board, so hopefully I'll be able to try the suggestions in this thread on that. Thanks! Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4693
Dear coreboot readers! This is the automatic build system of coreboot. The developer ward checked in revision 4693 to the coreboot repository. This caused the following changes: Change Log: Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912 fam10 and h8dmr k8 targets. Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with this, and to Arne for doing the s2912 fam10 port. Build and boot tested. Abuild tested. There are a number of outstanding issues and caveats - see src/mainboard/supermicro/h8dmr_fam10/README. Signed-off-by: Ward Vandewege w...@gnu.org Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4693device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4693device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4693device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in ward's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]Fix hopefully last stopper bug for CBFS. Plan to get rid of non-CBFS
Hi,
attached patch reworks the payload handling with CBFS (ie. selfboot).
We use a bounce buffer (both in CBFS and older) to keep coreboot running
while allowing the payload to use the same memory region, and this is a
tricky part of our code.
Assumptions in the code are:
The bounce buffer is at least 2x coreboot_ram size (lb_end - lb_start),
with the first half being the shadow region that the payload's data
lives in (exactly the bytes that cover the area of coreboot_ram), while
the second half exists to host a copy of coreboot while copying.
The change leads to the following behaviour:
At least 2x coreboot_ram size is looked for.
The area before the bounce buffer is assumed to be reasonably free (but
this isn't validated)
Payload segments that conflict with coreboot_ram are loaded to the
bounce buffer, probably using the memory before it, and filling up more
than coreboot_ram bytes there
Right after copying, the out of area bytes are copied to their final
location (around coreboot_ram).
I want to revisit the prefix/suffix calculation, as I'm not 100% sure
that it's doing the right thing (those copy operations should copy
_exactly_ the necessary set of bytes, nothing more), review is welcome
(look for prefix and suffix in selfboot.c)
The code is runtime tested on qemu-x86 (after cranking up the STACK_SIZE
to 16kb, so lzma could run), with the following scenarios:
RAMBASE = 0x4000, payload starting at 0x0010
(no collision between coreboot_ram and payload)
RAMBASE = 0x0010, payload starting at 0x0010
(RAMBASE below or at payload starting address, this worked before)
RAMBASE = 0x00101000, payload starting at 0x0010
(RAMBASE above payload starting address, this fails without this patch.
AMD boards were notorious with that one)
Pending the review of the prefix/suffix calculations (by me and
hopefully others), this is
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Once this is in, there are no CBFS issues that I know of, and hence I
propose to eliminate non-CBFS support in the tree soonish after that
patch is in.
I have some older patch for this, but it will likely not apply anymore,
but I can update it.
Opinions?
Regards,
Patrick
Index: src/boot/selfboot.c
===
--- src/boot/selfboot.c (Revision 4691)
+++ src/boot/selfboot.c (Arbeitskopie)
@@ -423,14 +423,13 @@
{
struct segment *ptr;
- unsigned long required_bounce_size = lb_end - lb_start;
+ unsigned long bounce_high = lb_end;
for(ptr = head-next; ptr != head; ptr = ptr-next) {
if (!overlaps_coreboot(ptr)) continue;
- unsigned long bounce = ptr-s_dstaddr + ptr-s_memsz - lb_start;
- if (bounce required_bounce_size)
- required_bounce_size = bounce;
+ if (ptr-s_dstaddr + ptr-s_memsz bounce_high)
+ bounce_high = ptr-s_dstaddr + ptr-s_memsz;
}
- get_bounce_buffer(mem, required_bounce_size);
+ get_bounce_buffer(mem, bounce_high - lb_start);
if (!bounce_buffer) {
printk_err(Could not find a bounce buffer...\n);
return 0;
@@ -502,6 +501,24 @@
/* Zero the extra bytes */
memset(middle, 0, end - middle);
}
+ /* Copy the data that's outside the area that shadows coreboot_ram */
+ printk_debug(dest %lx, end %lx, bouncebuffer %lx\n, dest, end, bounce_buffer);
+ if ((unsigned long)end bounce_buffer) {
+if ((unsigned long)dest bounce_buffer) {
+ unsigned long from = dest;
+ unsigned long to = lb_start-(bounce_buffer-(unsigned long)dest);
+ unsigned long amount = bounce_buffer-(unsigned long)dest;
+ printk_debug(move prefix around: from %lx, to %lx, amount: %lx\n, from, to, amount);
+ memcpy(to, from, amount);
+}
+if ((unsigned long)end bounce_buffer + (lb_end - lb_start)) {
+ unsigned long from = bounce_buffer + bounce_size;
+ unsigned long to = lb_end;
+ unsigned long amount = end - (bounce_buffer + bounce_size);
+ printk_debug(move suffix around: from %lx, to %lx, amount: %lx\n, from, to, amount);
+ memcpy(to, from, amount);
+}
+ }
}
}
return 1;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] SeaBIOS+libpayload?
Hi, There has been suggestions recently on using parts of libpayload in seabios. The following is my thoughts on some challenges of such an integration: Constrained memory - unlike a normal libpayload app, SeaBIOS must reserve all memory that it uses during runtime in the e820 map. This reserved memory then can't be used by the OS. Naturally, this means reserved memory needs to be kept to a minimum - it would be a shame to keep any sizable amount of memory unusable by the OS just so that it can be used for the 5 seconds or so before the OS starts. I'd say all code and ram used by SeaBIOS runtime shouldn't exceed 256KB. Right now, SeaBIOS is using around 80K. Also, code needed from 16bit mode must be located in the first 1Meg of ram. The constraints on memory here are even stricter - I'd say all code and ram here shouldn't exceed 100K. As a result of these restrictions, SeaBIOS code uses different memory zones (6 of them) and purposely allocates ram from the different zones to optimize the memory footprint. (For example, an allocation needed only during init wouldn't be reserved in the e820, an allocation needed during runtime but not from 16bit code would be in e820 high-mem, and only those allocations needed during 16bit run-time would go into the e820 low-mem.) Support for 16bit mode - SeaBIOS is fundamentally a 16bit bios implementation and that means supporting 16bit callers. Because SeaBIOS uses gcc, this isn't as difficult as it may seem, but it does require implementation restrictions. All code needs to be compiled by the seabios build (to manipulate the assembler and set compiler flags); it's not possible to just link in a library. Also, special macro wrappers must be placed in the code around all non-stack memory accesses. Because of these memory restrictions, seabios tends to pass parameters by value (so as to avoid lots of macro accesses). Seabios also tends to avoid function pointers (is the pointer to the 16bit version of the function or to the 32bit version of the function?). Finally, available stack space in 16bit mode is severely constrained. A hw irq handler probably shouldn't use more than 100 bytes of stack. A regular 16bit handler probably shouldn't use more than 250 bytes of stack. Seabios must work without coreboot - seabios can be used natively with qemu, bochs, and kvm. This isn't necessarily a problem for pulling in a libpayload driver, but it does constrain other parts of libpayload. (For example, it's not possible to assume a coreboot table will be found). Parts of libpayload tend to assume other parts of libpayload are available - this can be difficult for cherry picking drivers. For example, usb requires malloc, in/out, printf, mdelay, pci_config_write, etc. These can be redirected, but that's troublesome for maintenance because the different implementations may have subtly different behavior. Alternatively, one could try to introduce more parts of libpayload into seabios, but that further expands the scope of conflicts. For example, should the libpayload version of malloc know how to do e820 map allocations? On the flip side, the clear advantage of using libpayload in seabios is a reduction of the overall code that needs to be maintained. It could also lead to better test coverage of the code and a higher quality. In general, I think this raises a high-level question. Is there a desire to introduce the memory and operating constraints into the libpayload code that SeaBIOS will need? This is a bit of a difficult question, as the other users (eg, filo) have no need to worry about these restrictions and it will definitely make maintenance and testing harder. My general feel has been that this isn't worth the cost. The amount of code being duplicated I would estimate is around 3000 lines. This is unarguably very tricky code (eg, hw init, timing, malloc), but there is not an overwhelming amount of it. Thoughts? -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4694 - trunk/util/inteltool
Author: uwe
Date: 2009-09-30 19:05:46 +0200 (Wed, 30 Sep 2009)
New Revision: 4694
Modified:
trunk/util/inteltool/gpio.c
trunk/util/inteltool/inteltool.c
trunk/util/inteltool/inteltool.h
trunk/util/inteltool/memory.c
trunk/util/inteltool/powermgt.c
Log:
Add initial inteltool support for Intel 440BX/440LX and 82371AB/EB/MB.
Signed-off-by: Maciej Pijanka maciej.pija...@gmail.com
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified: trunk/util/inteltool/gpio.c
===
--- trunk/util/inteltool/gpio.c 2009-09-30 14:46:43 UTC (rev 4693)
+++ trunk/util/inteltool/gpio.c 2009-09-30 17:05:46 UTC (rev 4694)
@@ -131,6 +131,9 @@
gpio_registers = ich0_gpio_registers;
size = ARRAY_SIZE(ich0_gpio_registers);
break;
+ case PCI_DEVICE_ID_INTEL_82371XX:
+ printf(This southbridge has GPIOs in the PM unit.\n);
+ return 1;
case 0x1234: // Dummy for non-existent functionality
printf(This southbridge does not have GPIOBASE.\n);
return 1;
Modified: trunk/util/inteltool/inteltool.c
===
--- trunk/util/inteltool/inteltool.c2009-09-30 14:46:43 UTC (rev 4693)
+++ trunk/util/inteltool/inteltool.c2009-09-30 17:05:46 UTC (rev 4694)
@@ -29,6 +29,9 @@
uint16_t vendor_id, device_id;
char *name;
} supported_chips_list[] = {
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443LX, 82443LX },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443BX, 82443BX },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443BX_NO_AGP, 82443BX
without AGP },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810, i810 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810DC, i810-DC100 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845, i845 },
@@ -47,7 +50,8 @@
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH4, ICH4 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH2, ICH2 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH0, ICH0 },
- { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH, ICH }
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH, ICH },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371XX, 82371AB/EB/MB },
};
#ifndef __DARWIN__
@@ -112,7 +116,7 @@
int main(int argc, char *argv[])
{
struct pci_access *pacc;
- struct pci_dev *sb, *nb;
+ struct pci_dev *sb = NULL, *nb, *dev;
int i, opt, option_index = 0;
unsigned int id;
@@ -204,8 +208,20 @@
pci_scan_bus(pacc);
/* Find the required devices */
+ for (dev = pacc-devices; dev; dev = dev-next) {
+ pci_fill_info(dev, PCI_FILL_CLASS);
+ /* The ISA/LPC bridge can be 0x1f, 0x07, or 0x04 so we probe. */
+ if (dev-device_class == 0x0601) { /* ISA/LPC bridge */
+ if (sb == NULL)
+ sb = dev;
+ else
+ fprintf(stderr, Multiple devices with class ID
+0x0601, using %02x%02x:%02x.%02x\n,
+ dev-domain, dev-bus, dev-dev,
+ dev-func);
+ }
+ }
- sb = pci_get_dev(pacc, 0, 0, 0x1f, 0);
if (!sb) {
printf(No southbridge found.\n);
exit(1);
Modified: trunk/util/inteltool/inteltool.h
===
--- trunk/util/inteltool/inteltool.h2009-09-30 14:46:43 UTC (rev 4693)
+++ trunk/util/inteltool/inteltool.h2009-09-30 17:05:46 UTC (rev 4694)
@@ -32,28 +32,37 @@
#define INTELTOOL_VERSION 1.0
/* Tested chipsets: */
-#define PCI_VENDOR_ID_INTEL0x8086
-#define PCI_DEVICE_ID_INTEL_ICH0x2410
-#define PCI_DEVICE_ID_INTEL_ICH0 0x2420
-#define PCI_DEVICE_ID_INTEL_ICH2 0x2440
-#define PCI_DEVICE_ID_INTEL_ICH4 0x24c0
-#define PCI_DEVICE_ID_INTEL_ICH4M 0x24cc
-#define PCI_DEVICE_ID_INTEL_ICH7DH 0x27b0
-#define PCI_DEVICE_ID_INTEL_ICH7 0x27b8
-#define PCI_DEVICE_ID_INTEL_ICH7M 0x27b9
-#define PCI_DEVICE_ID_INTEL_ICH7MDH0x27bd
-#define PCI_DEVICE_ID_INTEL_ICH8M 0x2815
-#define PCI_DEVICE_ID_INTEL_ICH10R 0x3a16
+#define PCI_VENDOR_ID_INTEL0x8086
+#define PCI_DEVICE_ID_INTEL_ICH0x2410
+#define PCI_DEVICE_ID_INTEL_ICH0 0x2420
+#define PCI_DEVICE_ID_INTEL_ICH2 0x2440
+#define PCI_DEVICE_ID_INTEL_ICH4 0x24c0
+#define PCI_DEVICE_ID_INTEL_ICH4M 0x24cc
+#define PCI_DEVICE_ID_INTEL_ICH7DH 0x27b0
+#define PCI_DEVICE_ID_INTEL_ICH7 0x27b8
+#define PCI_DEVICE_ID_INTEL_ICH7M 0x27b9
+#define PCI_DEVICE_ID_INTEL_ICH7MDH0x27bd
[coreboot] [v2] r4695 - trunk/util/inteltool
Author: uwe Date: 2009-09-30 19:14:24 +0200 (Wed, 30 Sep 2009) New Revision: 4695 Modified: trunk/util/inteltool/inteltool.c Log: Hm, quickfix to prevent the following crash, no idea yet what happens: *** glibc detected *** ././inteltool: double free or corruption (top): 0x08db0260 *** Signed-off-by: Uwe Hermann u...@hermann-uwe.de Acked-by: Uwe Hermann u...@hermann-uwe.de Modified: trunk/util/inteltool/inteltool.c === --- trunk/util/inteltool/inteltool.c2009-09-30 17:05:46 UTC (rev 4694) +++ trunk/util/inteltool/inteltool.c2009-09-30 17:14:24 UTC (rev 4695) @@ -309,7 +309,7 @@ /* Clean up */ pci_free_dev(nb); - pci_free_dev(sb); + // pci_free_dev(sb); // TODO: glibc detected double free or corruption pci_cleanup(pacc); return 0; -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS+libpayload?
If libpayload can't fit seabios' needs then it needs to change so that it can. It's not much of a library if seabios can't use it IMHO. This may boil down to making the build process more flexible. I don't know. I wonder how much of the low 1M we should just take for our purposes. 1M is a tiny amount of memory, and there are already options for reserving the low 64k for BIOSen in the newer kernels, as well as scans for low memory corruption. Should we just mark all of low 1M as reserved and use it as needed? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Inteltool patch v4
On Sun, Sep 27, 2009 at 12:01:12AM +0200, Maciej Pijanka wrote: This is last version, includes detecting southbridge using device_class not device location on bus as Stefan suggested, also will tell if find more than one device with device_class 0x601 and notify which one it used (it will be first but may depend on order of devices inside structures returned by libpci). Thanks, committed as r4694 with some smaller changes. May need some more work though. Here's the output from one of my 440BX boards, which looks a bit strange: Intel CPU: Family 6, Model 8 Intel Northbridge: 8086:7190 (82443BX) Intel Southbridge: 8086:7110 (82371AB/EB/MB) = GPIOS = This southbridge has GPIOs in the PM unit. = RCBA == Error: Dumping RCBA on this southbridge is not (yet) supported. = PMBASE PMBASE = 0x (IO) pmbase+0x: 0x (PMSTS) pmbase+0x0002: 0x7f7f (PMEN) pmbase+0x0004: 0x (PMCNTRL) pmbase+0x0006: 0x (RESERVED) pmbase+0x0008: 0x00 (PMTMR) pmbase+0x0009: 0xff (RESERVED) pmbase+0x000a: 0xff (RESERVED) pmbase+0x000b: 0xff (RESERVED) pmbase+0x000c: 0x (GPSTS) pmbase+0x000e: 0x (GPEN) pmbase+0x0010: 0x (PCNTRL) pmbase+0x0018: 0x (GLBSTS) pmbase+0x001a: 0x (RESERVED) pmbase+0x001c: 0x (DEVSTS) pmbase+0x0020: 0x (GLBEN) pmbase+0x0022: 0xff (RESERVED) pmbase+0x0023: 0xff (RESERVED) pmbase+0x0024: 0x00 (RESERVED) pmbase+0x0025: 0x20 (RESERVED) pmbase+0x0026: 0xff (RESERVED) pmbase+0x0027: 0xff (RESERVED) pmbase+0x0028: 0x (GLBCTL) pmbase+0x002c: 0x (DEVCTL) pmbase+0x0030: 0x00 (GPIREG 0) pmbase+0x0031: 0x20 (GPIREG 1) pmbase+0x0032: 0xff (GPIREG 2) pmbase+0x0033: 0xff (GPIREG 3) pmbase+0x0034: 0x00 (GPOREG 0) pmbase+0x0035: 0x20 (GPOREG 1) pmbase+0x0036: 0xff (GPOREG 2) pmbase+0x0037: 0xff (GPOREG 3) = MCHBAR This northbrigde does not have MCHBAR. = EPBAR = Error: Dumping EPBAR on this northbridge is not (yet) supported. = DMIBAR Error: Dumping DMIBAR on this northbridge is not (yet) supported. = PCIEXBAR Error: Dumping PCIEXBAR on this northbridge is not (yet) supported. Error: Dumping MSRs on this CPU (0x000680) is not (yet) supported. I think 440BX doesn't have most of the BARs mentioned above either (which we can easily fix). The more interesting question is why the PMBASE is 0x0 above. Here's the respective lspci: 00:04.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 00: 86 80 10 71 0f 00 80 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 20 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 80 80 80 0a 10 00 00 00 00 f2 80 00 00 00 00 00 70: 00 00 00 00 00 00 0c 0c 00 00 00 00 00 00 00 00 80: 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00 So 0x40 (PMBASE) is indeed simply 0x, no idea if that's supposed to be the case. 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] [PATCH]Fix hopefully last stopper bug for CBFS. Plan to get rid of non-CBFS
Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4694
Dear coreboot readers! This is the automatic build system of coreboot. The developer uwe checked in revision 4694 to the coreboot repository. This caused the following changes: Change Log: Add initial inteltool support for Intel 440BX/440LX and 82371AB/EB/MB. Signed-off-by: Maciej Pijanka maciej.pija...@gmail.com Acked-by: Uwe Hermann u...@hermann-uwe.de Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4694device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4694device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4694device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Asus M2N4-SLI details
Attached is the output of various tools run on an Asus M2N4-SLI board.
Looks like mptable didn't work correctly?
--
Andrew.
/*
* This file is part of the coreboot project.
*
* Copyright (C) 200x TODO t...@todo
*
* 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
*/
#ifdef GETPIR /* TODO: Drop this when copying to coreboot. */
#include pirq_routing.h /* TODO: Drop this when copying to coreboot. */
#else /* TODO: Drop this when copying to coreboot. */
#include arch/pirq_routing.h
#endif /* TODO: Drop this when copying to coreboot. */
const struct irq_routing_table intel_irq_routing_table = {
PIRQ_SIGNATURE, /* u32 signature */
PIRQ_VERSION, /* u16 version */
32 + 16 * 13, /* Max. number of devices on the bus */
0x00, /* Interrupt router bus */
(0x00 3) | 0x0, /* Interrupt router dev */
0x828, /* IRQs devoted exclusively to PCI usage */
0, /* Vendor */
0, /* Device */
0, /* Miniport */
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
0x1f, /* Checksum (has to be set to some value that
* would give 0 after the sum of all bytes
* for this structure (including checksum).
*/
{
/* bus,dev | fn, {link, bitmap}, {link, bitmap},
{link, bitmap}, {link, bitmap}, slot, rfu */
{0x01, (0x06 3) | 0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8},
{0x03, 0xdeb8}, {0x04, 0xdeb8}}, 0x1, 0x0},
{0x01, (0x07 3) | 0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8},
{0x04, 0xdeb8}, {0x01, 0xdeb8}}, 0x2, 0x0},
{0x01, (0x01 3) | 0x0, {{0x02, 0xdeb8}, {0x02, 0xdeb8},
{0x02, 0xdeb8}, {0x02, 0xdeb8}}, 0x3, 0x0},
{0x05, (0x00 3) | 0x0, {{0x03, 0xdeb8}, {0x04, 0xdeb8},
{0x01, 0xdeb8}, {0x02, 0xdeb8}}, 0x4, 0x0},
{0x04, (0x00 3) | 0x0, {{0x04, 0xdeb8}, {0x01, 0xdeb8},
{0x02, 0xdeb8}, {0x03, 0xdeb8}}, 0x5, 0x0},
{0x03, (0x00 3) | 0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8},
{0x03, 0xdeb8}, {0x04, 0xdeb8}}, 0x6, 0x0},
{0x02, (0x00 3) | 0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8},
{0x04, 0xdeb8}, {0x01, 0xdeb8}}, 0x7, 0x0},
{0x00, (0x01 3) | 0x0, {{0x06, 0xdeb8}, {0x06, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}}, 0x0, 0x0},
{0x00, (0x02 3) | 0x0, {{0x07, 0xdeb8}, {0x09, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}}, 0x0, 0x0},
{0x00, (0x04 3) | 0x0, {{0x0a, 0xdeb8}, {0x0b, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}}, 0x0, 0x0},
{0x00, (0x0a 3) | 0x0, {{0x0c, 0xdeb8}, {0x00, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}}, 0x0, 0x0},
{0x00, (0x07 3) | 0x0, {{0x0d, 0xdeb8}, {0x00, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}}, 0x0, 0x0},
{0x00, (0x08 3) | 0x0, {{0x0e, 0xdeb8}, {0x00, 0xdeb8},
{0x00, 0xdeb8}, {0x00, 0xdeb8}}, 0x0, 0x0},
}
};
unsigned long write_pirq_routing_table(unsigned long addr)
{
return copy_pirq_routing_table(addr);
}
superiotool r4668
Probing for ALi Super I/O at 0x3f0...
Failed. Returned data: id=0x, rev=0xff
Probing for ALi Super I/O at 0x370...
Failed. Returned data: id=0x, rev=0xff
Probing for Fintek Super I/O at 0x2e...
Failed. Returned data: vid=0x, id=0x
Probing for Fintek Super I/O at 0x4e...
Failed. Returned data: vid=0x, id=0x
Probing for ITE Super I/O (init=standard) at 0x2e...
Found ITE IT8716F (id=0x8716, rev=0x0) at 0x2e
Register dump:
idx 20 21 22 23 24 2b
val 87 16 00 01 00 00
def 87 16 01 00 00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1
val 00 00 00 00 04 00 80
def 00 03 f0 06 02 00 00
LDN 0x01 (COM1)
idx 30 60 61 70 f0 f1 f2 f3
val 01 03 f8 04 00 50 00 7f
def 00 03 f8 04 00 50 00 7f
LDN 0x02 (COM2)
idx 30 60 61 70 f0 f1 f2 f3
val 00 00 00 00 00 50 00 7f
def 00 02 f8 03 00 50 00 7f
LDN 0x03 (Parallel port)
idx 30 60 61 62 63 70 74 f0
val 01 03 78 07 78 07 03 0a
def 00 03 78 07 78 07 03 03
LDN 0x04 (Environment controller)
idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6
val 01 02 90 00
[coreboot] build service results for r4695
Dear coreboot readers! This is the automatic build system of coreboot. The developer uwe checked in revision 4695 to the coreboot repository. This caused the following changes: Change Log: Hm, quickfix to prevent the following crash, no idea yet what happens: *** glibc detected *** ././inteltool: double free or corruption (top): 0x08db0260 *** Signed-off-by: Uwe Hermann u...@hermann-uwe.de Acked-by: Uwe Hermann u...@hermann-uwe.de Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4695device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4695device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4695device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Inteltool patch v4
On 30/09/2009, Uwe Hermann u...@hermann-uwe.de wrote: On Sun, Sep 27, 2009 at 12:01:12AM +0200, Maciej Pijanka wrote: This is last version, includes detecting southbridge using device_class not device location on bus as Stefan suggested, also will tell if find more than one device with device_class 0x601 and notify which one it used (it will be first but may depend on order of devices inside structures returned by libpci). Thanks, committed as r4694 with some smaller changes. May need some more work though. Here's the output from one of my 440BX boards, which looks a bit strange: Intel CPU: Family 6, Model 8 Intel Northbridge: 8086:7190 (82443BX) Intel Southbridge: 8086:7110 (82371AB/EB/MB) [..] = PMBASE PMBASE = 0x (IO) pmbase+0x: 0x (PMSTS) pmbase+0x0002: 0x7f7f (PMEN) pmbase+0x0004: 0x (PMCNTRL) pmbase+0x0006: 0x (RESERVED) pmbase+0x0008: 0x00 (PMTMR) pmbase+0x0009: 0xff (RESERVED) pmbase+0x000a: 0xff (RESERVED) pmbase+0x000b: 0xff (RESERVED) pmbase+0x000c: 0x (GPSTS) pmbase+0x000e: 0x (GPEN) pmbase+0x0010: 0x (PCNTRL) pmbase+0x0018: 0x (GLBSTS) pmbase+0x001a: 0x (RESERVED) pmbase+0x001c: 0x (DEVSTS) pmbase+0x0020: 0x (GLBEN) pmbase+0x0022: 0xff (RESERVED) pmbase+0x0023: 0xff (RESERVED) pmbase+0x0024: 0x00 (RESERVED) pmbase+0x0025: 0x20 (RESERVED) pmbase+0x0026: 0xff (RESERVED) pmbase+0x0027: 0xff (RESERVED) pmbase+0x0028: 0x (GLBCTL) pmbase+0x002c: 0x (DEVCTL) pmbase+0x0030: 0x00 (GPIREG 0) pmbase+0x0031: 0x20 (GPIREG 1) pmbase+0x0032: 0xff (GPIREG 2) pmbase+0x0033: 0xff (GPIREG 3) pmbase+0x0034: 0x00 (GPOREG 0) pmbase+0x0035: 0x20 (GPOREG 1) pmbase+0x0036: 0xff (GPOREG 2) pmbase+0x0037: 0xff (GPOREG 3) [..] I think 440BX doesn't have most of the BARs mentioned above either (which we can easily fix). The more interesting question is why the PMBASE is 0x0 above. I had no idea if i should put warnings about those BARs and datasheet didn't mention anything like that but maybe i overlooked something. Here's the respective lspci: 00:04.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA [8086:7110] (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 00: 86 80 10 71 0f 00 80 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 20 00 [...] So 0x40 (PMBASE) is indeed simply 0x, no idea if that's supposed to be the case. On all my machines that have 440BX or 440LX and are operational that i can run inteltool there i have same 0x PM base regardless i have enabled power management in bios or not. And indeed i think it is odd. One idea that came to my mind was writing very short and dumb module that will claim some IO space and set pmbase register to point to that space and check again, but didn't found yet time to put pieces together. Maciej -- Maciej Pijanka, PLD-Linux Developer, Reg Linux user #133161 POE/Perl user -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Inteltool patch v4
Maciej Pijanka wrote: On 30/09/2009, Uwe Hermann u...@hermann-uwe.de wrote: On Sun, Sep 27, 2009 at 12:01:12AM +0200, Maciej Pijanka wrote: This is last version, includes detecting southbridge using device_class not device location on bus as Stefan suggested, also will tell if find more than one device with device_class 0x601 and notify which one it used (it will be first but may depend on order of devices inside structures returned by libpci). Thanks, committed as r4694 with some smaller changes. May need some more work though. Here's the output from one of my 440BX boards, which looks a bit strange: Intel CPU: Family 6, Model 8 Intel Northbridge: 8086:7190 (82443BX) Intel Southbridge: 8086:7110 (82371AB/EB/MB) [..] = PMBASE PMBASE = 0x (IO) On all my machines that have 440BX or 440LX and are operational that i can run inteltool there i have same 0x PM base regardless i have enabled power management in bios or not. And indeed i think it is odd. One idea that came to my mind was writing very short and dumb module that will claim some IO space and set pmbase register to point to that space and check again, but didn't found yet time to put pieces together. On that southbridge, PMBASE is not in the LPC/ISA bridge (FN0) but in the PM device (FN3) -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • 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] SeaBIOS+libpayload?
ron minnich wrote: If libpayload can't fit seabios' needs then it needs to change so that it can. Not so fast. It's not much of a library if seabios can't use it IMHO. I disagree. libpayload is not optimized for a BIOS environment, and I think that's a really good thing. But it does mean it's not a great fit for SeaBIOS. If libpayload becomes tailored to a single user, it's not much of a library either. This may boil down to making the build process more flexible. I don't know. That can be a good thing, but I don't know how helpful it is. For memory allocation, maybe a variation on malloc in libpayload could take a malloc context struct parameter which describes where the area is located and has some callback hooks for when allocations change so that a memory map can be updated if needed. In the common case there will only be one malloc context. In SeaBIOS Kevin said there are six. In FILO the area resize hooks are NULL and never called, in SeaBIOS they can update the memory map. Because SeaBIOS is a little special (nice way of saying partly 16bit) it has special requirements. I think it would be very nice to reuse source from libpayload, as well as open up the libpayload build process if neccessary, if it is possible. But I agree with Kevin that it needs to be worthwhile to actually go and make changes both in SeaBIOS and in libpayload. I also agree with Kevin that it doesn't really look like it is.. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS and USB UHCI keyboard support
Kevin O'Connor wrote: The support in SeaBIOS is currently 1029 lines of code - it is a direct, no nonsense, just make it work implementation. I think that is wonderful! Good job! The next thing I am planning to look at is basic ohci keyboard support, and then fleshing out the current keyboard support (eg, auto-repeat, keyboard leds). The USB option ROM is still a tricky point. How to make it co-exist with USB support in SeaBIOS? If the option ROM works out well, maybe it could instead offer the keyboard services? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH]Compress coreboot_ram also if no payload is compressed
Hi, attached patch makes coreboot_ram compression depending on CONFIG_COMPRESS again, instead of looking at the compression configuration for the payload Build-tested (some coreboot_ram files were too large without compression for a full build, and now fit again) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Index: util/newconfig/config.g === --- util/newconfig/config.g (Revision 4695) +++ util/newconfig/config.g (Arbeitskopie) @@ -2278,6 +2278,7 @@ file.write(ifeq \$(CONFIG_CBFS)\ \1\\n\n) file.write(CBFS_COMPRESS_FLAG:=\n) file.write(ifeq \$(CONFIG_COMPRESSED_PAYLOAD_LZMA)\ \1\\nCBFS_COMPRESS_FLAG:=l\nendif\n\n) + file.write(ifeq \$(CONFIG_COMPRESS)\ \1\\nCBFS_STAGE_COMPRESS_FLAG:=l\nendif\n\n) for i in buildroms: file.write(%s: cbfstool %(i.name)) @@ -2303,7 +2304,7 @@ if (j != failover) and (rommapping[j] != /dev/null): file.write(\t./cbfs/cbfstool %s add-payload %s %s/payload $(CBFS_COMPRESS_FLAG)\n % (i.name, rommapping[j], j,)) if (j != failover): -file.write(\t./cbfs/cbfstool %s add-stage %s/coreboot_ram %s/coreboot_ram $(CBFS_COMPRESS_FLAG)\n % (i.name, j, j,)) +file.write(\t./cbfs/cbfstool %s add-stage %s/coreboot_ram %s/coreboot_ram $(CBFS_STAGE_COMPRESS_FLAG)\n % (i.name, j, j,)) file.write(\tif [ -f %s/coreboot_apc ]; then ./cbfs/cbfstool %s add-stage %s/coreboot_apc %s/coreboot_apc $(CBFS_COMPRESS_FLAG); fi\n % (j, i.name, j, j,)) file.write(\t./cbfs/cbfstool %s print\n % i.name) file.write(\n) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Compress coreboot_ram also if no payload is compressed
On Wed, Sep 30, 2009 at 1:41 PM, Patrick Georgi patr...@georgi-clan.de wrote: Hi, attached patch makes coreboot_ram compression depending on CONFIG_COMPRESS again, instead of looking at the compression configuration for the payload Makes sense. Build-tested (some coreboot_ram files were too large without compression for a full build, and now fit again) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Myles Watson myle...@gmail.com Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4696 - trunk/coreboot-v2/util/newconfig
Author: oxygene Date: 2009-09-30 21:54:15 +0200 (Wed, 30 Sep 2009) New Revision: 4696 Modified: trunk/coreboot-v2/util/newconfig/config.g Log: Compress stage if CONFIG_COMPRESS is activated, instead of relying on payload compression configuration (disabled when using abuild without payload, for example) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Myles Watson myle...@gmail.com Modified: trunk/coreboot-v2/util/newconfig/config.g === --- trunk/coreboot-v2/util/newconfig/config.g 2009-09-30 17:14:24 UTC (rev 4695) +++ trunk/coreboot-v2/util/newconfig/config.g 2009-09-30 19:54:15 UTC (rev 4696) @@ -2277,7 +2277,9 @@ file.write(ifeq \$(CONFIG_CBFS)\ \1\\n\n) file.write(CBFS_COMPRESS_FLAG:=\n) + file.write(CBFS_STAGE_COMPRESS_FLAG:=\n) file.write(ifeq \$(CONFIG_COMPRESSED_PAYLOAD_LZMA)\ \1\\nCBFS_COMPRESS_FLAG:=l\nendif\n\n) + file.write(ifeq \$(CONFIG_COMPRESS)\ \1\\nCBFS_STAGE_COMPRESS_FLAG:=l\nendif\n\n) for i in buildroms: file.write(%s: cbfstool %(i.name)) @@ -2303,7 +2305,7 @@ if (j != failover) and (rommapping[j] != /dev/null): file.write(\t./cbfs/cbfstool %s add-payload %s %s/payload $(CBFS_COMPRESS_FLAG)\n % (i.name, rommapping[j], j,)) if (j != failover): - file.write(\t./cbfs/cbfstool %s add-stage %s/coreboot_ram %s/coreboot_ram $(CBFS_COMPRESS_FLAG)\n % (i.name, j, j,)) + file.write(\t./cbfs/cbfstool %s add-stage %s/coreboot_ram %s/coreboot_ram $(CBFS_STAGE_COMPRESS_FLAG)\n % (i.name, j, j,)) file.write(\tif [ -f %s/coreboot_apc ]; then ./cbfs/cbfstool %s add-stage %s/coreboot_apc %s/coreboot_apc $(CBFS_COMPRESS_FLAG); fi\n % (j, i.name, j, j,)) file.write(\t./cbfs/cbfstool %s print\n % i.name) file.write(\n) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4696
Dear coreboot readers! This is the automatic build system of coreboot. The developer oxygene checked in revision 4696 to the coreboot repository. This caused the following changes: Change Log: Compress stage if CONFIG_COMPRESS is activated, instead of relying on payload compression configuration (disabled when using abuild without payload, for example) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Myles Watson myle...@gmail.com Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4696device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4696device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4696device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Compress coreboot_ram also if no payload is compressed
Myles Watson wrote: attached patch makes coreboot_ram compression depending on CONFIG_COMPRESS again, instead of looking at the compression configuration for the payload Makes sense. Is the uncompressor always available? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Compress coreboot_ram also if no payload is compressed
Am Mittwoch, den 30.09.2009, 22:23 +0200 schrieb Peter Stuge: Myles Watson wrote: attached patch makes coreboot_ram compression depending on CONFIG_COMPRESS again, instead of looking at the compression configuration for the payload Makes sense. Is the uncompressor always available? Yes, and even if not, that's what's CONFIG_COMPRESS is for, right? (otherwise: what would be the point of that variable?) Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Fix hopefully last stopper bug for CBFS. Plan to get rid of non-CBFS
Am Mittwoch, den 30.09.2009, 18:16 +0200 schrieb Patrick Georgi:
Pending the review of the prefix/suffix calculations (by me and
hopefully others), this is
Review done, one bug found and hunted down. See new patch
It's
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
and considered ready for commit by me.
Regards,
Patrick
Index: src/boot/selfboot.c
===
--- src/boot/selfboot.c (Revision 4695)
+++ src/boot/selfboot.c (Arbeitskopie)
@@ -423,14 +423,13 @@
{
struct segment *ptr;
- unsigned long required_bounce_size = lb_end - lb_start;
+ unsigned long bounce_high = lb_end;
for(ptr = head-next; ptr != head; ptr = ptr-next) {
if (!overlaps_coreboot(ptr)) continue;
- unsigned long bounce = ptr-s_dstaddr + ptr-s_memsz - lb_start;
- if (bounce required_bounce_size)
- required_bounce_size = bounce;
+ if (ptr-s_dstaddr + ptr-s_memsz bounce_high)
+ bounce_high = ptr-s_dstaddr + ptr-s_memsz;
}
- get_bounce_buffer(mem, required_bounce_size);
+ get_bounce_buffer(mem, bounce_high - lb_start);
if (!bounce_buffer) {
printk_err(Could not find a bounce buffer...\n);
return 0;
@@ -502,6 +501,24 @@
/* Zero the extra bytes */
memset(middle, 0, end - middle);
}
+ /* Copy the data that's outside the area that shadows coreboot_ram */
+ printk_debug(dest %lx, end %lx, bouncebuffer %lx\n, dest, end, bounce_buffer);
+ if ((unsigned long)end bounce_buffer) {
+if ((unsigned long)dest bounce_buffer) {
+ unsigned long from = dest;
+ unsigned long to = lb_start-(bounce_buffer-(unsigned long)dest);
+ unsigned long amount = bounce_buffer-(unsigned long)dest;
+ printk_debug(move prefix around: from %lx, to %lx, amount: %lx\n, from, to, amount);
+ memcpy(to, from, amount);
+}
+if ((unsigned long)end bounce_buffer + (lb_end - lb_start)) {
+ unsigned long from = bounce_buffer + (lb_end - lb_start);
+ unsigned long to = lb_end;
+ unsigned long amount = end - from;
+ printk_debug(move suffix around: from %lx, to %lx, amount: %lx\n, from, to, amount);
+ memcpy(to, from, amount);
+}
+ }
}
}
return 1;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Compress coreboot_ram also if no payload is compressed
Patrick Georgi wrote: attached patch makes coreboot_ram compression depending on CONFIG_COMPRESS again, instead of looking at the compression configuration for the payload Makes sense. Is the uncompressor always available? Yes, and even if not, that's what's CONFIG_COMPRESS is for, right? Completely right. Great! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Patrick Georgi wrote: attached patch removes: - CONFIG_CBFS - anything that's conditional on CONFIG_CBFS == 0 - files that were only included for CONFIG_CBFS == 0 In particular: - elfboot Ok. - stream boot code Wasn't this used for accessing large flash on m57sli? And does it have anything to do with the serial transfer stuff? (Xmodem) - mini-filo and filesystems Cleaning out the attic - great! I consider the tree ready for this as there are no known bugs anymore (except the one fixed by that other patch). Speak up if you disagree I agree! :) //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On Sep 30, 2009, at 22:56, Peter Stuge pe...@stuge.se wrote: Patrick Georgi wrote: attached patch removes: - CONFIG_CBFS - anything that's conditional on CONFIG_CBFS == 0 - files that were only included for CONFIG_CBFS == 0 In particular: - elfboot Ok. - stream boot code Wasn't this used for accessing large flash on m57sli? Yes. Anyone with such a setup willing to fix CBFS for that? And does it have anything to do with the serial transfer stuff? (Xmodem) Not possible anymore with CBFS.. Maybe we should make a minipayload for the functionality? //Peter Stefan -- 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]Fix hopefully last stopper bug for CBFS. Plan to get rid of non-CBFS
Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4697 - trunk/coreboot-v2/src/boot
Author: oxygene
Date: 2009-09-30 23:36:38 +0200 (Wed, 30 Sep 2009)
New Revision: 4697
Modified:
trunk/coreboot-v2/src/boot/selfboot.c
Log:
Fix payload loading in various corner cases when working
with the bounce buffer.
In particular, the not-so-rare configuration of AMD boards with RAMBASE at
2MB shouldn't crash anymore for payloads that take 1MB in total
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Ronald G. Minnich rminn...@gmail.com
Modified: trunk/coreboot-v2/src/boot/selfboot.c
===
--- trunk/coreboot-v2/src/boot/selfboot.c 2009-09-30 19:54:15 UTC (rev
4696)
+++ trunk/coreboot-v2/src/boot/selfboot.c 2009-09-30 21:36:38 UTC (rev
4697)
@@ -423,14 +423,13 @@
{
struct segment *ptr;
- unsigned long required_bounce_size = lb_end - lb_start;
+ unsigned long bounce_high = lb_end;
for(ptr = head-next; ptr != head; ptr = ptr-next) {
if (!overlaps_coreboot(ptr)) continue;
- unsigned long bounce = ptr-s_dstaddr + ptr-s_memsz - lb_start;
- if (bounce required_bounce_size)
- required_bounce_size = bounce;
+ if (ptr-s_dstaddr + ptr-s_memsz bounce_high)
+ bounce_high = ptr-s_dstaddr + ptr-s_memsz;
}
- get_bounce_buffer(mem, required_bounce_size);
+ get_bounce_buffer(mem, bounce_high - lb_start);
if (!bounce_buffer) {
printk_err(Could not find a bounce buffer...\n);
return 0;
@@ -502,6 +501,24 @@
/* Zero the extra bytes */
memset(middle, 0, end - middle);
}
+ /* Copy the data that's outside the area that shadows
coreboot_ram */
+ printk_debug(dest %lx, end %lx, bouncebuffer %lx\n,
dest, end, bounce_buffer);
+ if ((unsigned long)end bounce_buffer) {
+ if ((unsigned long)dest bounce_buffer) {
+ unsigned long from = dest;
+ unsigned long to =
lb_start-(bounce_buffer-(unsigned long)dest);
+ unsigned long amount =
bounce_buffer-(unsigned long)dest;
+ printk_debug(move prefix around: from
%lx, to %lx, amount: %lx\n, from, to, amount);
+ memcpy(to, from, amount);
+ }
+ if ((unsigned long)end bounce_buffer +
(lb_end - lb_start)) {
+ unsigned long from = bounce_buffer +
(lb_end - lb_start);
+ unsigned long to = lb_end;
+ unsigned long amount = end - from;
+ printk_debug(move suffix around: from
%lx, to %lx, amount: %lx\n, from, to, amount);
+ memcpy(to, from, amount);
+ }
+ }
}
}
return 1;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Index: src/devices/pci_rom.c
===
--- src/devices/pci_rom.c (Revision 4696)
+++ src/devices/pci_rom.c (Arbeitskopie)
@@ -35,17 +35,15 @@
struct rom_header *rom_header;
struct pci_data *rom_data;
if (dev-on_mainboard) {
/* this is here as a legacy path. We hope it goes away soon.
Users should not have to
The legacy path is the non-CBFS path and should disappear
-#if CONFIG_CBFS == 1
-# if CONFIG_USE_FALLBACK_IMAGE == 1
+#if CONFIG_USE_FALLBACK_IMAGE == 1
str_coreboot_ram_name:.string fallback/coreboot_ram
-# else
+#else
str_coreboot_ram_name:.string normal/coreboot_ram
-# endif
#endif
Since normal and failover aren't supported with CBFS, can they disappear
too?
I consider the tree ready for this as there are no known bugs anymore
(except the one fixed by that other patch). Speak up if you disagree (I
intend to wait with committing this patch until saturday evening CEST)
The sooner the better. Non-CBFS is already bit rotting.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Myles Watson myle...@gmail.com
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4697
Dear coreboot readers! This is the automatic build system of coreboot. The developer oxygene checked in revision 4697 to the coreboot repository. This caused the following changes: Change Log: Fix payload loading in various corner cases when working with the bounce buffer. In particular, the not-so-rare configuration of AMD boards with RAMBASE at 2MB shouldn't crash anymore for payloads that take 1MB in total Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Ronald G. Minnich rminn...@gmail.com Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4697device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4697device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4697device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On 30.09.2009 23:08, Stefan Reinauer wrote: On Sep 30, 2009, at 22:56, Peter Stuge pe...@stuge.se wrote: Patrick Georgi wrote: attached patch removes: - CONFIG_CBFS - stream boot code Wasn't this used for accessing large flash on m57sli? Yes. Anyone with such a setup willing to fix CBFS for that? I don't have such a setup, but I remember the discussion about supporting this for LAR in v3 and back then it was the consensus that such boards would simply not be ported to v3. Given that v2 now has CBFS, we need to either abandon large flash on M57SLI and similar boards or fix CBFS somehow. The horrible way out is to use accessor functions for every flash access made by CBFS code. It also means you get to write your own streaming version of memcmp, strstr, strlen etc. The easy way out is to simply copy all of flash to RAM, then walk the copy in RAM. It's a bit inefficient because you have to copy the whole flash chip to RAM, but the code stays readable. Of course RAMinit and bootblock have to be in the always-mapped region of the flash chip. And does it have anything to do with the serial transfer stuff? (Xmodem) Not possible anymore with CBFS.. Maybe we should make a minipayload for the functionality? Interfacing the minipayload is probably going to be more pain than simply linking in the xmodem code and calling it if all other options fail. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
can anyone even buy an m57sli any more? Was it an unfortunate mistake -- never repeated -- that FLASH was not directly accessible? If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad. If we have to cope with this problem in future, maybe we're stuck with accessor functions. But FLASH is so slow I doubt that the cost of an accessor function is going to kill us. Function calls run in nanoseconds, and if SPI really is only 40 MB/sec., then that's 25 ns/byte. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
ron minnich wrote: can anyone even buy an m57sli any more? No, they are out of production and out of stock really everywhere. Was it an unfortunate mistake -- never repeated -- that FLASH was not directly accessible? In the long term (a few years) the problem will go away as SPI masters move into every chipset, but as long as boards are using extra components between the CPU and the flash chip, there can be issues like this. If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad. It would be unfortunate to drop support for one of the most hack friendly boards that we've seen in a while. But FLASH is so slow I doubt that the cost of an accessor function is going to kill us. Function calls run in nanoseconds, and if SPI really is only 40 MB/sec., then that's 25 ns/byte. 40 Mbyte/s seems way optimistic to me. In the ideal case it's possible to stream all of the data out of the chip without overhead, and even then it's CLK/8 Mbyte/s. I think the fastest CLK I've seen recently is 90 MHz but the superio SPI masters only run at 16 MHz. (=2Mbyte/s assuming no overhead, which is far from the norm, it's common to have several bytes overhead for each 256 bytes of data) Chipsets could run faster, but not all flash chips can run super fast either. 25-33 somewhere would be the safe number. Max CLK seems to increase with size and each flash chip product generation though. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On Wed, Sep 30, 2009 at 3:43 PM, Peter Stuge pe...@stuge.se wrote: 40 Mbyte/s seems way optimistic to me Yeah, I was going worst-case scenario (i.e. SPI is super-fast) and even in that case accessor functions would not hurt much if at all. So if we absolutely *have* to do some sort of function interface, well, it won't exactly kill us. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Myles Watson wrote: -#if CONFIG_CBFS == 1 -# if CONFIG_USE_FALLBACK_IMAGE == 1 +#if CONFIG_USE_FALLBACK_IMAGE == 1 str_coreboot_ram_name: .string fallback/coreboot_ram -# else +#else str_coreboot_ram_name: .string normal/coreboot_ram -# endif #endif Since normal and failover aren't supported with CBFS, can they disappear too? No, we should get that back to life with CBFS asap.. it's one of coreboot's key features.. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Since normal and failover aren't supported with CBFS, can they disappear too? No, we should get that back to life with CBFS asap.. it's one of coreboot's key features.. Good to know. It seemed like it was being slowly removed. I'm interested to see how it integrates with Kconfig. It's not obvious to me how it will work. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it. As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image. CBFS will give us a normal/fallback setup that people can understand. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On 01.10.2009 01:07, ron minnich wrote: Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it. As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image. CBFS will give us a normal/fallback setup that people can understand. Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar-cbfs on that file? As a nice side benefit, we get global variables and similar stuff. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On Thu, Oct 01, 2009 at 12:51:17AM +0200, Stefan Reinauer wrote: Myles Watson wrote: Since normal and failover aren't supported with CBFS, can they disappear too? No, we should get that back to life with CBFS asap.. it's one of coreboot's key features.. What's the use case for normal/failover? I always envisioned it as a software implementation of a bios savior. If so, building in a serialice shell might be a simpler solution. Am I missing an important use-case? -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On Wed, Sep 30, 2009 at 4:23 PM, Kevin O'Connor ke...@koconnor.net wrote: What's the use case for normal/failover? I always envisioned it as a software implementation of a bios savior. If so, building in a serialice shell might be a simpler solution. Am I missing an important use-case? I'm flashing 1024 machines. power fails midway through. bad. I flash a new bios that has worked in test. It fails on 10% of the machines, in ways that could not be predicted because 10% of my machines have a manufacturing defect. This is what happened to me. Fallback saved me. There are lots of use cases. It's why many vendors ship with a fallback. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On Wed, Sep 30, 2009 at 4:16 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar-cbfs on that file? As a nice side benefit, we get global variables and similar stuff. I've looked into doing just that. It's not as simple as it sounds. I'd rather not open that can of worms just yet. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On 01.10.2009 00:32, ron minnich wrote: can anyone even buy an m57sli any more? Was it an unfortunate mistake -- never repeated -- that FLASH was not directly accessible? If the m57sli is an exception and we'll never see this problem again, I say we drop it. Copying all of flash into ram sounds bad. If we have to cope with this problem in future, maybe we're stuck with accessor functions. But FLASH is so slow I doubt that the cost of an accessor function is going to kill us. Function calls run in nanoseconds, and if SPI really is only 40 MB/sec., then that's 25 ns/byte. The accessor function has the disadvantage of ruining readability of the code, and it also has to perform these extremely slow accesses every time someone walks the CBFS image. AFAIK the M57SLI worst case read performance is ~400 kB/s, and the best case is ~855 kB/s. Each one-byte read access to flash needs at least 2.5 us (microseconds), and a three-byte read access needs at least 3.5 us. If your flash chip can handle 33 MHz with the normal read command (instead of the fast read command), flash access latency will be cut in half and data rate will be doubled. While using accessor functions look somewhat beneficial from a performance standpoint, using accessor functions to run the lzma decompressor is way slower (I think by at least a factor of 4) than copying the uncompressed code to RAMand decompressing it there. My suggestion would be to drop support for these large flash chips on M57SLI for now and use the copy-to-RAM mechanism once someone complains. I think Harald Gutmann has such a board with big flash. Regads, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On 01.10.2009 01:27, ron minnich wrote: On Wed, Sep 30, 2009 at 4:16 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar-cbfs on that file? As a nice side benefit, we get global variables and similar stuff. I've looked into doing just that. It's not as simple as it sounds. I'm surprised. My stage1 SMP patch was never merged IIRC, so stack trashing is expected on any non-UP v3 boot. But other than that, v3 stage1 code worked pretty well. The ELFboot code in there should be dropped (was default off anyway) and then we have a pretty readable startup. I'd rather not open that can of worms just yet. If you're talking about doing too many things at once, I fully agree. Once the tree is CBFS-only and once Kconfig works for all actively developed boards, we will have a mostly stable tree again and it would be cool to look at importing stage1 (and possibly stage0) from v3. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
ron minnich wrote: Yeah, I was going worst-case scenario (i.e. SPI is super-fast) and even in that case accessor functions would not hurt much if at all. Ah! So if we absolutely *have* to do some sort of function interface, well, it won't exactly kill us. I think it would be great to not have to deal with that in the common case, but I think it can be useful for some boards - ie. if there is would I think it would be best to make it optional. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Carl-Daniel Hailfinger wrote: On 01.10.2009 01:07, ron minnich wrote: Yes, I'm sorry, we keep board support, but stop worrying about huge SPI anbd weird accessing of it. As for fallback: we really need to bring it back at some point. I'm speaking as someone whose life was saved because I did not destroy a 1024-node cluster with a bad bios image. CBFS will give us a normal/fallback setup that people can understand. Could we simply reuse arch/x86/stage1.c from v3 and run a search+replace lar-cbfs on that file? As a nice side benefit, we get global variables and similar stuff. No search and replace blind copy of non-fitting code please. The least we can use in v2 right now is a code quality drop to v3 level .. One step after the other.. It's not enough to have one board running. If you have a solution to safely bring over 200 boards, please do it! Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Kevin O'Connor wrote: On Thu, Oct 01, 2009 at 12:51:17AM +0200, Stefan Reinauer wrote: Myles Watson wrote: Since normal and failover aren't supported with CBFS, can they disappear too? No, we should get that back to life with CBFS asap.. it's one of coreboot's key features.. What's the use case for normal/failover? I always envisioned it as a software implementation of a bios savior. If so, building in a serialice shell might be a simpler solution. SerialICE is more or less a development tool.. it won't help you with misflashed units in the field. Safe updates and safe recovery is the key. Details are quite open though, the fallback image could carry some kind of shell, while the real one goes SeaBIOS; depending on how people want to boot, and how they want to recover. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Patrick Georgi wrote: Hi, attached patch removes: - CONFIG_CBFS - anything that's conditional on CONFIG_CBFS == 0 - files that were only included for CONFIG_CBFS == 0 In particular: - elfboot - stream boot code - mini-filo and filesystems (depends on stream boot code) After this patch, there is no way to build an image that is not using CBFS anymore. I might not have caught everything, but an abuild run over everything built fine, and there is no mention of CBFS in the tree anymore that doesn't belong there. Kconfig is almost not affected, as it's CBFS-only, anyway. I only had to remove the CBFS configuration variable that defaulted to true. I consider the tree ready for this as there are no known bugs anymore (except the one fixed by that other patch). Speak up if you disagree (I intend to wait with committing this patch until saturday evening CEST) Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
On Wed, Sep 30, 2009 at 04:26:44PM -0700, ron minnich wrote: On Wed, Sep 30, 2009 at 4:23 PM, Kevin O'Connor ke...@koconnor.net wrote: What's the use case for normal/failover? I always envisioned it as a software implementation of a bios savior. If so, building in a serialice shell might be a simpler solution. Am I missing an important use-case? I'm flashing 1024 machines. power fails midway through. bad. Ouch. So, I guess we're saying it's a software bios savior that doesn't require one to go hitting 1000 switches? As an aside, to protect against a power failure, flashrom is going to need to know that it shouldn't reflash the fallback parts of the image. I flash a new bios that has worked in test. It fails on 10% of the machines, in ways that could not be predicted because 10% of my machines have a manufacturing defect. This is what happened to me. Fallback saved me. Ouch - I guess hooking up a serialice console to 100 machines isn't an appealing alternative. Just to throw my 2cents in -- the coreboot fallback/normal thing has been thoroughly confusing to me. If this is being re-implemented it would be nice to see this done in a way that makes sense to users. One suggestion I have - assuming my bios savior analogy is correct - would be to truly break up the fallback and normal parts. A user that wants fallback/normal should download two separate copies of coreboot-v2 into two separate directories, and then run make config ; make in both separate directories. The normal config would take the directory location of the fallback cbfs image, copy it into its local directory, and then just add the cbfs files it needs. In particular, I'd like to be able to go into my normal directory and run svn up, make, and then flashrom - and be fairly confident that I didn't just blow up my image. As near as I can tell, the current fallback/normal thing recompiles both fallback and normal images, and there's a pretty good chance that both images are hosed when code changes are made. (Of course, as I said before, fallback/normal has me perplexed, so maybe I just missed the boat.) -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Stefan Reinauer wrote: Safe updates and safe recovery is the key. Details are quite open though, the fallback image could carry some kind of shell, Maybe this touches on the panic room. depending on how people want to boot, and how they want to recover. Yeah, this is important. A panic room should not be too ambitious, or it might not be quite as reliable as we would like. If very simple, it may not be a good choice also for fallback. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
Author: rminnich
Date: 2009-10-01 02:02:28 +0200 (Thu, 01 Oct 2009)
New Revision: 4698
Modified:
trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
Log:
This is now set up more like the real hardware likes it.
Some of this trickery was determined with serialice.
There are several lovely undocumented features to the chipset.
Signed-off-by: Ronald G. Minnich rminn...@gmail.com
Acked-by: Ronald G. Minnich rminn...@gmail.com
Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
===
--- trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c 2009-09-30 21:36:38 UTC
(rev 4697)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c 2009-10-01 00:02:28 UTC
(rev 4698)
@@ -173,8 +173,13 @@
}
/* end IPMI garbage */
+
static void main(unsigned long bist)
{
+ u8 b;
+ u16 w;
+ u32 l;
+ int do_reset;
/*
*
*
@@ -191,6 +196,80 @@
}
};
+ /* using SerialICE, we've seen this basic reset sequence on the dell.
+* we don't understand it as it uses undocumented registers, but
+* we're going to clone it.
+*/
+ /* enable a hidden device. */
+ b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4);
+ b |= 0x8;
+ pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b);
+
+ /* read-write lock in CMOS on LPC bridge on ICH5 */
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd8, 4);
+
+ /* operate on undocumented device */
+ l = pci_read_config32(PCI_DEV(0, 0, 2), 0xa4);
+ l |= 0x1000;
+ pci_write_config32(PCI_DEV(0, 0, 2), 0xa4, l);
+
+ l = pci_read_config32(PCI_DEV(0, 0, 2), 0x9c);
+ l |= 0x8000;
+ pci_write_config32(PCI_DEV(0, 0, 2), 0x9c, l);
+
+ /* disable undocumented device */
+ b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4);
+ b = ~0x8;
+ pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b);
+
+ /* set up LPC bridge bits, some of which reply on undocumented
+* registers
+*/
+
+ b= pci_read_config8(PCI_DEV(0, 0x1f, 0), 0xd8);
+ b |= 4;
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd8, b);
+
+ b= pci_read_config8(PCI_DEV(0, 0x1f, 0), 0xd4);
+ b |= 2;
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd4, b);
+
+ /* ACPI base address */
+ pci_write_config16(PCI_DEV(0, 0x1f, 0), 0x40, 0x800);
+
+ /* Enable specific ACPI features */
+ b= pci_read_config8(PCI_DEV(0, 0x1f, 0), 0x44);
+ b |= 0x10;
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0x44, b);
+
+ /* ACPI control */
+ w = inw(0x868);
+ outw(w|0x800, 0x868);
+ w = inw(0x866);
+ outw(w|2, 0x866);
+
+ /* SMBUS */
+ pci_write_config16(PCI_DEV(0, 0x1f, 3), 0x20, 0x08c0);
+
+ /* unknown */
+ b = inb(0x8c2);
+ outb(0xdf, 0x8c2);
+
+ /* another device enable? */
+ b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4);
+ b |= 2;
+ pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b);
+
+ /* ?? */
+ l = pci_read_config32(PCI_DEV(0, 0, 8), 0xc0);
+ do_reset = l 0x800;
+ l |= 0x800;
+ pci_write_config32(PCI_DEV(0, 0, 2), 0xc0, l);
+
+ if (! do_reset) {
+ outb(2, 0xcf9);
+ outb(6, 0xcf9);
+ }
if (bist == 0) {
/* Skip this if there was a built in self test failure */
early_mtrr_init();
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
The fallback should work like the normal does. What you want, if things go wrong, is something that works as much like what you're used to as possible, so that you can recover easily. The worst thing you can do, if things go wrong, is drop users into an unfamiliar environment that sends them scurrying around looking for the manuals. The panic room should look just like the normal room, save it has a big sign that says Don't Panic. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Remove non-CBFS
Kevin O'Connor wrote: As an aside, to protect against a power failure, flashrom is going to need to know that it shouldn't reflash the fallback parts of the image. Yes. flashrom should know CBFS. truly break up the fallback and normal parts. I see a few problem with normal and fallback as they have been in v2 previously; It was not well understood how to produce them. It was not well understood how they were combined. And finally it was not well understood how one of the two were selected. CBFS and Kconfig fixes the hard parts; the first two. I see cbfstool being a crucial part of safe updates. Initially cbfstool might have to be run manually (or even just flashrom) but we should look into how Kconfig and the build system can take an existing CBFS as input, and only build/replace the normal part. In particular, I'd like to be able to go into my normal directory and run svn up, make, and then flashrom - and be fairly confident that I didn't just blow up my image. Two directories strikes me as pretty complicated but I do get your point - it should be really easy to rebuild and flash normal, without touching anything else. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
s...@coreboot.org wrote:
Author: rminnich
Date: 2009-10-01 02:02:28 +0200 (Thu, 01 Oct 2009)
New Revision: 4698
Modified:
trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
Log:
This is now set up more like the real hardware likes it.
Some of this trickery was determined with serialice.
There are several lovely undocumented features to the chipset.
Signed-off-by: Ronald G. Minnich rminn...@gmail.com
Acked-by: Ronald G. Minnich rminn...@gmail.com
:-) Nice
Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
===
--- trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c 2009-09-30 21:36:38 UTC
(rev 4697)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c 2009-10-01 00:02:28 UTC
(rev 4698)
@@ -173,8 +173,13 @@
}
/* end IPMI garbage */
+
static void main(unsigned long bist)
{
+ u8 b;
+ u16 w;
+ u32 l;
+ int do_reset;
/*
*
*
@@ -191,6 +196,80 @@
}
};
+ /* using SerialICE, we've seen this basic reset sequence on the dell.
+ * we don't understand it as it uses undocumented registers, but
+ * we're going to clone it.
+ */
+ /* enable a hidden device. */
+ b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4);
+ b |= 0x8;
+ pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b);
+
+ /* read-write lock in CMOS on LPC bridge on ICH5 */
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd8, 4);
+
+ /* operate on undocumented device */
Can you dump the pci config space or read the pci id of that device?
+ l = pci_read_config32(PCI_DEV(0, 0, 2), 0xa4);
+ l |= 0x1000;
+ pci_write_config32(PCI_DEV(0, 0, 2), 0xa4, l);
+
+ l = pci_read_config32(PCI_DEV(0, 0, 2), 0x9c);
+ l |= 0x8000;
+ pci_write_config32(PCI_DEV(0, 0, 2), 0x9c, l);
+
+ /* disable undocumented device */
+ b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4);
+ b = ~0x8;
+ pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b);
+
+ /* set up LPC bridge bits, some of which reply on undocumented
+ * registers
+ */
+
+ b= pci_read_config8(PCI_DEV(0, 0x1f, 0), 0xd8);
+ b |= 4;
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd8, b);
+
+ b= pci_read_config8(PCI_DEV(0, 0x1f, 0), 0xd4);
+ b |= 2;
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd4, b);
+
+ /* ACPI base address */
+ pci_write_config16(PCI_DEV(0, 0x1f, 0), 0x40, 0x800);
bit 0 is hard wired to 1 so it doesn't matter much I guess.
+
+ /* Enable specific ACPI features */
+ b= pci_read_config8(PCI_DEV(0, 0x1f, 0), 0x44);
+ b |= 0x10;
+ pci_write_config8(PCI_DEV(0, 0x1f, 0), 0x44, b);
+
+ /* ACPI control */
+ w = inw(0x868);
+ outw(w|0x800, 0x868);
+ w = inw(0x866);
+ outw(w|2, 0x866);
This is something in the TCO area, probably disabling the watchdog
+
+ /* SMBUS */
+ pci_write_config16(PCI_DEV(0, 0x1f, 3), 0x20, 0x08c0);
+
+ /* unknown */
+ b = inb(0x8c2);
+ outb(0xdf, 0x8c2);
+
+ /* another device enable? */
+ b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4);
+ b |= 2;
+ pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b);
+
+ /* ?? */
+ l = pci_read_config32(PCI_DEV(0, 0, 8), 0xc0);
+ do_reset = l 0x800;
+ l |= 0x800;
+ pci_write_config32(PCI_DEV(0, 0, 2), 0xc0, l);
+
+ if (! do_reset) {
+ outb(2, 0xcf9);
+ outb(6, 0xcf9);
+ }
if (bist == 0) {
/* Skip this if there was a built in self test failure */
early_mtrr_init();
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4698
Dear coreboot readers! This is the automatic build system of coreboot. The developer rminnich checked in revision 4698 to the coreboot repository. This caused the following changes: Change Log: This is now set up more like the real hardware likes it. Some of this trickery was determined with serialice. There are several lovely undocumented features to the chipset. Signed-off-by: Ronald G. Minnich rminn...@gmail.com Acked-by: Ronald G. Minnich rminn...@gmail.com Build Log: Compilation of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4698device=ep405pcvendor=embeddedplanetnum=2 Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4698device=sandpointx3_altimus_mpc7410vendor=motorolanum=2 Compilation of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4698device=briqvendor=totalimpactnum=2 If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
On Wed, Sep 30, 2009 at 5:11 PM, Stefan Reinauer ste...@coresystems.de wrote: :-) Nice Sorry. I just assumed nobody would even care about this antique. Hope no one is too annoyed by the self-ack. + /* operate on undocumented device */ Can you dump the pci config space or read the pci id of that device? no, because the Dell BIOS turns it completely off. + /* ACPI base address */ + pci_write_config16(PCI_DEV(0, 0x1f, 0), 0x40, 0x800); bit 0 is hard wired to 1 so it doesn't matter much I guess. yes, I'm cloning what they do by watching IO with serialice. They did not read it and or it in in this one case. lotsa magic bits here. This is a really old part so I'm a little surprised. Not too much, any more. Going to have a long delay now while I convert to CAR. Also having a meeting in 2 weeks that may kill the whole project. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
On Wed, Sep 30, 2009 at 5:02 PM, s...@coreboot.org wrote: + /* using SerialICE, we've seen this basic reset sequence on the dell. + * we don't understand it as it uses undocumented registers, but + * we're going to clone it. + */ + /* enable a hidden device. */ + b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4); + b |= 0x8; + pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b); + + /* read-write lock in CMOS on LPC bridge on ICH5 */ + pci_write_config8(PCI_DEV(0, 0x1f, 0), 0xd8, 4); + + /* operate on undocumented device */ + l = pci_read_config32(PCI_DEV(0, 0, 2), 0xa4); + l |= 0x1000; + pci_write_config32(PCI_DEV(0, 0, 2), 0xa4, l); + + l = pci_read_config32(PCI_DEV(0, 0, 2), 0x9c); + l |= 0x8000; + pci_write_config32(PCI_DEV(0, 0, 2), 0x9c, l); + + /* disable undocumented device */ + b = pci_read_config8(PCI_DEV(0, 0, 0), 0xf4); + b = ~0x8; + pci_write_config8(PCI_DEV(0, 0, 0), 0xf4, b); http://downloadmirror.intel.com/8815/ENG/README.TXT offers a hint about what this is doing, but doesn't really explain why: According MCH BSU 0.82, document#64:Required Register Settings. To take full advantage of the changes in the MCH Silicon, for stability on MCH B0 stepping and above, Intel recommends that BIOS clear bit 12 of D0:F2:R0A4h and set bit 15 of D0:F2:R09Ch very early during boot. --Ed -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS and USB UHCI keyboard support
On Wed, Sep 30, 2009 at 09:18:21PM +0200, Peter Stuge wrote: Kevin O'Connor wrote: The support in SeaBIOS is currently 1029 lines of code - it is a direct, no nonsense, just make it work implementation. I think that is wonderful! Good job! Thanks! The next thing I am planning to look at is basic ohci keyboard support, and then fleshing out the current keyboard support (eg, auto-repeat, keyboard leds). The USB option ROM is still a tricky point. How to make it co-exist with USB support in SeaBIOS? As Stefan pointed out, there can be only one driver of a usb controller. Anything else would be too fragile. If the option ROM works out well, maybe it could instead offer the keyboard services? Yes - an option ROM can support keyboard. However, a real 16bit option ROM implementation is going to impose the same constraints on libpayload as SeaBIOS. Alternatively, the option rom could give up support for vm86 mode callers and reserve lots of high ram to avoid those constraints. It still wouldn't be simple - the rom would need to implement the bios calls for disk and kbd (seabios src/disk.c src/kbd.c src/bregs.h src/entryfuncs.S = 1792 lines of code) and may need to implement self uncompression (to reduce its rom code size). I'd say it's doable, but not easy. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
Ed Swierk wrote: http://downloadmirror.intel.com/8815/ENG/README.TXT offers a hint about what this is doing, but doesn't really explain why: .. for stability on MCH B0 stepping and above, A secret/magic erratum. Yippee. :) //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS and USB UHCI keyboard support
Kevin O'Connor wrote: The USB option ROM is still a tricky point. How to make it co-exist with USB support in SeaBIOS? As Stefan pointed out, there can be only one driver of a usb controller. Anything else would be too fragile. Yeah. The debug port can be used in parallell with another USB stack, but that's only good for debug transfers. If the option ROM works out well, maybe it could instead offer the keyboard services? Yes - an option ROM can support keyboard. .. I'd say it's doable, but not easy. I don't know what the result was/is from the GSoC project. You are aware that there has been a GSoC project for a USB option ROM, right? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
On Oct 1, 2009, at 2:44, ron minnich rminn...@gmail.com wrote: On Wed, Sep 30, 2009 at 5:11 PM, Stefan Reinauer ste...@coresystems.de wrote: :-) Nice Sorry. I just assumed nobody would even care about this antique. Hope no one is too annoyed by the self-ack. + /* operate on undocumented device */ Can you dump the pci config space or read the pci id of that device? no, because the Dell BIOS turns it completely off. There's a pci config space dumper in one or two of the debug.c versions + /* ACPI base address */ + pci_write_config16(PCI_DEV(0, 0x1f, 0), 0x40, 0x800); bit 0 is hard wired to 1 so it doesn't matter much I guess. yes, I'm cloning what they do by watching IO with serialice. They did not read it and or it in in this one case. lotsa magic bits here. This is a really old part so I'm a little surprised. Not too much, any more. Going to have a long delay now while I convert to CAR. Also having a meeting in 2 weeks that may kill the whole project. Sure you want to add new points of failure? ;-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Boot issues (CBFS?) on VIA pc2500e
Hi, tried to boot-test the VIA p2500e yesterday, but tried a manual non-kconfig build first, and that one doesn't successfully boot anymore and thus needs to be fixed first. The cfbs output was (I used a FILO payload): Name Offset Type Size fallback/payload 0x0payload 85864 fallback/coreboot_ram 0x14fc0stage35069 0x1d900null 337592 Here's a bootlog, there's a hang at the end, no further output on serial afterwards. Any ideas what the issue may be? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org coreboot-2.0.0-r4697-pc2500e Thu Oct 1 00:04:48 CEST 2009 booting... Calibrating delay loop... end 2cb8ad7b3, start 1dc56e326 32-bit delta 3827 calibrate_tsc 32-bit result is 3827 clocks_per_usec: 3827 Enumerating buses... Show all devs...Before Device Enumeration. Root Device: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:00.1: enabled 1, 0 resources PCI: 00:00.2: enabled 1, 0 resources PCI: 00:00.3: enabled 1, 0 resources PCI: 00:00.4: enabled 1, 0 resources PCI: 00:00.7: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:0f.0: enabled 1, 0 resources PCI: 00:0f.1: enabled 1, 0 resources PCI: 00:10.0: enabled 1, 0 resources PCI: 00:10.1: enabled 1, 0 resources PCI: 00:10.2: enabled 1, 0 resources PCI: 00:10.3: enabled 1, 0 resources PCI: 00:10.4: enabled 1, 0 resources PCI: 00:10.5: enabled 1, 0 resources PCI: 00:11.0: enabled 1, 0 resources PNP: 002e.0: enabled 1, 3 resources PNP: 002e.1: enabled 1, 2 resources PNP: 002e.2: enabled 0, 2 resources PNP: 002e.3: enabled 1, 3 resources PNP: 002e.4: enabled 1, 3 resources PNP: 002e.5: enabled 0, 3 resources PNP: 002e.6: enabled 0, 1 resources PNP: 002e.7: enabled 1, 3 resources PNP: 002e.8: enabled 0, 2 resources PNP: 002e.9: enabled 0, 1 resources PNP: 002e.a: enabled 1, 2 resources PCI: 00:11.5: enabled 1, 0 resources PCI: 00:12.0: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources Compare with tree... Root Device: enabled 1, 0 resources PCI_DOMAIN: : enabled 1, 0 resources PCI: 00:00.0: enabled 1, 0 resources PCI: 00:00.1: enabled 1, 0 resources PCI: 00:00.2: enabled 1, 0 resources PCI: 00:00.3: enabled 1, 0 resources PCI: 00:00.4: enabled 1, 0 resources PCI: 00:00.7: enabled 1, 0 resources PCI: 00:01.0: enabled 1, 0 resources PCI: 00:0f.0: enabled 1, 0 resources PCI: 00:0f.1: enabled 1, 0 resources PCI: 00:10.0: enabled 1, 0 resources PCI: 00:10.1: enabled 1, 0 resources PCI: 00:10.2: enabled 1, 0 resources PCI: 00:10.3: enabled 1, 0 resources PCI: 00:10.4: enabled 1, 0 resources PCI: 00:10.5: enabled 1, 0 resources PCI: 00:11.0: enabled 1, 0 resources PNP: 002e.0: enabled 1, 3 resources PNP: 002e.1: enabled 1, 2 resources PNP: 002e.2: enabled 0, 2 resources PNP: 002e.3: enabled 1, 3 resources PNP: 002e.4: enabled 1, 3 resources PNP: 002e.5: enabled 0, 3 resources PNP: 002e.6: enabled 0, 1 resources PNP: 002e.7: enabled 1, 3 resources PNP: 002e.8: enabled 0, 2 resources PNP: 002e.9: enabled 0, 1 resources PNP: 002e.a: enabled 1, 2 resources PCI: 00:11.5: enabled 1, 0 resources PCI: 00:12.0: enabled 1, 0 resources APIC_CLUSTER: 0: enabled 1, 0 resources APIC: 00: enabled 1, 0 resources scan_static_bus for Root Device In cn700 enable_dev for device PCI_DOMAIN: . Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: enabled In cn700 enable_dev for device APIC_CLUSTER: 0. APIC_CLUSTER: 0 enabled PCI_DOMAIN: scanning... PCI: pci_scan_bus for bus 00 In cn700 enable_dev for device PCI: 00:00.0. PCI: 00:00.0 [1106/0314] ops PCI: 00:00.0 [1106/0314] enabled In cn700 enable_dev for device PCI: 00:00.1. PCI: 00:00.1 [1106/1314] enabled In cn700 enable_dev for device PCI: 00:00.2. PCI: 00:00.2 [1106/2314] enabled In cn700 enable_dev for device PCI: 00:00.3. PCI: 00:00.3 [1106/3208] ops PCI: 00:00.3 [1106/3208] enabled In cn700 enable_dev for device PCI: 00:00.4. PCI: 00:00.4 [1106/4314] enabled PCI: 00:00.5, bad id 0x PCI: 00:00.6, bad id 0x In cn700 enable_dev for device PCI: 00:00.7. PCI: 00:00.7 [1106/7314] enabled In cn700 enable_dev for device PCI: 00:01.0. PCI: 00:01.0 [1106/b198] bus ops PCI: 00:01.0 [1106/b198] enabled PCI: 00:02.0, bad id 0x PCI: 00:03.0, bad id 0x PCI: 00:04.0, bad id 0x PCI: 00:05.0, bad id 0x PCI: 00:06.0, bad id 0x PCI: 00:07.0, bad id 0x PCI: 00:08.0, bad id 0x PCI: 00:09.0, bad id 0x PCI: 00:0a.0, bad id 0x PCI: 00:0b.0, bad id 0x PCI: 00:0c.0, bad id 0x PCI: 00:0d.0, bad id 0x PCI: 00:0e.0, bad id 0x PCI: 00:0f.0 [1106/3149] ops PCI: 00:0f.0 [1106/3149] enabled PCI:
Re: [coreboot] [v2] r4698 - trunk/coreboot-v2/src/mainboard/dell/s1850
On Wed, Sep 30, 2009 at 5:44 PM, ron minnich rminn...@gmail.com wrote: On Wed, Sep 30, 2009 at 5:11 PM, Stefan Reinauer ste...@coresystems.de wrote: + /* operate on undocumented device */ Can you dump the pci config space or read the pci id of that device? no, because the Dell BIOS turns it completely off. It shouldn't harm anything to leave the undocumented device enabled. Then you can boot Linux and sniff around with lspci. --Ed -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Boot issues (CBFS?) on VIA pc2500e
Can you try without cbfs? Did it work with cbfs before? If the issue is new, can you bisect where it happened? On Oct 1, 2009, at 3:30, Uwe Hermann u...@hermann-uwe.de wrote: Hi, tried to boot-test the VIA p2500e yesterday, but tried a manual non-kconfig build first, and that one doesn't successfully boot anymore and thus needs to be fixed first. The cfbs output was (I used a FILO payload): Name Offset Type Size fallback/payload 0x0payload 85864 fallback/coreboot_ram 0x14fc0stage35069 0x1d900null 337592 Here's a bootlog, there's a hang at the end, no further output on serial afterwards. Any ideas what the issue may be? Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org minicom_pc2500e_cbfs_nokconfig.txt -- 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] Boot issues (CBFS?) on VIA pc2500e
-Original Message- From: coreboot-bounces+mylesgw=gmail@coreboot.org [mailto:coreboot- bounces+mylesgw=gmail@coreboot.org] On Behalf Of Uwe Hermann Sent: Wednesday, September 30, 2009 7:31 PM To: coreboot@coreboot.org Subject: [coreboot] Boot issues (CBFS?) on VIA pc2500e Hi, tried to boot-test the VIA p2500e yesterday, but tried a manual non-kconfig build first, and that one doesn't successfully boot anymore and thus needs to be fixed first. The cfbs output was (I used a FILO payload): Name Offset Type Size fallback/payload 0x0payload 85864 fallback/coreboot_ram 0x14fc0stage35069 0x1d900null 337592 Here's a bootlog, there's a hang at the end, no further output on serial afterwards. Any ideas what the issue may be? It doesn't look like a place I would expect CBFS to be the issue. tomk is 0x8 tom: 2000, high_tables_base: 1fff, high_tables_size: 1 512M of RAM = 0x2000, 64K for high tables. ... High Tables Base is 1fff. Copying Interrupt Routing Table to 0x000f... done. Copying Interrupt Routing Table to 0x1fff... done. Wrote the mp table end at: 000f0410 - 000f0568 Wrote the mp table end at: 1fff0410 - 2001040e Writing high tables above RAM! Why is the high MP table so much larger than the low one? Moving GDT to 0x20010800...ok Multiboot Information structure has been written. Writing high table forward entry at 0x0500 Wrote coreboot table at: 0500 - 0518 checksum d3dd New low_table_end: 0x0518 Now going to write high coreboot table at 0x20010c00 rom_table_end = 0x20010c00 Adjust low_table_end from 0x0518 to 0x1000 Adjust rom_table_end from 0x20010c00 to 0x2002 And more writing above RAM. I don't know that that is the cause of your trouble, but it isn't good. An easy thing to try would be to increase high_tables_size to 0x4 and see if you get anything different. I'm surprised that your mp table is so large. Maybe that's where the real problem is? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
