Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
* Scott Duplichan sc...@notabs.org [110225 02:02]: Stefan Reinauer wrote: ] +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) ]if CONFIG_SIO_PORT is defined in Kconfig (why?) we could as well use it ]in romstage.c. Is there a chance to remove it from Kconfig instead? Certainly the two occurrences of 2e is not ideal. This change works: -#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) +#define SERIAL_DEV PNP_DEV(CONFIG_SIO_PORT, W83627HF_SP1) That would work. Or leave the first version and we try to get rid of the Kconfig variable later on... Anyways Acked-by: Stefan Reinauer stefan.reina...@coreboot.org I believe most SIOs have a strap option for 4e, so presumably this address needs to be project selectable by some method. Phoenix legacy BIOS actually figures it out at runtime. That method seems dangerous to me and makes stepping through the code tedious. You can certainly detect where it lives and what kind of device it is (though I have not seen Phoenix do that during runtime on intel systems, according to SerialICE) .. The one thing I think you can not probe is how the ports are wired up (i.e. if you have two Super I/O chips, is the one serial port connected to the first or second chip) If we remove it from kconfig, would it just be local to romstage.c? I suppose this would be a separate patch, given the number of projects affected. There's always at least another occurence in devicetree.cb. But that is not used in romstage, only in ramstage. Maybe it is time to think about extending the devicetree.cb so it can be used by romstage, too? But that's for another mail. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [FILO] Artec loader with initrd
* Nathan Williams nat...@traverse.com.au [110225 03:08]: When using Artec loader and no file system, use dev_name for initrd instead of flashb. Signed-off-by: Nathan Williams nat...@traverse.com.au Thanks, r141 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [FILO] Artec loader with NULLFS
* Nathan Williams nat...@traverse.com.au [110225 03:34]: load_linux_kernel() checks using_devsize, so we need to clear it if we are using Artec loader without a file system. Signed-off-by: Nathan Williams nat...@traverse.com.au Thanks, r142 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 2/5] libpayload: Some more standard types and defines
* Patrick Georgi patrick.geo...@secunet.com [110225 13:02]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com --- payloads/libpayload/include/limits.h |2 ++ payloads/libpayload/include/stdint.h |5 + 2 files changed, 7 insertions(+), 0 deletions(-) Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/5] libpayload: Implement ffs()
* Patrick Georgi patrick.geo...@secunet.com [110225 13:11]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com --- payloads/libpayload/include/strings.h | 35 payloads/libpayload/libc/Makefile.inc |2 +- payloads/libpayload/libc/strings.c| 40 + 3 files changed, 76 insertions(+), 1 deletions(-) create mode 100644 payloads/libpayload/include/strings.h create mode 100644 payloads/libpayload/libc/strings.c diff --git a/payloads/libpayload/include/strings.h b/payloads/libpayload/include/strings.h new file mode 100644 index 000..ce7fe93 --- /dev/null +++ b/payloads/libpayload/include/strings.h @@ -0,0 +1,35 @@ +#ifndef _STRING_H +#define _STRING_H This should be _STRINGS_H otherwise it can/will conflict. Otherwise Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 5/5] libpayload: Add more libpci-compatibility (#defines)
* Patrick Georgi patrick.geo...@secunet.com [110225 13:40]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com --- payloads/libpayload/include/pci.h |2 ++ payloads/libpayload/include/pci/pci.h | 26 ++ 2 files changed, 28 insertions(+), 0 deletions(-) Nice! Acked-by: Stefan Reinauer stefan.reina...@coreboot.org Is there some (public) documentation on how to use flashrom as a payload, or is there a chance you could publish this? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 1/5] libpayload: Add lib/ to the default library path of lpgcc, so -l works
* Patrick Georgi patrick.geo...@secunet.com [110225 14:09]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com --- payloads/libpayload/bin/lpgcc |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 4/5] libpayload: Implement pci_cleanup() to make flashrom happy
* Patrick Georgi patrick.geo...@secunet.com [110225 14:09]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com --- payloads/libpayload/include/pci/pci.h |1 + payloads/libpayload/libpci/libpci.c |6 +- 2 files changed, 6 insertions(+), 1 deletions(-) Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] outb(* 0x80) to post_code()
* Alex G. mr.nuke...@gmail.com [110225 18:48]:
Find attached the version with the colloquial verbiage abridged.
Alex
Remove all occurences of outb(*, 0x80), and replace them with
post_code().
Create post_codes.h to store a central place for post codes.
Replace common post_codes with macros defined in post_codes.h.
Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com
Hi Alexandru,
thanks a lot, nice patch! I have a few comments below though.
Index: src/southbridge/via/vt8231/early_smbus.c
===
--- src/southbridge/via/vt8231/early_smbus.c (revision 6380)
+++ src/southbridge/via/vt8231/early_smbus.c (working copy)
@@ -1,3 +1,5 @@
+#include console/console.h
+
#define SMBUS_IO_BASE 0x5000
#define SMBHSTSTAT 0x0
@@ -54,7 +56,7 @@
static inline void smbus_delay(void)
{
- outb(0x80, 0x80);
+ post_code(POST_SMBUS_DELAY);
}
This should not be an outb to 0x80 at all, as it does not reflect a
post_code debug message but rather a delay. I suggest that you either
use an inb(0x80) or an outb to port 0xeb or something instead.
Index: src/southbridge/via/vt8235/early_smbus.c
===
--- src/southbridge/via/vt8235/early_smbus.c (revision 6380)
+++ src/southbridge/via/vt8235/early_smbus.c (working copy)
@@ -1,4 +1,5 @@
#define SMBUS_IO_BASE 0xf00
+#include console/console.h
#define SMBHSTSTAT 0x0
#define SMBSLVSTAT 0x1
@@ -52,7 +53,7 @@
/* let clocks and the like settle */
/* as yet arbitrary count - 1000 is too little 5000 works */
for(i = 0 ; i 5000 ; i++)
- outb(0x80,0x80);
+ post_code(POST_SMBUS_DELAY);
same here.
/*
* The VT1211 serial port needs 48 mhz clock, on power up it is getting
@@ -75,7 +76,7 @@
static inline void smbus_delay(void)
{
- outb(0x80, 0x80);
+ post_code(POST_SMBUS_DELAY);
}
and here.
+ post_code( P80_CHIPSET_INIT );
No spaces required left and right.
Index: src/southbridge/amd/sb600/smbus.c
===
--- src/southbridge/amd/sb600/smbus.c (revision 6380)
+++ src/southbridge/amd/sb600/smbus.c (working copy)
@@ -18,10 +18,11 @@
*/
#include smbus.h
+#include console/console.h
static inline void smbus_delay(void)
{
- outb(0x80, 0x80);
+ post_code(POST_SMBUS_DELAY);
}
No use of post_code here (inb or 0xeb instead)
Index: src/southbridge/amd/sb700/smbus.c
===
--- src/southbridge/amd/sb700/smbus.c (revision 6380)
+++ src/southbridge/amd/sb700/smbus.c (working copy)
@@ -21,10 +21,11 @@
#define _SB700_SMBUS_C_
#include smbus.h
+#include console/console.h
static inline void smbus_delay(void)
{
- outb(inb(0x80), 0x80);
+ post_code(POST_SMBUS_DELAY);
}
static int smbus_wait_until_ready(u32 smbus_io_base)
Same here.
Index: src/southbridge/amd/sb800/smbus.c
===
--- src/southbridge/amd/sb800/smbus.c (revision 6380)
+++ src/southbridge/amd/sb800/smbus.c (working copy)
@@ -21,10 +21,11 @@
#define _SB800_SMBUS_C_
#include smbus.h
+#include console/console.h
static inline void smbus_delay(void)
{
- outb(inb(0x80), 0x80);
+ post_code(POST_SMBUS_DELAY);
}
Same here.
Index: src/southbridge/amd/cimx_wrapper/sb800/smbus.c
===
--- src/southbridge/amd/cimx_wrapper/sb800/smbus.c(revision 6380)
+++ src/southbridge/amd/cimx_wrapper/sb800/smbus.c(working copy)
@@ -20,10 +20,11 @@
#include arch/io.h
#include smbus.h
+#include console/console.h
static inline void smbus_delay(void)
{
- outb(inb(0x80), 0x80);
+ post_code(POST_SMBUS_DELAY);
}
Same here.
Index: src/southbridge/amd/amd8111/amd8111_smbus.h
===
--- src/southbridge/amd/amd8111/amd8111_smbus.h (revision 6380)
+++ src/southbridge/amd/amd8111/amd8111_smbus.h (working copy)
@@ -12,7 +13,7 @@
static inline void smbus_delay(void)
{
- outb(0x80, 0x80);
+ post_code(POST_SMBUS_DELAY);
}
Same here.
--- src/southbridge/broadcom/bcm5785/smbus.h (revision 6380)
+++ src/southbridge/broadcom/bcm5785/smbus.h (working copy)
@@ -42,7 +43,7 @@
static inline void smbus_delay(void)
{
- outb(0x80, 0x80);
+ post_code(POST_SMBUS_DELAY);
}
Same here.
static int smbus_wait_until_ready(unsigned smbus_io_base)
Index: src/southbridge/nvidia/ck804/smbus.h
===
--- src/southbridge/nvidia/ck804/smbus.h (revision 6380)
+++ src/southbridge/nvidia/ck804/smbus.h (working copy)
@@ -19,6 +19,7 @@
*/
Re: [coreboot] [PATCH 2/5] libpayload: Some more standard types and defines
* Peter Stuge pe...@stuge.se [110225 21:45]: Patrick Georgi wrote: +++ b/payloads/libpayload/include/stdint.h @@ -27,4 +27,9 @@ * SUCH DAMAGE. */ +#ifndef __STDINT_H +#define __STDINT_H #include arch/types.h + +typedef unsigned long uintptr_t; +#endif What about 64 bit? Or libpayload simply doesn't support it? In that case Acked-by: Peter Stuge pe...@stuge.se unsigned long is 64bit on 64bit gccs -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/5] libpayload: Implement ffs()
* Peter Stuge pe...@stuge.se [110225 21:48]:
Patrick Georgi wrote:
+int ffs(int i);
Wording in my ffs(3) page suggests that int can be 64 bit. We don't
care?
So far the only compiler I know where this could happen is MSVC. Since
we have an endless amount of GNUisms in all of our code that basically
limits us to gcc/llvm/sun compiler/intel compiler/... it will never be a
problem for us.
We might want to consider a slightly bigger but non-looping and faster
implementation
int ffs(int i)
{
int count = 1;
if (i == 0)
return 0;
if (!(i 0x)) {
i = 16;
count += 16;
}
if (!(i 0xff)) {
i = 8;
count += 8;
}
if (!(i 0xf)) {
i = 4;
count += 4;
}
if (!(i 3)) {
i = 2;
count += 2;
}
if (!(i 1)) {
i = 1;
count += 1;
}
return count;
}
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] outb(* 0x80) to post_code()
* Patrick Georgi patr...@georgi-clan.de [110225 22:55]: Am 25.02.2011 22:45, schrieb Stefan Reinauer: Hm. If we touch it now, why not fix it so we don't have to care anymore? Some smbus drivers (like the ICH7 one) are using inb already, and it works fine. I didn't want to block this task because of that other one, it's great that Alexandru takes care of it. Of course, I'd love to see smbus* fixed (or even better, refactored and fixed) refactored... should we move the delay function to a common place? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] outb(* 0x80) to post_code()
* Alex G. mr.nuke...@gmail.com [110225 23:26]: Hi Stefan and Patrick. I Just saw your emails. inb(0x80) or post_code(POST_SMBUS_DELAY): make up your minds :) The second one seems wrong. It's not a post_code, but a delay that happens to print some garbage on a post card. Changing that into post_code() silently pretends that this is done on purpose. Not good, in my opinion. Can we put this in one file together with src/include/cpu/amd/geode_post_code.h Looks interesting. Looking into that. Using this will totally obsolete documentation/POSTCODES, which I used as the basis. If you prefer to use these codes, say green. src/include/cpu/x86/post_code.h No. This would ruin the behavior of post_code() in console.c, which also outputs to console if the option is selected. Why? Just add #ifdef ASSEMBLY around it. Then it won't be visible in console.c (or console.h for that matter) On 02/25/2011 11:59 PM, Stefan Reinauer wrote: refactored... should we move the delay function to a common place? I can move it. Just which file ? Also, wouldn't this make a single patch too hard to swallow? Yes. I think you should remove all changes to smbus* files from your patch and then we can look at the issue separately. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6378 - trunk/src/mainboard/tyan/s2735
* repository service s...@coreboot.org [110224 08:43]: Author: oxygene Date: Thu Feb 24 08:43:37 2011 New Revision: 6378 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6378 Log: Tyan/s2735 doesn't need to define its own hard_reset function anymore. The southbridge already provides hard_reset. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Patrick Georgi patrick.geo...@secunet.com Why was this exposed by the Makefile restructuring but never occurred before? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6380 - in trunk/src: cpu/amd/model_fxx northbridge/amd/amdk8
* repository service s...@coreboot.org [110224 15:35]:
Modified: trunk/src/cpu/amd/model_fxx/model_fxx_init.c
==
--- trunk/src/cpu/amd/model_fxx/model_fxx_init.c Thu Feb 24 14:54:10
2011(r6379)
+++ trunk/src/cpu/amd/model_fxx/model_fxx_init.c Thu Feb 24 15:35:42
2011(r6380)
@@ -264,7 +264,10 @@
/* See if we scrubbing should be enabled */
enable_scrubbing = 1;
- get_option(enable_scrubbing, hw_scrubber);
+ if( get_option(enable_scrubbing, hw_scrubber) 0 )
+ {
+ enable_scrubbing = CONFIG_HW_SCRUBBER;
+ }
small style note: if() wants the curly brackets on the same line, new
functions don't.
Also, does it make sense to initialize enable_scrubbing like this if
it's overwritten anyways?
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] RFC AMD powernow generation for pre fam 0fh
* Rudolf Marek r.ma...@assembler.cz [110224 21:04]: Hi all Attaching update patch. Not much changed, only comments added. It adds support for automatic PSS object generation for AMD pre fam Fh CPU. Those CPUs require a hardcoded table, which I managed to rewrite during one particularly boring flight. Too pity it is only for Opteron CPUs. Someone needs to finish the second PDF for All others Athlons and Semprons. Also it enables the FID/VID changes in SB. Jakllsch had some troubles with that too but on am2 CPU. Those bits are only documented in SB600. They arent in RRG RPR and BDG. Signed-off-by:Rudolf Marek r.ma...@asssembler.cz Acked-by: Stefan Reinauer stefan.reina...@coreboot.org Thanks, Rudolf Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
* Scott Duplichan sc...@notabs.org [110224 05:03]: The attached patch gets coreboot going on the ASRock E350M1 board. This is an AMD family 14h Fusion board I bought for US $120, including processor. The video option rom is from the supplied UEFI BIOS. The patch modifies the persimmon project and is for development use, not for commit. With this patch it can boot DOS from a SATA drive. It can also boot WinPE from a USB flash drive. I was unable to get Windows setup to run. The board has a socketed SPI flash BIOS chip and a serial port header. The SIO is Nuvoton NCT5572D. Using coreboot's existing Winbond w83627hf is a good enough match to at least get the serial port and keyboard going. Here are pictures of the board: http://notabs.org/pictures/ASRock-E350M1/ +#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) if CONFIG_SIO_PORT is defined in Kconfig (why?) we could as well use it in romstage.c. Is there a chance to remove it from Kconfig instead? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot for AMD Fusion family 14h: ASRock E350M1
Any chance to move the SSDTs to the northbridge/southbridge/cpu
directory instead of having them live under mainboard?
* Scott Duplichan sc...@notabs.org [110224 07:05]:
Index: src/mainboard/asrock/e350m1/acpi/ssdt2.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt2.asl(revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt2.asl(working copy)
@@ -17,7 +17,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-DefinitionBlock (SSDT2.aml, SSDT, 1, AMD-FAM10, AMDACPI, 100925440)
+DefinitionBlock (SSDT2.aml, SSDT, 1, AMD-FAM14, AMDACPI, 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/acpi/ssdt3.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt3.asl(revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt3.asl(working copy)
@@ -17,7 +17,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-DefinitionBlock (SSDT3.aml, SSDT, 1, AMD-FAM10, AMDACPI, 100925440)
+DefinitionBlock (SSDT3.aml, SSDT, 1, AMD-FAM14, AMDACPI, 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/acpi/ssdt4.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt4.asl(revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt4.asl(working copy)
@@ -17,7 +17,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-DefinitionBlock (SSDT4.aml, SSDT, 1, AMD-FAM10, AMDACPI, 100925440)
+DefinitionBlock (SSDT4.aml, SSDT, 1, AMD-FAM14, AMDACPI, 100925440)
{
Scope (_SB)
{
Index: src/mainboard/asrock/e350m1/acpi/ssdt5.asl
===
--- src/mainboard/asrock/e350m1/acpi/ssdt5.asl(revision 6375)
+++ src/mainboard/asrock/e350m1/acpi/ssdt5.asl(working copy)
@@ -18,7 +18,7 @@
*/
-DefinitionBlock (SSDT5.aml, SSDT, 1, AMD-FAM10, AMDACPI, 100925440)
+DefinitionBlock (SSDT5.aml, SSDT, 1, AMD-FAM14, AMDACPI, 100925440)
{
Scope (_SB)
{
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] 870 attempt
* Scott Duplichan sc...@notabs.org [110224 18:07]: -Original Message- From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On Behalf Of Marc Jones Sent: Thursday, February 24, 2011 10:45 AM To: Jonathan A. Kollasch Cc: coreboot@coreboot.org Subject: Re: [coreboot] 870 attempt On Thu, Feb 24, 2011 at 7:23 AM, Jonathan A. Kollasch jakll...@kollasch.net wrote: On Thu, Feb 24, 2011 at 02:14:07AM +, Jonathan A. Kollasch wrote: Hi, I've attempted to use the rs780 and sb800 code on a AM3 870 + SB850 board. Raminit seems to go okay, as does the first bits of ramstage. However, ramstage fails after the first two passes through rs780_enable(). It stalls in get_vid_did() reading PCI config space of device 2 (or 4). Also, the rs780 HT init code thinks the link should run at 200MHz, maybe that's related. Attached is the diff, and console output there from. (Mainboard directory is a svn cp of bimini_fam10.) rs780_htinit cpu_ht_freq=0. rs780_htinit: HT1 mode ]It looks it had problems getting the HT frequency from the CPU. Both ]sides have to agree on what is capable. You may need to look at the ]CPU HT code for a hint on why it reports what it does to the SB. ] ]Marc Also remember that the family 10h swap list problem still exists. There are some old patches and discussion that might be useful. Here is an example: http://www.mail-archive.com/coreboot@coreboot.org/msg27356.html Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/3] Move coreboot specific rules and setup to toplevel Makefile.inc
* Georgi, Patrick patrick.geo...@secunet.com [110222 15:35]: Am Donnerstag, den 17.02.2011, 20:05 +0100 schrieb Stefan Reinauer: I agree we want this, though. Can you please put Makefile.inc in src/? We currently have subdirs-y = ... util/cbfstool in there. That would be ++ugly with src/Makefile.inc. hm... as ugly as /Makefile and /Makefile.inc? What's needed other than a subdirs-y += ../util/cbfstool ? However we could move the src/* related things and the coreboot rules into a new file src/Makefile.inc, so toplevel Makefile.inc only contains the KERNELVERSION (I fixed that one, thanks for reporting it), and subdirs-y = src util/cbfstool util/romcc I'd prefer not to add more Makefiles than needed. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Add .text into romstage sections.
* Bao, Zheng zheng@amd.com [110223 03:31]: The ldscript_fallback_cbfs.lb is only for the romstage. It does nothing to change the building of ramstage. And it doesn't have area like .data, which can be read and wrote. From the attached build output, we can see that only crt0.romstage.o changes .rodata to rom.data, changes .text to .rom.text. Other romstage files like console.romstage.o only have .text., without .rom.text, .rom.data, or .data. I believe this is an odd survivor from romcc-only times. Is there a reason on non-romcc builds to move any code into .rom.* sections at all? If not, we should remove that behavior completely and just have it include .text and .rodata in the ld script. (which should be called romstage.ld and not ldscript_fallback_cbfs.lb) From the 2 romstage.map(s), we can see where the _erom should be. Compared to the patch to ldscript_fallback_cbfs.lb, we can also change other romstage's .text to .rom.text. But I don't think it is worth to do such a complicated job. Zheng Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] disabling microcode update
On 2/19/11 12:45 PM, xdrudis wrote:
On Fri, Feb 18, 2011 at 10:19:31AM -0500, Ward Vandewege wrote:
Hi Xavi,
On Wed, Feb 16, 2011 at 02:45:02PM +0100, Xavi Drudis Ferran wrote:
Should I send a patch making a Kconfig option to not upgrade microcode
for fam10? Is there any interest in that ?
What's the particular rationale behind this? When disabling microcode
updates, why don't you also disable the other erratas?
+ Select this to apply (propietary?) patches to the cpu
I don't think the word proprietary (nor the question mark) applies very
well here.
+ microcode provided by AMD to correct issues in the CPU after
+ production, and distributed with coreboot (not necessarily
+ the latest microcode version produced by AMD, but only
+ applied if newer than the version in your CPU).
+
+ Unselect to let FAM10 CPUs run with factory microcode. If
Here's some formatting problem. It's also unclear what you mean by
factory microcode imho.
+ you unselect this, no binary microcode patches will be
+ included in the image, so it will help you get an image
+ which you have the entire source code for and may simplify
+ license compliance (IANAL).
I don't see how this makes license compliance any easier. Also, please
refrain from using terms like IANAL. If we make claims they should be
either right to the best of our knowledge or we don't put them in the
source code, anyways.
BTW, some corporations had legal teams analyze the microcode license and
it was considered not problematic for inclusion in coreboot in the sense
of the GPL.
--- src/cpu/amd/model_10xxx/update_microcode.c 2011-02-19 21:56:44.0
+0100
+++ src/cpu/amd/model_10xxx/update_microcode.c 2011-02-19 22:09:17.0
+0100
@@ -29,6 +29,7 @@
#includecpu/amd/microcode.h
#endif
+#if CONFIG_UPDATE_CPU_MICROCODE
static const u8 microcode_updates[] __attribute__ ((aligned(16))) = {
Please change the patch to not include update_microcode.c in the
Makefile for the case that microcode selection is disabled.
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Question: Can I change DQS settings from a user program
On 2/18/11 2:48 PM, Fengwei Zhang wrote: Hi all, I have a K8 board. I tried to change the DQS settings from a user program, but I failed. I printed out the DQS settings before my pci_write_long() function. I also printed out the DQS settings after the pci writing. The results are same. My question is: can I change DQS settings from a user program? or I need to enable some registers before changing? I believe you have to do this during RAM init as it will potentially compromise the contents of your RAM. Thus it can not be done after an OS has started. What's the rationale here? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6373 - in trunk/src/superio: fintek/f71805f fintek/f71859 fintek/f71863fg fintek/f71872 fintek/f71889 intel/i3100 ite/it8712f ite/it8716f smsc/lpc47b272 smsc/lpc47b397 smsc/lp
On 2/19/11 6:51 AM, repository service wrote:
Modified: trunk/src/superio/smsc/lpc47n227/superio.c
==
--- trunk/src/superio/smsc/lpc47n227/superio.c Thu Feb 17 21:48:45 2011
(r6372)
+++ trunk/src/superio/smsc/lpc47n227/superio.c Sat Feb 19 15:51:31 2011
(r6373)
@@ -116,7 +116,7 @@
void lpc47n227_pnp_enable(device_t dev)
{
pnp_enter_conf_state(dev);
- lpc47n227_pnp_set_enable(dev, (dev-enabled) ? 1 : 0);
+ lpc47n227_pnp_set_enable(dev, !!dev-enabled);
pnp_exit_conf_state(dev);
}
How's this different? I like the ?: notion more than the :: notion.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Will coreboot work on my Shuttle X27?
* Jørn Odberg jorn.odb...@gmail.com [110217 15:49]: 1) This is a Shuttle X27 , dual Intel Atom CPU 330. This system is fairly similar to the Intel D945GCLF board that is already supported by coreboot. You will have to adapt the SuperIO settings in devicetree.cb and romstage.c to the ite/it8718f though. superiotool r3844 Found ITE IT8718F (id=0x8718, rev=0x5) at 0x2e Make sure you have a backup BIOS chip and a means of recovery as well as a serial null modem cable for the debug messages. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Code organization question Re: Next target: ASUS TUSI-M
* Keith Hui buu...@gmail.com [110217 05:52]:
Southbridge has...
bootblock.c for code required to make the whole ROM chip accessible
all ACPI stuff (will be a while before I can get to that)
There is some ACPI stuff in the northbridge, too. See Intel i945 and
sb i82801gx for an example.
one ramstage driver for each PCI device the bridge supports eg. IDE, USB,
LAN
romstage smbus access code for reading SPD
you only need a driver if there is a __pci_driver struct in the code,
and if you actually have to do init on that device.
For this single chip chipset, should I put everything into
northbridge, or keep only RAM init and bus scan stuff in
src/northbridge, and put IDE/USB/LAN/SMBus/LPC/ISA etc. in
src/southrbidge? In this scheme where would VGA fit?
I think you can decide which way to go. The Intel SCH chipset for
example exists in both northbridge/ and southbridge despite it being one
chip. On the other hand the VIA CX700 lives completely in northbridge/
VGA probably lives in the northbridge part of the chip.
SIS630 and my board has onboard VGA that shares memory with main. I
have the VGA BIOS extracted. Do I still need to write code to
initialize it? If so, where in the coreboot tree?
I would start without writing extra code and then go from there. You
might need VGA int15 5fXX hooks, or additional init, but you can figure
that out when it becomes a problem.
What is the relationship between devicetree.cb, sconfig, parameters
available to be included in cmos.layout, northbridge and southbridge
drivers?
sconfig is a C program that parses devicetree.cb and creates the static
portion of the coreboot device tree. The parameters you specify in
devicetree.cb end up in static.c which is produced by sconfig.
cmos.layout is completely distinct from the device tree stuff.
Say I need to have add a setting in cmos.layout to
enable/disable the built in LAN, in how many places do I have to
declare this setting?
Look at src/mainboard/kontron/986lcd-m/{cmos.layout,romstage.c} for an
example of how I did this. There might be better ways to do it, but
basically you want to make sure you disable your device early on so it
does not interact with the resource allocator. .enable function in
stage2 is good enough, too.
My factory bios writes some known values into
various superio LDNs during early initialization. Can I declare them
in devicetree.cb or I have to write them in C into some early init
code?
That's a matter of taste. I think if it's not going to be changed
putting it in code is fine. Sometimes it needs to go in romstage.c, for
example the serial port setup in romstage.c. Beyond that most things
should be fine to go to devicetree.cb
Also, should I declare devices that can be enabled/disabled
either in software or by jumper?
In declaring devices in devicetree.cb, does device pci_domain 1...
means PCI bus 1, like the AGP slot on a 440BX?
No, on PC systems you almost always only have one PCI domain. AGP is
just another bus. In general you should not need to add that explicitly
to your devicetree.cb as coreboot can do the enumeration by itself.
Roughly you only need to add devices to the device tree if
- they can not be automatically detected
- they need some specific configuration, like whether to run the IDE
controller in AHCI or IDE mode.
- they require some knowledge of the layout, like which HT link is used
on a K8 system to connect the southbridge.
- they shall be explicitly disabled even though they're on per default
(and you don't want to do that in romstage)
The IDE, USB and LAN devices on SIS chipsets so often share the same
PCI IDs and probably the same initialization sequence. There is
currently only one other SIS southbridge in the tree (the 966) but its
IDE has the same 1039:5513 ID as that on the 630. Any way I can share
this code, or I still have to duplicate it?
It might be worth duplicating the code, since the components might still
need specific errata work arounds despite their same PCI ID. I've seen
this happen more than once.
Any chance I can factor it out like Sil3114?
I suggest not to do that for chipset components.
In the ramstage driver model, what is the relationships between chip.h,
chip.h contains the config structures for the parameters used in
devicetree.cb.
Looking at my factory BIOS disassembly and what coreboot v1 had done,
I am going to have to write some known values into known registers,
both in the northbridge device, southbridge device, and superio.
Where usually is this done?
Since this is basically what firmware does all the time, this totally
depends on the values and the devices and the purpose of the writes.
If it's for configuring the RAM controller, it should probably happen in
raminit.c. for some generic chipset setup I used early_init.c in i945
but if possible it is a good manner to put the code changing a device's
config space to the ramstage driver of that device.
bootblock_northbridge_init() for
Re: [coreboot] [PATCH 2/3] Handle compiler options for source classes more generically
* Patrick Georgi patrick.geo...@secunet.com [110217 09:55]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com index 0754b15..a233c13 100644 --- a/Makefile +++ b/Makefile -$(eval $(call create_cc_template,driver,S,-DASSEMBLY)) -$(eval $(call create_cc_template,smm,c)) -$(eval $(call create_cc_template,smm,S)) Interesting. I think smm,S should have had -DASSEMBLY, too. Well, even better would be to use __ASSEMBLY__ or __ASSEMBLER__ in the code as defined by gcc for this purpose and not treat them differently at all. Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 1/3] Make Makefile.inc parser loop more generic
* Patrick Georgi patrick.geo...@secunet.com [110217 08:44]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/3] Move coreboot specific rules and setup to toplevel Makefile.inc
* Georgi, Patrick patrick.geo...@secunet.com [110217 12:32]: The result of this patch series would be that the coreboot toplevel Makefile contains only the build system logic and is usable for other trees, such as libpayload (which I'd like to change so it builds libc, libcurses, and libpci instead of/in addition to libpayload) Thanks for the explanation. I felt a slight attack of panic when seeing that stuff change so many lines of sufficiently advanced technology ;-) I agree we want this, though. Can you please put Makefile.inc in src/? Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/3] Move coreboot specific rules and setup to toplevel Makefile.inc
* Patrick Georgi patrick.geo...@secunet.com [110217 10:24]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com --- Makefile | 223 ++--- Makefile.inc | 227 ++ 2 files changed, 248 insertions(+), 202 deletions(-) create mode 100644 Makefile.inc diff --git a/Makefile b/Makefile index a233c13..596d3f7 100644 --- a/Makefile +++ b/Makefile @@ -4,6 +4,7 @@ ## Copyright (C) 2008 Advanced Micro Devices, Inc. ## Copyright (C) 2008 Uwe Hermann u...@hermann-uwe.de ## Copyright (C) 2009-2010 coresystems GmbH +## Copyright (C) 2011 secunet Security Networks AG ## ## 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 @@ -40,7 +41,6 @@ export objutil ?= $(obj)/util export objk := $(objutil)/kconfig -export KERNELVERSION := 4.0 This is not such a great idea. make menuconfig will then print .config - coreboot v(null) Configuration I don't think this variable is used outside of Kconfig (hence the stupid name) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [superiotool] patch for smsc mec1308
Acked-by: Stefan Reinauer reina...@google.com On Wed, Feb 16, 2011 at 4:11 PM, David Hendricks dhend...@google.com wrote: Hi, Attached is a patch to add support for the SMSC MEC1308 embedded controller. Unfortunately, the device ID it conflicts with another SMSC Super IO chip, the FDC37M81x. However, since superiotool does not really support the FDC37M81x in any really useful capacity, I think it's fair to just disable it for now. Signed-off-by: David Hendricks dhend...@google.com -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- Stefan Reinauer Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [FILO] r140 - trunk/filo/fs
* Nathan Williams nat...@traverse.com.au [110214 04:20]: On Sat, 2011-02-12 at 03:01 +0100, repository service wrote: Author: stepan Date: Sat Feb 12 03:01:44 2011 New Revision: 140 URL: http://tracker.coreboot.org/trac/filo/changeset/140 Log: Allow FILO to boot off EXT4 partitions. Using adapted http://grub4ext4.googlecode.com/svn/trunk/ext4-support Signed-off-by: Stefan Reinauer stefan.reina...@coreboot.org Acked-by: Stefan Reinauer stefan.reina...@coreboot.org Modified: trunk/filo/fs/fsys_ext2fs.c This doesn't compile with CONFIG_DEBUG_FSYS_EXT2FS=y Regards, Nathan Fixes welcome! Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 1 of 8.
Hi! Thank you very much, Frank, Gary, Kenneth, Kerry, Kevin, Michael, Mike and Zheng! And of course all the others that were involved! This is great moment for coreboot, and we are all incredibly excited about this! Those among the coreboot community that have done hardware ports before can estimate how much excellent work has been put into this port, both on the technical as well as on the legal side. Awesome job! Apart from the actual port, we are also seeing infrastructure coming in place that allows coreboot to support AMD processors and chipsets much sooner and even better than in previous releases. May AMD systems boot fast and numerously out there! Thanks, Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 1 of 8.
* Vibrans, Frank frank.vibr...@amd.com [110213 22:43]: Add AMD Agesa and AMD CIMx SB800 code. Patch 1 of 8. This code currently generates many warnings that are functionally benign. These are being addressed, but the wheels of bureaucracy turn slowly. This drop supports AMD cpu families 10h and 14h. Only Family 14h is used as an example in this set of patches. Other cpu families are supported by the infrastructure, but their specific support is not included herein. This patch is functionally independent of the other patches in this set. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 2 of 8
* Vibrans, Frank frank.vibr...@amd.com [110213 22:47]: Add AMD Agesa northbridge wrapper code. Patch 2 of 8. This code provides cpu northbridge initialization for Family 14h cpus. It is dependent on the AMD Agesa code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 3 of 8.
* Vibrans, Frank frank.vibr...@amd.com [110213 22:49]: Add AMD CIMx SB800 wrapper code. Patch 3 of 8. This code provides southbridge initialization for SB800 south bridges. It is dependent on the AMD CIMx/SB800 code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 4 of 8.
* Vibrans, Frank frank.vibr...@amd.com [110213 22:50]: Add AMD cpu wrapper code. Patch 4 of 8. This code provides cpu early initialization for Family 14h cpus. It is dependent on the AMD Agesa code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Add AMD cpu wrapper code. Patch 4 of 8. This code provides cpu early initialization for Family 14h cpus. It is dependent on the AMD Agesa code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] (no subject)
* Vibrans, Frank frank.vibr...@amd.com [110213 22:52]: Add support for AMD Agesa wrapper code. Patch 5 of 8. This code fixes a number of build issues related to the AMD Agesa code. The particular issues are global variables existing in romstage and the use of GCC intrinsics in the build. The former issue will be addressed shortly, and the latter issue requires community assistance. This code is dependent on the AMD Family 14h mainboard code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 6 of 8.
* Vibrans, Frank frank.vibr...@amd.com [110213 22:53]: Add Fintek f81865f superio code. Patch 6 of 8. This code provides support for the superio chip on the IBASE Technology DB-FT1 (AMD code name Persimmon) platform. It is independent of the AMD code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 7 of 8.
* Vibrans, Frank frank.vibr...@amd.com [110213 22:55]: Add SMSC KBC 1100 superio code. Patch 7 of 8. This code provides support for the superio chip on the AMD Inagua platform (not commercially available). It is independent of the AMD code. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 8 of 8.
* Vibrans, Frank frank.vibr...@amd.com [110213 22:55]: Add IBASE DB-FT1 and AMD Inagua motherboards. Patch 8 of 8. This code provides support for IBASE Technology DB-FT1 (AMD code name Persimmon) and AMD Inagua platforms. It is dependent on all other patches in this set. Signed-off-by Frank Vibrans frank.vibr...@amd.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] superiotool: generation from C code to XML
* Антон Кочков anton.koch...@gmail.com [110214 22:02]: superiotool: add support for producing xml files from C code Signed-off-by: Anton Kochkov anton.koch...@gmail.com Is it possible to make superiotool read those instead of the C structures as its database? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 2/4] libpayload: Less noisy lpgcc
On 11.02.2011, at 01:38, Patrick Georgi patrick.geo...@secunet.com wrote: lpgcc was too noisy in some cases Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org --- payloads/libpayload/bin/lpgcc |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/payloads/libpayload/bin/lpgcc b/payloads/libpayload/bin/lpgcc index 826e498..57015d5 100755 --- a/payloads/libpayload/bin/lpgcc +++ b/payloads/libpayload/bin/lpgcc @@ -30,12 +30,14 @@ # let's not recurse. # This is a hack, I know, but it makes sure that really simple user errors # don't fork-bomb your machine. -echo CC = $CC +# echo CC = $CC +if [ -n $CC ]; then b=`basename $CC` if [ $b = lpgcc ]; then CC= fi +fi -- 1.7.1 -- 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 1/4] libpayload: Some more POSIX compatibility
On 11.02.2011, at 01:36, Patrick Georgi patrick.geo...@secunet.com wrote:
- Add assert.h
- Add arpa/inet.h
- Add assert-macro
Signed-off-by: Patrick Georgi patrick.geo...@secunet.com
Acked-by: Stefan Reinauer stefan.reina...@coreboot.org
---
payloads/libpayload/include/arpa/inet.h | 36
payloads/libpayload/include/assert.h| 39 +++
2 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 payloads/libpayload/include/arpa/inet.h
create mode 100644 payloads/libpayload/include/assert.h
diff --git a/payloads/libpayload/include/arpa/inet.h
b/payloads/libpayload/include/arpa/inet.h
new file mode 100644
index 000..4fc8a89
--- /dev/null
+++ b/payloads/libpayload/include/arpa/inet.h
@@ -0,0 +1,36 @@
+/*
+ * This file is part of the libpayload project.
+ *
+ * Copyright (C) 2011 secunet Security Networks AG
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef _ARPA_INET_H
+#define _ARPA_INET_H
+
+// arch/endian.h already provides ?to?[lwb]
+#include arch/endian.h
+
+#endif
diff --git a/payloads/libpayload/include/assert.h
b/payloads/libpayload/include/assert.h
new file mode 100644
index 000..fda4bc0
--- /dev/null
+++ b/payloads/libpayload/include/assert.h
@@ -0,0 +1,39 @@
+/*
+ * This file is part of the libpayload project.
+ *
+ * Copyright (C) 2011 secunet Security Networks AG
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include stdlib.h
+
+// assert's existence depends on NDEBUG state on _last_ inclusion of
assert.h,
+// so don't guard this against double-includes.
+#ifdef NDEBUG
+// Heisenbugs appear if statement has side-effects. This could be worked
around but does the standard allow for that?
+#define assert(statement)
+#else
+#define assert(statement) if ((statement) == 0) { printf(assertion failed
in file %s, function %s(), line %s\n, __FILE__, __FUNCTION__, __LINE__);
abort(); }
+#endif
--
1.7.1
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/4] libpayload: Stub out FILE*, stdout/stdin/stderr and implement fprintf on these
On 11.02.2011, at 01:57, Patrick Georgi patrick.geo...@secunet.com wrote:
- Add FILE*
- Add stdout, stdin, stderr stubs
- Add fprintf that redirects to printf for stdout and stderr and fails
otherwise
Signed-off-by: Patrick Georgi patrick.geo...@secunet.com
Acked-by: Stefan Reinauer stefan.reina...@coreboot.org
---
payloads/libpayload/include/stdio.h | 11 ++-
payloads/libpayload/libc/printf.c | 14 ++
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/payloads/libpayload/include/stdio.h
b/payloads/libpayload/include/stdio.h
index 73af2d1..fb40a0d 100644
--- a/payloads/libpayload/include/stdio.h
+++ b/payloads/libpayload/include/stdio.h
@@ -32,6 +32,15 @@
#include stddef.h
+struct _FILE {
+} _stdout, _stdin, _stderr;
+
+typedef struct _FILE FILE;
+
+FILE *stdout = _stdout;
+FILE *stdin = _stdin;
+FILE *stderr = _stderr;
+
/**
* @defgroup printf Print functions
* @{
@@ -39,6 +48,7 @@
int snprintf(char *str, size_t size, const char *fmt, ...);
int sprintf(char *str, const char *fmt, ...);
int printf(const char *fmt, ...);
+int fprintf(FILE *file, const char *fmt, ...);
/** @} */
void perror(const char *s);
@@ -47,5 +57,4 @@ void perror(const char *s);
#define SEEK_CUR 1 /** The seek offset is against the current position. */
#define SEEK_END 2 /** The seek offset is against the end of the file. */
-
#endif
diff --git a/payloads/libpayload/libc/printf.c
b/payloads/libpayload/libc/printf.c
index 04d3931..a1ebb14 100644
--- a/payloads/libpayload/libc/printf.c
+++ b/payloads/libpayload/libc/printf.c
@@ -723,6 +723,20 @@ int sprintf(char *str, const char *fmt, ...)
return ret;
}
+int fprintf(FILE *file, const char *fmt, ...)
+{
+int ret;
+if ((file == stdout) || (file == stderr)) {
+va_list args;
+va_start(args, fmt);
+ret = vprintf(fmt, args);
+va_end(args);
+
+return ret;
+}
+return -1;
+}
+
struct vsnprintf_data {
size_t size;/* Total space for string */
size_t len;/* Count of currently used characters */
--
1.7.1
--
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 4/4] libpayload: Use fprintf(stderr, ...) in library
On 11.02.2011, at 02:00, Patrick Georgi patrick.geo...@secunet.com wrote:
If we have it, why not use it?
Signed-off-by: Patrick Georgi patrick.geo...@secunet.com
Acked-by: Stefan Reinauer stefan.reina...@coreboot.org
---
payloads/libpayload/include/assert.h |3 ++-
payloads/libpayload/libc/lib.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/payloads/libpayload/include/assert.h
b/payloads/libpayload/include/assert.h
index fda4bc0..9968504 100644
--- a/payloads/libpayload/include/assert.h
+++ b/payloads/libpayload/include/assert.h
@@ -28,6 +28,7 @@
*/
#include stdlib.h
+#include stdio.h
// assert's existence depends on NDEBUG state on _last_ inclusion of assert.h,
// so don't guard this against double-includes.
@@ -35,5 +36,5 @@
// Heisenbugs appear if statement has side-effects. This could be worked
around but does the standard allow for that?
#define assert(statement)
#else
-#define assert(statement) if ((statement) == 0) { printf(assertion failed
in file %s, function %s(), line %s\n, __FILE__, __FUNCTION__, __LINE__);
abort(); }
+#define assert(statement) if ((statement) == 0) { fprintf(stderr, assertion
failed in file %s, function %s(), line %s\n, __FILE__, __FUNCTION__,
__LINE__); abort(); }
#endif
diff --git a/payloads/libpayload/libc/lib.c b/payloads/libpayload/libc/lib.c
index baccc07..c8539cb 100644
--- a/payloads/libpayload/libc/lib.c
+++ b/payloads/libpayload/libc/lib.c
@@ -109,7 +109,7 @@ u8 hex2bin(u8 h)
*/
void fatal(const char *msg)
{
-printf(%s,msg);
+fprintf(stderr, %s,msg);
halt();
}
--
1.7.1
--
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] what was 'set' in struct io_info for?
* Mark Marshall mark.marsh...@csr.com [110210 11:52]: I found the same thing as you a while ago. The io_info structure in pnp.h is never referenced by the code, and it's purpose is never really defined anywhere. If you change the name to something else (just in the header file) the code still all compiles, so I'd say remove it. I also asked about it on the news group, but got no reply. Oh, we have a news group? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] how Coreboot keeps the right offsets of the sections
* Peter Stuge pe...@stuge.se [110209 20:44]:
I checked the content of build/coreboot.rom and the last byte was
0x0a!! Which is written probably on the top of our EEPROM. Right?
but src/arch/i386/init/ldscript.ld specifies the last byte as 0x00!!
SECTIONS {
_ROMTOP = 0xfff0;
. = _ROMTOP;
.resetvector . : {
*(.reset)
. = 15 ;
BYTE(0x00);
}
}
Please help me with this puzzle. Thank you.
What is the concrete problem? You should not rule out that there are
binutils bugs. Just be happy that the reset vector has the right
opcodes.
cbfstool updates those memory regions.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] nvramtool hardware access on NetBSD
* Georgi, Patrick patrick.geo...@secunet.com [110208 11:26]: More general question (shouldn't stop anyone from committing this patch): Should we move hardware access code to directio and use its API on all platforms (not just Darwin, and - in theory - win32)? Though in that case, we might want to import directio to the coreboot tree. +1 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reliably build any Kconfig-based SeaBIOS revision
* Stefan Reinauer stefan.reina...@coreboot.org [110203 22:33]: * Peter Stuge pe...@stuge.se [110129 21:26]: See patch. The new TAG-stable points to the very latest commit in seabios.git, which may not be quite right, but both stable and master must be using Kconfig. //Peter slightly reworked to get rid of the perl calls (and to work with the latest HEAD version with options that are hidden during defconfig so a perl call would not replace them. Reliably build arbitrary Kconfig-based revisions of SeaBIOS The reliability is accomplished by checking out the user's desired SeaBIOS tag into a branch named 'coreboot' in the local SeaBIOS git repository. Thanks to the use of a branch TAG-$(CONFIG_SEABIOS_..) can refer to any commitish at all in the SeaBIOS git repo. Configuration is done by make defconfig followed by enabling of several coreboot-specific Kconfig options for SeaBIOS using perl. Signed-off-by: Peter Stuge pe...@stuge.se Acked-by: Stefan Reinauer stefan.reina...@coreboot.org Unless there's a reason not to, please commit the revised version (plus the one line change to src/arch/x86/Makefile.inc which I forgot to diff) Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Reliably build any Kconfig-based SeaBIOS revision
* Peter Stuge pe...@stuge.se [110129 21:26]: See patch. The new TAG-stable points to the very latest commit in seabios.git, which may not be quite right, but both stable and master must be using Kconfig. //Peter slightly reworked to get rid of the perl calls (and to work with the latest HEAD version with options that are hidden during defconfig so a perl call would not replace them. Reliably build arbitrary Kconfig-based revisions of SeaBIOS The reliability is accomplished by checking out the user's desired SeaBIOS tag into a branch named 'coreboot' in the local SeaBIOS git repository. Thanks to the use of a branch TAG-$(CONFIG_SEABIOS_..) can refer to any commitish at all in the SeaBIOS git repo. Configuration is done by make defconfig followed by enabling of several coreboot-specific Kconfig options for SeaBIOS using perl. Signed-off-by: Peter Stuge pe...@stuge.se Acked-by: Stefan Reinauer stefan.reina...@coreboot.org Index: payloads/external/SeaBIOS/Makefile.inc === --- payloads/external/SeaBIOS/Makefile.inc (revision 6326) +++ payloads/external/SeaBIOS/Makefile.inc (working copy) @@ -1,31 +1,37 @@ TAG-$(CONFIG_SEABIOS_MASTER)=origin/master -TAG-$(CONFIG_SEABIOS_STABLE)=rel-0.6.1.3 +TAG-$(CONFIG_SEABIOS_STABLE)=1efb10b9ea30c45a8c9c6230234fefa10d2886ed +unexport KCONFIG_AUTOCONFIG + all: seabios -seabios: patch - cd seabios; $(MAKE) - -patch: checkout - test -r seabios/.patched || \ - perl -pi -e s,#define CONFIG_COREBOOT 0,#define CONFIG_COREBOOT 1,; \ - -e s,#define CONFIG_DEBUG_SERIAL 0,#define CONFIG_DEBUG_SERIAL 1,; \ - -e s,#define CONFIG_VGAHOOKS 0,#define CONFIG_VGAHOOKS 1,; \ - seabios/src/config.h - touch seabios/.patched - checkout: - echo Checking out SeaBIOS $(TAG-y) + echo GITSeaBIOS $(TAG-y) test -d seabios ( cd seabios; git fetch ) || \ - git clone git://git.linuxtogo.org/home/kevin/seabios.git seabios - cd seabios; git checkout -m $(TAG-y) + git clone git://git.linuxtogo.org/home/kevin/seabios.git + cd seabios; git checkout master; git branch -D coreboot 2/dev/null; git checkout -b coreboot $(TAG-y) +config: checkout + echo CONFIG SeaBIOS $(TAG-y) + $(MAKE) -C seabios defconfig + echo CONFIG_COREBOOT=y seabios/.config + echo CONFIG_DEBUG_SERIAL=y seabios/.config + echo CONFIG_COREBOOT_FLASH=y seabios/.config + echo CONFIG_LZMA=y seabios/.config + echo CONFIG_FLASH_FLOPPY=y seabios/.config + echo CONFIG_VGAHOOKS=y seabios/.config + #echo # CONFIG_SMBIOS is not set seabios/.config + +seabios: config + echo MAKE SeaBIOS $(TAG-y) + $(MAKE) -C seabios + clean: - test -d seabios (cd seabios; $(MAKE) clean) || exit 0 + test -d seabios $(MAKE) -C seabios clean || exit 0 distclean: rm -rf seabios -.PHONY: seabios +.PHONY: checkout config seabios clean distclean -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Add license headers for AMD family Fh
* Alex G. mr.nuke...@gmail.com [110202 20:23]: Add GPL license headers to all files in src/cpu/amd/model_fxx (except microcode). Signed-off-by Alexandru Gagniuc mr.nuke...@gmail.com Acked-by Alexandru Gagniuc mr.nuke...@gmail.com Trivial Not trivial at all, but legally kind of troublesome. Got to NACK this, sorry. +# Copyright (C) The coreboot project We can not accept generic copyright to the coreboot project, as it is not a legal entity. +# 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. coreboot is GPLv2, not GPLv2+ Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Very large, active development team
Thanks to Patrick Georgi for finding this: --- http://www.ohloh.net/p/coreboot/factoids/4229016 Very large, active development team Over the past twelve months, 25 developers contributed new code to coreboot. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. For this measurement, Ohloh considered only recent changes to the code. Over the entire history of the project, 56 developers have contributed. --- Thanks, development team! You have been doing an outstanding job over the last 11 years! Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] [sort of] multiplex console output from each core
* xdrudis xdru...@tinet.cat [110130 20:59]: Yes, it'd be mostly unneeded, but anyway the patch I sent does not disable it in ramstage. So it still causes sprintf to consume the double of bytes maybe beyond its buffers (and produce unreadable messages). The idea can work, the perl script may be usable, but the patches to C should be redone from scratch. Can't you just hack up the muxing in console_tx_byte instead? That should solvle the problem and make the patch a tad less intrusive. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Freeze SeaBIOS master tag
On 29.01.2011, at 06:34, Kevin O'Connor ke...@koconnor.net wrote: SeaBIOS is moving to Kconfig. This will make it easier to configure coreboot and seabios going forward. However, it will also break the coreboot build in the short term. This patch, freezes the master branch of coreboot's seabios checkout so users don't see build failures. Signed-off-by: Kevin O'Connor ke...@koconnor.net -Kevin Hi Kevin Much appreciated! However I don't think this is needed at this point. Per default coreboot uses the stable checkout and well, the bleeding edge sometime bleeds :) Stefan --- a/payloads/external/SeaBIOS/Makefile.inc +++ b/payloads/external/SeaBIOS/Makefile.inc @@ -1,6 +1,6 @@ -TAG-$(CONFIG_SEABIOS_MASTER)=origin/master +TAG-$(CONFIG_SEABIOS_MASTER)=4d0c592b138f394f96a99b6311a8ef48c24fb1c6 TAG-$(CONFIG_SEABIOS_STABLE)=rel-0.6.1.3 all: seabios -- 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] QA contribution
* Danila Sukharev mam...@gmail.com [110130 06:00]: Hi there! I'm a QA guy interested in coreboot project. I have two mobos supported by coreboot; also I have some QA and dev skills (but mostly QA). I also have the ability to check the coreboot on some other mobos - I have them in my hands from time to time. Awesome! Welcome! How is it possible for me to start contributing the project in such a role? Is there some guide, some list of open tasks, or list of fixes pending review?.. You might be interested in checking out our testing efforts: http://www.coreboot.org/Distributed_and_Automated_Testsystem Unfortunately no machines actually run tests these days. Would love to hear your ideas on this. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] get USB debug console working in ROM stage
* Georgi, Patrick patrick.geo...@secunet.com [110128 08:22]:
Am Donnerstag, den 27.01.2011, 18:16 -0800 schrieb Stefan Reinauer:
+#if defined(__ROMCC__)
+#define printk(BIOS_DEBUG, fmt, arg...) do {} while(0)
+#else
romcc doesn't support variadic macros. This only works because no
chipset that uses romcc supports USB debug.
Given the age of romcc-chipsets I think it's safe to assume that they
support serial console, so how about we make usbdebug a CAR-only feature
(ie. drop this #define)?
You are right. The rest of the code has some CAR assumptions, too, and
the code complexity would probably make romcc explode anyways. So for
now, I dropped the ROMCC specific stuff, including the changes I made to
src/include/console/console.h
Otherwise the patch is
Acked-by: Patrick Georgi patrick.geo...@secunet.com
Thanks. r6315
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Sanitize cbfs-files-y
* Georgi, Patrick patrick.geo...@secunet.com [110128 15:32]: Hi, attached patch inverses two arguments of cbfs-files-y and adapts its users (one of which already used the new order). This is in reponse to feedback that the original setup was too complicated. New cbfs-files-y: cbfs-files-y contains the names of files as they appear in CBFS. The arguments describe the on-filesystem name, the type and (optionally) the position. Example: cbfs-files-y += foo foo-file := bar foo-type := splashscreen foo-position := 0x8000 This configures a CBFS file called foo that is marked splashscreen, located at 0x8000 in flash and contains the data of the file bar in the filesystem (either in the current directory, ie. where the corresponding Makefile.inc resides, or if that doesn't exist, relative to the toplevel directory). Signed-off-by: Patrick Georgi patrick.geo...@secunet.com nice! Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Sanitize cbfs-files-y
* Georgi, Patrick patrick.geo...@secunet.com [110128 15:32]: Hi, attached patch inverses two arguments of cbfs-files-y and adapts its users (one of which already used the new order). This is in reponse to feedback that the original setup was too complicated. New cbfs-files-y: cbfs-files-y contains the names of files as they appear in CBFS. The arguments describe the on-filesystem name, the type and (optionally) the position. Example: cbfs-files-y += foo foo-file := bar foo-type := splashscreen foo-position := 0x8000 Two questions: Stuff like cmos.layout could arguably go into fallback/ or normal/. What's the right way to solve this with cbfs-files-y? If it stays in /, what happens if an image is updated with a newer version of cmos.layout (say, no old options move/remove so it's safe in that regard). Will the file be ignored? Or Overwritten? Do we produce a proper warning for that? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix infinite loop in pnp_get_ioresource()
Hi Alexandru,
thanks for finding this issue. I think I ran into this before. We
should not silently continue in this case, and not create a resource
either. The problem is most likely caused by a faulty devicetree.cb or
superio driver. Hence, I suggest to print an error instead. See patch.
Can you test, please? It should tell you which device / index is
causing the problem.
Stefan
On Fri, Jan 28, 2011 at 2:14 AM, Alex G. mr.nuke...@gmail.com wrote:
Fix an infinite loop in pnp_get_ioresource(), which freezes coreboot if
a rare condition arises.
Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com
---
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
Stefan Reinauer
Google Inc.
Fix an infinite loop in pnp_get_ioresource(), which freezes coreboot if
a rare condition arises.
Based on findings by Alexandru Gagniuc mr.nuke...@gmail.com
Signed-off-by: Stefan Reinauer reina...@google.com
diff --git a/src/devices/pnp_device.c b/src/devices/pnp_device.c
index b2bca03..4a6d266 100644
--- a/src/devices/pnp_device.c
+++ b/src/devices/pnp_device.c
@@ -170,6 +170,12 @@ static void pnp_get_ioresource(device_t dev, u8 index, struct io_info *info)
struct resource *resource;
unsigned moving, gran, step;
+ if (!info-mask) {
+ printk(BIOS_ERR, ERROR: device %s index %d has no mask.\n,
+dev_path(dev), index);
+ return;
+ }
+
resource = new_resource(dev, index);
/* Initilize the resource. */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Add PCI ID's for VIA K8T800 and K8M800 chipsets
* Alex G. mr.nuke...@gmail.com [110128 13:05]: Added PCI ID's for the functions of the VIA K8T800(Pro) and K8M800 chipsets. Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com --- Although this is very trivial, I don't think I'm in the position to ack. Alex Hm.. Is there a chance to name them other than _1 ... _7? It's not really more readable than just using the numbers directly.. Index: pci_ids.h === --- pci_ids.h (revision 6255) +++ pci_ids.h (working copy) @@ -1220,6 +1220,24 @@ #define PCI_DEVICE_ID_VIA_8505_1 0x8605 #define PCI_DEVICE_ID_VIA_8633_1 0xB091 #define PCI_DEVICE_ID_VIA_8367_1 0xB099 +#define PCI_DEVICE_ID_VIA_K8T800_0 0x0282 +#define PCI_DEVICE_ID_VIA_K8T800_1 0x1282 +#define PCI_DEVICE_ID_VIA_K8T800_2 0x2282 +#define PCI_DEVICE_ID_VIA_K8T800_3 0x3282 +#define PCI_DEVICE_ID_VIA_K8T800_4 0x4282 +#define PCI_DEVICE_ID_VIA_K8T800_5 0x5282 +#define PCI_DEVICE_ID_VIA_K8T800_6 0x6282 +#define PCI_DEVICE_ID_VIA_K8T800_7 0x7282 +#define PCI_DEVICE_ID_VIA_K8M800_0 0x0204 +#define PCI_DEVICE_ID_VIA_K8M800_1 0x1204 +#define PCI_DEVICE_ID_VIA_K8M800_2 0x2204 +#define PCI_DEVICE_ID_VIA_K8M800_3 0x3204 +#define PCI_DEVICE_ID_VIA_K8M800_4 0x4204 +#define PCI_DEVICE_ID_VIA_K8M800_5 0x5204 +#define PCI_DEVICE_ID_VIA_K8M800_6 0x6204 +#define PCI_DEVICE_ID_VIA_K8M800_7 0x7204 +#define PCI_DEVICE_ID_VIA_K8T800_AGP 0x3188 +#define PCI_DEVICE_ID_VIA_K8T800_BR 0xb188 #define PCI_DEVICE_ID_VIA_K8T890CE_0 0x0238 #define PCI_DEVICE_ID_VIA_K8T890CE_1 0x1238 #define PCI_DEVICE_ID_VIA_K8T890CE_2 0x2238 -- 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 1/6] No need to add varargs magic to a simple regex wrapper.
* Patrick Georgi patrick.geo...@secunet.com [110127 15:15]: Einfaches Textdokument attachment (20110127-1-less-magic-for-regex.diff) Not a good changelog suggestion ;-) Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 2/6] Eliminate a couple of 3-line functions that barely wrap *printf calls
* Patrick Georgi patrick.geo...@secunet.com [110127 15:07]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 4/6] Move the parser for cmos.layout text files to accessors. No API change yet
* Patrick Georgi patrick.geo...@secunet.com [110127 15:07]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 5/6] Move CMOS handling into separate files in accessors. No API change yet
* Patrick Georgi patrick.geo...@secunet.com [110127 15:07]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 6/6] Separate CMOS layout from lbtable handling.
* Patrick Georgi patrick.geo...@secunet.com [110127 15:07]:
Signed-off-by: Patrick Georgi patrick.geo...@secunet.com
Mixed use of uint32_t and u32. Otherwise
Acked-by: Stefan Reinauer stefan.reina...@coreboot.org
Index: nvramtool/accessors/layout-bin.c
===
--- /dev/null
+++ nvramtool/accessors/layout-bin.c
+void get_layout_from_cbfs_file(void)
+{
+ u32 len;
+ cmos_table = cbfs_find_file(cmos_layout.bin,
CBFS_COMPONENT_CMOS_LAYOUT, len);
+ process_layout();
+}
...
+static const struct lb_record *first_cmos_rec(uint32_t tag)
+{
+ const char *p;
+ uint32_t bytes_processed, bytes_for_entries;
+ const struct lb_record *lbrec;
+
+ p = ((const char *)cmos_table) + cmos_table-header_length;
+ bytes_for_entries = cmos_table-size - cmos_table-header_length;
+
+ for (bytes_processed = 0;
+ bytes_processed bytes_for_entries;
+ bytes_processed += lbrec-size) {
+ lbrec = (const struct lb_record *)p[bytes_processed];
+
+ if (lbrec-tag == tag)
+ return lbrec;
+ }
+
+ return NULL;
+}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 3/6] Move CLI portion of nvramtool into cli/ subdirectory as first step towards librarization.
* Patrick Georgi patrick.geo...@secunet.com [110127 15:07]: Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer stefan.reina...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] core boot ehci debug
* trevor.davenp...@gmail.com trevor.davenp...@gmail.com [110127 02:56]: Hi, I've been trying to get coreboot to work a machine i have (http:// www.coreboot.org/pipermail/coreboot/2010-November/061987.html) but have so far have not had any luck. I've tried most board types that are similar but all result in the same scenario, flash the rom, rebootnothing on screen. This system does not have serial port available (the closest thing on the board appears to be solder contacts labeled COMB). If you are skilled with soldering or know someone close by who is, that might be an option... The southbridge is a SB700. Is the EHCI Debug Port support usuable on these (the wiki says WIP but it seems the code is there) and do you think it would help to go this route? Is there anything else you could suggest in helping me make any progress on this board? Cheers, Trevor Davenport You will need the patch sent to the list a few minutes ago. Plus, an Ajays NET20DC. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] get USB debug console working in ROM stage
See patch.
This patch gets usbdebug console working in romstage.
- actually hook up usbdebug in printk/print_ for romstage
- make usbdebug.c more similar to the Linux kernel version it was
originally derived from.
- increase retries and timing for usbdebug init (at least one chipset
seems to need this)
- src/pc80/usbdebug_serial.c is not needed
- some small console cleanups
Signed-off-by: Stefan Reinauer reina...@google.com
Index: src/include/usbdebug.h
===
--- src/include/usbdebug.h (revision 6307)
+++ src/include/usbdebug.h (working copy)
@@ -27,22 +27,20 @@
void *ehci_caps;
void *ehci_regs;
void *ehci_debug;
-unsigned devnum;
-unsigned endpoint_out;
-unsigned endpoint_in;
+u32 devnum;
+u32 endpoint_out;
+u32 endpoint_in;
};
int dbgp_bulk_write_x(struct ehci_debug_info *dbg_info, const char *bytes, int size);
int dbgp_bulk_read_x(struct ehci_debug_info *dbg_info, void *data, int size);
-int dbgp_control_msg(struct ehci_dbg_port *ehci_debug, unsigned devnum, int requesttype, int request,
- int value, int index, void *data, int size);
-int ehci_wait_for_port(struct ehci_regs *ehci_regs, int port);
void set_ehci_base(unsigned ehci_base);
-void set_ehci_debug(unsigned ehci_deug);
+void set_ehci_debug(unsigned ehci_debug);
unsigned get_ehci_debug(void);
void set_debug_port(unsigned port);
-void early_usbdebug_init(void);
-void usbdebug_ram_tx_byte(unsigned char data);
+int early_usbdebug_init(void);
+
+//void usbdebug_ram_tx_byte(unsigned char data);
void usbdebug_tx_byte(unsigned char data);
#endif
Index: src/include/console/console.h
===
--- src/include/console/console.h (revision 6307)
+++ src/include/console/console.h (working copy)
@@ -149,6 +149,7 @@
#define print_info_hex32(HEX)printk(BIOS_INFO, %08x, (HEX))
#define print_debug_hex32(HEX) printk(BIOS_DEBUG, %08x, (HEX))
#define print_spew_hex32(HEX)printk(BIOS_SPEW, %08x, (HEX))
+
#else
/* __ROMCC__ */
@@ -156,6 +157,9 @@
#if CONFIG_CONSOLE_SERIAL8250
#include lib/uart8250.c
#endif
+#if CONFIG_USBDEBUG
+#include lib/usbdebug.c
+#endif
#if CONFIG_CONSOLE_NE2K
#include lib/ne2k.c
#endif
@@ -165,6 +169,9 @@
#if CONFIG_CONSOLE_SERIAL8250
uart8250_tx_byte(CONFIG_TTYS0_BASE, byte);
#endif
+#if CONFIG_USBDEBUG
+ usbdebug_tx_byte(byte);
+#endif
#if CONFIG_CONSOLE_NE2K
ne2k_append_data_byte(byte, CONFIG_CONSOLE_NE2K_IO_PORT);
#endif
@@ -186,6 +193,9 @@
#if CONFIG_CONSOLE_SERIAL8250
uart8250_tx_byte(CONFIG_TTYS0_BASE, byte);
#endif
+#if CONFIG_USBDEBUG
+ usbdebug_tx_byte(byte);
+#endif
#if CONFIG_CONSOLE_NE2K
ne2k_append_data_byte(byte, CONFIG_CONSOLE_NE2K_IO_PORT);
ne2k_transmit(CONFIG_CONSOLE_NE2K_IO_PORT);
@@ -198,10 +208,10 @@
if (console_loglevel = loglevel) {
__console_tx_nibble((value 4U) 0x0fU);
__console_tx_nibble(value 0x0fU);
- }
#if CONFIG_CONSOLE_NE2K
ne2k_transmit(CONFIG_CONSOLE_NE2K_IO_PORT);
#endif
+ }
}
static void __console_tx_hex16(int loglevel, unsigned short value)
@@ -211,10 +221,10 @@
__console_tx_nibble((value 8U) 0x0fU);
__console_tx_nibble((value 4U) 0x0fU);
__console_tx_nibble(value 0x0fU);
- }
#if CONFIG_CONSOLE_NE2K
ne2k_transmit(CONFIG_CONSOLE_NE2K_IO_PORT);
#endif
+ }
}
static void __console_tx_hex32(int loglevel, unsigned int value)
@@ -228,10 +238,10 @@
__console_tx_nibble((value 8U) 0x0fU);
__console_tx_nibble((value 4U) 0x0fU);
__console_tx_nibble(value 0x0fU);
- }
#if CONFIG_CONSOLE_NE2K
ne2k_transmit(CONFIG_CONSOLE_NE2K_IO_PORT);
#endif
+ }
}
static void __console_tx_string(int loglevel, const char *str)
@@ -357,9 +367,6 @@
#define print_spew_hex32(HEX)__console_tx_hex32(BIOS_SPEW, HEX)
#endif
-#endif
-
-#ifdef __ROMCC__
/* if included by romcc, include the sources, too. romcc can't use prototypes */
#include console/console.c
#include console/post.c
Index: src/lib/usbdebug.c
===
--- src/lib/usbdebug.c (revision 6307)
+++ src/lib/usbdebug.c (working copy)
@@ -2,6 +2,7 @@
* This file is part of the coreboot project.
*
* Copyright (C) 2006 Eric Biederman (ebied...@xmission.com)
+ * Copyright (C) 2007 AMD
*
* 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
@@ -17,15 +18,24 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
*/
-#if !defined(__ROMCC__)
+#if defined(__ROMCC__)
+#define printk(BIOS_DEBUG, fmt, arg...) do {} while(0)
+#else
#include console/console.h
+#endif
+
+// Does not work if we want early printk to do usb debug, too..
+#define DBGP_DEBUG 0
+#if DBGP_DEBUG
+# define dbgp_printk(fmt_arg...) printk(BIOS_DEBUG, fmt_arg)
#else
-#if CONFIG_CACHE_AS_RAM==0
-#define
Re: [coreboot] [PATCH]Make LPT ports configurable on various i945/ich7 boards
* Georgi, Patrick patrick.geo...@secunet.com [110125 08:59]:
Hi,
attached patch adds a new CMOS variable which triggers activation of the
LPT port. With the CMOS variable set, LPT is found by SeaBIOS, with the
variable reset, it's not.
There's probably a better place for the code to end up in, but this has
to do for now.
Signed-off-by: Patrick Georgi patrick.geo...@secunet.com
Acked-by: Stefan Reinauer stefan.reina...@coreboot.org
+ if (read_option(CMOS_VSTART_lpt, CMOS_VLEN_lpt, 0) != 0) {
Do we want a wrapper like this?
#define read_cmos_option(option, default) \
read_option(CMOS_VSTART_##option, CMOS_VLEN_##option, default)
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6298 - trunk/payloads/external/SeaBIOS
* repository service s...@coreboot.org [110125 20:27]: Author: stepan Date: Tue Jan 25 20:27:23 2011 New Revision: 6298 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6298 Log: Fix abuild thanks to Kevin who came up with this Not this is just to get this working. I think we should still find the right solution. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [RFC] [PATCH] Overclocking support for 939a785gmh
Nice work, Rudolf!
Index: src/mainboard/asrock/939a785gmh/romstage.c
===
--- src/mainboard/asrock/939a785gmh/romstage.c(revision 6298)
+++ src/mainboard/asrock/939a785gmh/romstage.c(working copy)
@@ -48,6 +48,9 @@
#include southbridge/amd/sb700/early_setup.c
#include northbridge/amd/amdk8/debug.c /* After sb700/early_setup.c! */
+#include option_table.h
+
+
#define SERIAL_DEV PNP_DEV(0x2e, W83627DHG_SP1)
#define GPIO2345_DEV PNP_DEV(0x2e, W83627DHG_GPIO2345_V)
@@ -74,7 +77,20 @@
static void sio_init(void)
{
u8 reg;
+ u8 mem_volt = read_option(CMOS_VSTART_memory_voltage,
CMOS_VLEN_memory_voltage, 0);
+ u8 ht_volt = read_option(CMOS_VSTART_ht_voltage, CMOS_VLEN_ht_voltage,
0);
+ u8 gpu_volt = read_option(CMOS_VSTART_gpu_voltage,
CMOS_VLEN_gpu_voltage, 0);
+ u8 sideport_volt = read_option(CMOS_VSTART_sideport_voltage,
CMOS_VLEN_sideport_voltage, 0);
Should these defaults really be all 0? The old defaults seem to be 1 for
gpu_volt, and 6 for sideport_volt, 1 for ht_volt
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix LPC decode ranges on SB700
* Rudolf Marek r.ma...@assembler.cz [110126 00:01]: Hello, Attached patch fixes the LPC decode ranges of SB700. We enable early only Serial/SIO/RTC. Everything else needs to be done by lpc.c Problem was that early settings survived, because the lpc.c is doing ORs only... Hence we decode quite a lot and even strange ranges like IO port 0x4600 etc... Also, if some port which does not fit to predefined set is requested, like 0x290 for Hardware monitor, the wide port is done, but in our case it has range 512 bytes which means we decode in fact 0x290 - 0x490. And if we hit GPU in the 0x3bx range I receive MCE exception if I do isadump -f 0x300 which is bad. Therefore If I detect that the requested range is small (16 bytes) I additionally set the small wide io region so only 16 bytes is decoded. While at it, I fix spelling typos and I init the regs so we don't write random garbage to regs even if we don't enable them later. Signed-off-by: Rudolf Marek r.ma...@assembler.cz Acked-by: Stefan Reinauer stefan.reina...@coreboot.org Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Patch for coreboot_table.c
* Joseph Kellermann joseph.kellerm...@heitec.de [110124 18:33]: This patch fixes an 'write_tables: coreboot table didn't fit (f0221)' issue. Signed-off-by: Josef Kellermann joseph.kellerm...@heitec.de Thanks for spotting this error. Your fix went into the repository as r6295. Best regards, Stefan Reinauer -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Use a tag for SeaBIOS stable checkouts.
* Peter Stuge pe...@stuge.se [110124 00:35]: I neither want to check the changes I make to the config file in to the local repository Can we please not use perl for this? sed can do it just fine. Sure. Not all sed versions support in-place changes though, so the code will have to handle that. Just send the patch, I'll ack. Can I ask why you don't want to create a commit for the changes? It needs more of git setup in order to use the system (such as the user name and email), so I am hesitating to put this constraint on the users for something that should not require a commit in the first place. It's only a configuration change. nor do I want to undo/redo the changes for every build, Well, but every build can (outside abuild) switch to a different branch. And we need to handle that. (Ie. a user first building with master, then building with stable.) I believe that my original code did that, at least it worked in my tests. nor do I want to re-checkout for every target. Why not? Note we are talking git checkout now, not git clone. No, actually I was talking about git clone. Sorry, I am not quite used to all the git nomenclature yet. In fact git checkout simply failed for me with varying errors. +TAG-$(CONFIG_SEABIOS_MASTER)=origin/master TAG-$(CONFIG_SEABIOS_STABLE)=rel-0.6.1.3 .. checkout: echo Checking out SeaBIOS $(TAG-y) - test -d seabios ( cd seabios; git pull ) || \ + test -d seabios ( cd seabios; git fetch ) || \ I agree that git fetch should be here, certainly not git pull. A fetch alone does not seem to make much sense. It will not update the tree when working with the master tag, as far as I can tell. The idea of master is that you will always get the latest and greatest SeaBIOS, so the tree should be updated accordingly, eh, fetched and merged. But we need to consider what we want to happen if someone has made local changes in this repository. And we also need to consider *our* local changes that are done in this repository. The fact that they are not so easily distinguishable is a problem. Let's start with the simple case of us just building a plain image from the SeaBIOS git repository without the user changing stuff on top of that. Remember, this is just the simple path. If you want to develop SeaBIOS and change it, you can always specify it as external ELF payload instead of using this automatism. - cd seabios; git checkout $(TAG-y) + cd seabios; git checkout -m $(TAG-y) I don't really like trying to do a merge of local changes here. It will quickly conflict with later development from upstream. Well, unless SeaBIOS switches over to a non-checked-in, auto generated config.h we will probably have to do this. Do we want to switch SeaBIOS over to Kconfig? That would certainly solve the issue, and allow to specify a default config, as well as user or coreboot specific changes to the configuration. We need to weigh two objectives against each other: 1. someone has local changes in payloads/external/SeaBIOS/seabios that we don't want to erase I think that's out of focus, as described above. However, we need to configure SeaBIOS to actually work on top of coreboot, and that requires automatically doing local changes due to the way the code works currently. I think merging is always the wrong thing to do, because it will make a mess of the repo and what the user has configured is exclusively one of the tags we offer, so that is what they should always get. I think it's quite incredible that we can not update the version of SeaBIOS automatically because we enabled it to build with coreboot and serial console support. We need to fix this constraint. Subject: [PATCH 1/2] Allow initial COMMONCFLAGS to be set from the make command line The patch will probably allow CFLAGS like -O2 be overwritten by -Os? I think COMMONCFLAGS is not something the user should set. The commonly used notion would suggest the user set CFLAGS instead. Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 384bf79..ccdf96a 100644 --- a/Makefile +++ b/Makefile @@ -27,7 +27,7 @@ cc-option = $(shell if test -z `$(1) $(2) -S -o /dev/null -xc \ /dev/null 21`; then echo $(2); else echo $(3); fi ;) # Default compiler flags -COMMONCFLAGS = -Os -MD -Wall -Wno-strict-aliasing -Wold-style-definition \ +COMMONCFLAGS += -Os -MD -Wall -Wno-strict-aliasing -Wold-style-definition \ $(call cc-option,$(CC),-Wtype-limits,) \ -m32 -march=i386 -mregparm=3 -mpreferred-stack-boundary=2 \ -mrtd -minline-all-stringops \ From: Peter Stuge pe...@stuge.se Date: Mon, 24 Jan 2011 00:20:18 +0100 Subject: [PATCH 2/2] Allow override of CONFIG_COREBOOT CONFIG_DEBUG_SERIAL CONFIG_VGAHOOKS This allows the coreboot build system control over these parameters without having to modify src/config.h. ---
Re: [coreboot] [PATCH] Use a tag for SeaBIOS stable checkouts.
* Kevin O'Connor ke...@koconnor.net [110122 17:28]: Use a tag (rel-0.6.1.3) for SeaBIOS stable checkouts instead of the stable branch. The tag is a little safer because it prevents an incorrect commit to the stable branch from being immiediately picked up by coreboot users. Note - rel-0.6.1.3 (and 0.6.1-stable) now have the CFLAGS build fix that was causing build failures for coreboot users. Signed-off-by: Kevin O'Connor ke...@koconnor.net --- payloads/external/SeaBIOS/Makefile.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/payloads/external/SeaBIOS/Makefile.inc b/payloads/external/SeaBIOS/Makefile.inc index 120e796..faca57e 100644 --- a/payloads/external/SeaBIOS/Makefile.inc +++ b/payloads/external/SeaBIOS/Makefile.inc @@ -1,7 +1,7 @@ TAG-$(CONFIG_SEABIOS_MASTER)=master -TAG-$(CONFIG_SEABIOS_STABLE)=0.6.1-stable +TAG-$(CONFIG_SEABIOS_STABLE)=rel-0.6.1.3 all: seabios -- 1.7.3.4 On the build system with git 1.7.3.4 this breaks the build because 0.6.1-stable is a head and rel-0.6.1.3 is a master. Starting with the second target git dies with: Checking out SeaBIOS rel-0.6.1.3 test -d coreboot-builds/sharedutils/seabios ( cd coreboot-builds/sharedutils/seabios; pwd; git pull ) || \ git clone git://git.linuxtogo.org/home/kevin/seabios.git coreboot-builds/sharedutils/seabios /srv/svn/coreboot-extra/tmp/coreboot-6292/payloads/external/SeaBIOS/coreboot-builds/sharedutils/seabios You are not currently on a branch, so I cannot use any 'branch.branchname.merge' in your configuration file. Please specify which remote branch you want to use on the command line and try again (e.g. 'git pull repository refspec'). See git-pull(1) for details. fatal: destination path 'coreboot-builds/sharedutils/seabios' already exists and is not an empty directory. make[2]: *** [checkout] Error 128 make[1]: *** [seabios] Error 2 make[1]: Leaving directory `/srv/svn/coreboot-extra/tmp/coreboot-6292' make: *** [all] Error 2 Not sure what the right fix is for this. I neither want to check the changes I make to the config file in to the local repository nor do I want to undo/redo the changes for every build, nor do I want to re-checkout for every target. Is this possible with git? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Use a tag for SeaBIOS stable checkouts.
* Kevin O'Connor ke...@koconnor.net [110123 17:12]: On Sun, Jan 23, 2011 at 07:43:59AM +0100, Peter Stuge wrote: Kevin O'Connor wrote: Use a tag (rel-0.6.1.3) for SeaBIOS stable checkouts instead of the stable branch. The tag is a little safer because it prevents an incorrect commit to the stable branch from being immiediately picked up by coreboot users. Note - rel-0.6.1.3 (and 0.6.1-stable) now have the CFLAGS build fix that was causing build failures for coreboot users. Signed-off-by: Kevin O'Connor ke...@koconnor.net Acked-by: Peter Stuge pe...@stuge.se Do you think we should also default to the stable tag rather than master? It looks like it already defaults to the stable branch. Yes, that is what we do. You can choose to go for master in Kconfig though. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] superiotool IT8720F support
* Christian Ruppert id...@gentoo.org [110120 13:48]: Hey guys, attached is a patch to add support for the IT8720F Super I/O to superiotool. There are three NANA bits in the GPIO reset part, the first two of those were unclear to me so I added them as NANA. One with more experience than me could/should take a look at those please but it should be ok to apply it anyway. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 Add support for the IT8720F Super I/O Signed-off-by: Christian Ruppert id...@gentoo.org Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]nvramtool: Abstract CMOS accesses
* Georgi, Patrick patrick.geo...@secunet.com [110120 14:34]: Hi, in preparation of teaching nvramtool to edit files instead of real hardware, this patch abstracts CMOS accesses a bit more. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Signed-off-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]nvramtool: Teach it to work on data in memory
* Georgi, Patrick patrick.geo...@secunet.com [110120 14:35]: Attached patch allows nvramtool to work on in-memory data. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]nvramtool: Support CBFS Images in nvramtool
* Georgi, Patrick patrick.geo...@secunet.com [110120 14:36]: This is the first patch of this series that actually adds a new feature. Use nvramtool -C to work on CBFS images that contain cmos_layout.bin for CMOS metadata and cmos.default for CMOS defaults. Read/Write/Enum on CMOS data work on cmos.default then. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]nvramtool: Support CMOS data from non-CBFS file, too
* Georgi, Patrick patrick.geo...@secunet.com [110120 14:38]: This patch adds a -D option to tell nvramtool to work on data in a plain CMOS image (as extracted by the nvramtool dump option, for example). Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Nice work! Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]nvramtool: Look at another place for the CMOS checksum specification
* Georgi, Patrick patrick.geo...@secunet.com [110120 14:31]: Hi, This patch tells nvramtool about another place where it can find information about the CMOS checksum location and range before it reverts to its own default values. Signed-off-by: Patrick Georgi patrick.geo...@secunet.com Please add a comment that this is needed for parsing the cmos_layout.bin file in cbfs. Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] gcc or glibc version dependancy problem
* Yoo, Taik-Yon jaa...@gmail.com [110121 03:39]: I built r6275 for my RS690/SB600 based box with debug level 8. This box did not boot up. The last displayed console message is `bsp_apicid=0x`. This happens line 269 at src/console/vtxprintf.c. ... num = va_arg(args, unsigned int); ... I moved this source tree to ubuntu 9.0.4_x86_64 box. Compiled again. My box was correctly booted. I don't know why this happens. Build Environment: - Gentoo Linux x86_64 - gcc: 4.5.2 - glibc: 2.12.2 Your compiler is probably faulty. Can you please try with the coreboot reference toolchain (build with util/crossgcc/buildgcc) ? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] abuild error
* Nils njaco...@hetnet.nl [110120 23:59]: I investigated this some more and i think i found the problem. The crosscompiler is working ok now and my coreboot rom has the same size as the one from the automatic build system of coreboot.org exept for the SeaBios payload mine is 46881 bytes and the one from the automatic build system of coreboot.org is 33545 bytes.(same stable version) Ah! This went undetected because the build system was still building coreboot with a very old version of filo. It should be picking up SeaBIOS with the coming releases. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [patch] AMDMCT DDR3 fix Dual rank + high mem frequency.
* Bao, Zheng zheng@amd.com [110119 10:37]:
For Cx, each ChipSel need to be sent MR command.
After this patch, tilapia can run in higher memory frequency.
To test the high frequency, dont forget to change the freq limit in
mcti_d.c:
static void mctGet_MaxLoadFreq(struct DCTStatStruc *pDCTstat)
{
pDCTstat-PresetmaxFreq = 800;
}
Is it safe to add this to the repository? I'm worried that people will
forget over time.
Signed-off-by: Zheng Bao zheng@amd.com
Acked-by: Stefan Reinauer ste...@coreboot.org
Index: src/northbridge/amd/amdmct/mct_ddr3/mctsdi.c
===
--- src/northbridge/amd/amdmct/mct_ddr3/mctsdi.c (revision 6275)
+++ src/northbridge/amd/amdmct/mct_ddr3/mctsdi.c (working copy)
@@ -306,7 +306,7 @@
if (!(pDCTstat-Status (1
SB_Registered)))
break; /* For UDIMM, only send
MR commands once per channel */
}
- if (pDCTstat-LogicalCPUID (AMD_DR_Cx/* | AMD_RB_C0
*/)) /* We dont support RB_C0 now. need to be added and tested. */
+ if (pDCTstat-LogicalCPUID (AMD_DR_Bx/* | AMD_RB_C0
*/)) /* We dont support RB_C0 now. need to be added and tested. */
if (!(pDCTstat-Status (1 SB_Registered)))
MrsChipSel ++;
}
--
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] Add new ec subdir for Embedded Controllers
* Sven Schnelle sv...@stackframe.org [110117 21:46]: Index: src/ec/acpi/ec.h === --- src/ec/acpi/ec.h (revision 0) +++ src/ec/acpi/ec.h (working copy) @@ -17,9 +17,11 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#ifndef _MAINBOARD_EC_H -#define _MAINBOARD_EC_H +#ifndef _EC_ACPI_H +#define _EC_ACPI_H +#include chip.h Is chip.h needed ? + #define EC_DATA 0x62 #define EC_SC0x66 @@ -28,6 +28,7 @@ select SOUTHBRIDGE_TI_PCIXX12 select SUPERIO_SMSC_FDC37N972 select SUPERIO_SMSC_SIO10N268 + select EC_ACPI select BOARD_HAS_FADT select HAVE_ACPI_TABLES select HAVE_PIRQ_TABLE Maybe we want to add support for explicit EC types and reference those here? And then have the acpi code shared between all those ECs. The Roda RK886EX has it's EC code spread out into src/superio/renesas, too. Index: src/mainboard/getac/p470/mainboard_smi.c === --- src/mainboard/getac/p470/mainboard_smi.c (revision 6260) +++ src/mainboard/getac/p470/mainboard_smi.c (working copy) @@ -26,7 +26,8 @@ #include southbridge/intel/i82801gx/i82801gx.h #include southbridge/intel/i82801gx/nvs.h #include northbridge/intel/i945/udelay.c -#include ec.c +#include ec/acpi/ec.h ec/acpi.h? +#include ec_oem.c #define MAX_LCD_BRIGHTNESS 0xd8 Index: src/mainboard/getac/p470/Makefile.inc === --- src/mainboard/getac/p470/Makefile.inc (revision 6260) +++ src/mainboard/getac/p470/Makefile.inc (working copy) @@ -21,3 +21,4 @@ ramstage-$(CONFIG_HAVE_ACPI_SLIC) += acpi_slic.c smm-$(CONFIG_HAVE_SMI_HANDLER) += mainboard_smi.c +smm-$(CONFIG_HAVE_SMI_HANDLER) += ../../../ec/acpi/ec.c shouldn't the EC makefile in src/ec/acpi say smm-$(CONFIG_HAVE_SMI_HANDLER) += ec.c instead? Index: src/mainboard/getac/p470/devicetree.cb === --- src/mainboard/getac/p470/devicetree.cb(revision 6260) +++ src/mainboard/getac/p470/devicetree.cb(working copy) @@ -133,6 +133,12 @@ end device pnp 4e.b off # HWM end + chip ec/acpi + device pnp ff.1 on + io 0x60 = 0x62 + io 0x62 = 0x66 + end + end what's the device pnp and io 0x60/io 0x62 used for? this does not look too good. I would wipe it. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6253 - in trunk: src/arch/x86 src/mainboard/getac/p470 src/mainboard/kontron/986lcd-m src/mainboard/roda/rk886ex src/pc80 util/cbfstool
* Peter Stuge pe...@stuge.se [110117 03:25]:
repository service wrote:
+++ trunk/src/pc80/mc146818rtc_early.c Fri Jan 14 08:40:24 2011
(r6253)
..
static inline int do_normal_boot(void)
{
+ char *cmos_default = cbfs_find_file(cmos.default, 0xaa);
unsigned char byte;
+ int i;
if (cmos_error() || !cmos_chksum_valid()) {
+ if (cmos_default) {
+ printk_warning(WARNING - CMOS CORRUPTED. RESTORING
DEFAULTS.\n);
+ /* First 14 bytes are reserved for
+ RTC and ignored by nvramtool, too.
+ Only 128 bytes: 128+ requires cmos configuration and
+ contains only suspend-to-ram data, which isn't part
+ of the recovery procedure. */
+ for (i = 14; i 128; i++) {
+ cmos_write(cmos_default[i], i);
+ }
+ /* Now reboot to run with default cmos. */
+ outb(0x06, 0xcf9);
+ for (;;) asm(hlt); /* Wait for reset! */
Isn't this kinda ugly to have in the rtc code? We could at least have
some kind of reset/reboot function..
agreed. Is this possible? Maybe romcc makes it harder ...
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6271 - trunk/src/arch/x86/include/arch
* Peter Stuge pe...@stuge.se [110119 07:37]:
repository service wrote:
Log:
The cn700.c code references mainboard_interrupt_handlers() which isn't
defined if VGA_ROM_RUN is off. Define a dummy implementation of that
function for this case.
Signed-off-by: Kevin O'Connor ke...@koconnor.net
Acked-by: Stefan Reinauer ste...@coreboot.org
Modified:
trunk/src/arch/x86/include/arch/interrupt.h
Modified: trunk/src/arch/x86/include/arch/interrupt.h
==
--- trunk/src/arch/x86/include/arch/interrupt.h Tue Jan 18 15:38:59
2011(r6270)
+++ trunk/src/arch/x86/include/arch/interrupt.h Wed Jan 19 07:31:24
2011(r6271)
@@ -22,4 +22,8 @@
#include registers.h
/* setup interrupt handlers for mainboard */
+#if defined(CONFIG_PCI_OPTION_ROM_RUN_REALMODE)
CONFIG_PCI_OPTION_ROM_RUN_REALMODE
extern void mainboard_interrupt_handlers(int intXX, void *intXX_func);
+#else
+static inline void mainboard_interrupt_handlers(int intXX, void
*intXX_func) { }
+#endif
Didn't I NAK this sufficiently clearly?
Actually, no. I got the impression that the discussion fell asleep
without any better solution.
1. there was no alternative patch on the list
2. it fixes a compile problem
It belongs in the northbridge files.
Cool, go ahead. I will gladly ack to replace this solution with yours.
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [MSRTOOL] [PATCH] Add Geode GX2 memmory desriptor registers.
* Nils njaco...@hetnet.nl [110113 15:42]: Add Geode GX2 memmory descriptors. Add a simple README file. Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, Nils. Thanks, r6274 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Geode GX2 VGA problems
* Nils njaco...@hetnet.nl [110113 16:19]: Hello all, In the past i used coreboot without a VGAbios and used the linux framebuffer driver and that works ok. I am trying to get onboard early VGA running on my Geode GX2 board but until now i have no succes.( the screen stays black until the framebuffer driver in linux loads) I have SoftVG in my VSA2 blob. I am running the (extracted) original VGA bios via Seabios. This is from lspci with the original bios: 00:01.1 0300: 100b:0030 (prog-if 00 [VGA controller]) Subsystem: 100b:0030 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- Region 0: Memory at 4100 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 40ffc000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at 40ff8000 (32-bit, non-prefetchable) [size=16K] Region 3: Memory at 40ff4000 (32-bit, non-prefetchable) [size=16K] This is from lspci with coreboot/seabios: 00:01.1 0300: 100b:0030 (prog-if 00 [VGA controller]) Subsystem: 100b:0030 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- Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at fe00 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at fe004000 (32-bit, non-prefetchable) [size=16K] Region 3: Memory at fe008000 (32-bit, non-prefetchable) [size=16K] Expansion ROM at unassigned [disabled] Kernel driver in use: gxfb If i force the driver on via the virtual VSA2 register in gprhinit.c the softvg seems to setup a video text buffer from A-B . Could the problem have anything to do with the fact that the VSA2 code runs in a different memory region? (setup by oprom) And therefore the video bars GP, VP and DC are also in a different address range so VSA2 or VGAbios can not find them? which VSA are you using? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Preliminary support for ASUS K8V-X SE with VIA K8T800 southbridge
* Alex G. mr.nuke...@gmail.com [110114 16:37]: Added preliminary support for the ASUS K8V-X SE and the VIA K8T800 chipset. Coreboot is able to finalize and load SeaBIOS, which boots from IDE HDD or DVD. IRQ ACPI and MP tables are not yet complete. Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com --- I've refined the previous patch with the help of ruik (on #coreboot IRC). This is still a work in progress. As of right now, USB does not work, and linux freezes on boot, IRQ routing is a mess. Alex Looks good. can someone with the K8T890 hardware test this? Stefam -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] sb800 code derived from sb700 implementation
* Bao, Zheng zheng@amd.com [110111 03:19]: I personally like this patch, not because I did. It is easy to use and handle. I am gonna signed-off-by it. If I get support, I will check it in. Zheng Signed-off-by: Zheng Bao zheng@amd.com Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serial port 2 fix for Epia-Mii
* Snoke sn...@iki.fi [110109 20:07]: Serial port 2 won't work on Epia-Mii. Following patch I get it work. Found solution at Linuxbios archive : [LinuxBIOS] EPIA M COM2 problem + possible solution? --- coreboot/src/superio/via/vt1211/vt1211.c 2011-01-09 16:05:47.0 +0200 +++ coreboot_epia/src/superio/via/vt1211/vt1211.c 2011-01-09 19:49:53.0 +0200 @@ -63,7 +63,7 @@ case VT1211_PP: case VT1211_SP1: case VT1211_SP2: - pnp_write_config(dev, index + 0, (iobase 2) 0xff); Are you sure this line should be deleted? + pnp_write_config(dev, 0x27, 0x00); I think the case VT1211_SP2: should go extra: case VT1211_SP1: pnp_write_config(dev, index + 0, (iobase 2) 0xff); break; case VT1211_SP2: pnp_write_config(dev, index + 0, (iobase 2) 0xff); pnp_write_config(dev, 0x27, 0x00); // Serial Port 2 Multi Function Pin Select break; Can you please try and see if this does the job? Signed-off-by: Stefan Reinauer ste...@coreboot.org break; case VT1211_ROM: /* TODO: Error. VT1211_ROM doesn't have an I/O base. */ -- 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] Add new ec subdir for Embedded Controllers
* Peter Stuge pe...@stuge.se [110119 07:55]: Sven Schnelle wrote: +++ src/ec/acpi/Makefile.inc(revision 0) @@ -0,0 +1 @@ +driver-y += ec.c .. +++ src/mainboard/roda/rk886ex/Makefile.inc (working copy) @@ -18,7 +18,6 @@ ## ramstage-y += m3885.c -ramstage-y += ec.c driver-y += rtl8168.c smm-$(CONFIG_HAVE_SMI_HANDLER) += mainboard_smi.c I think it should be ramstage-y also in ec/acpi/Makefile.inc no? Yes, I think so too. In theory, unused objects in ramstage are kicked out, while in drivers they are not. Maybe with a smart generation of gcc and binutils evolving, we can get rid of this size hack and treat everything in ram stage the same way, while LTO keeps the image small for us. I did some tests with LTO and 4.5.0, and the resulting images were not bootable. However, I think since then a lot of bugs have been fixed. So maybe someone wants to try? Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r6253 - in trunk: src/arch/x86 src/mainboard/getac/p470 src/mainboard/kontron/986lcd-m src/mainboard/roda/rk886ex src/pc80 util/cbfstool
* Stefan Reinauer stefan.reina...@coreboot.org [110119 07:37]:
* Peter Stuge pe...@stuge.se [110117 03:25]:
repository service wrote:
+++ trunk/src/pc80/mc146818rtc_early.cFri Jan 14 08:40:24 2011
(r6253)
..
static inline int do_normal_boot(void)
{
+ char *cmos_default = cbfs_find_file(cmos.default, 0xaa);
unsigned char byte;
+ int i;
if (cmos_error() || !cmos_chksum_valid()) {
+ if (cmos_default) {
+ printk_warning(WARNING - CMOS CORRUPTED. RESTORING
DEFAULTS.\n);
+ /* First 14 bytes are reserved for
+RTC and ignored by nvramtool, too.
+Only 128 bytes: 128+ requires cmos configuration and
+contains only suspend-to-ram data, which isn't part
+of the recovery procedure. */
+ for (i = 14; i 128; i++) {
+ cmos_write(cmos_default[i], i);
+ }
+ /* Now reboot to run with default cmos. */
+ outb(0x06, 0xcf9);
+ for (;;) asm(hlt); /* Wait for reset! */
Isn't this kinda ugly to have in the rtc code? We could at least have
some kind of reset/reboot function..
agreed. Is this possible? Maybe romcc makes it harder ...
To update on this, there are many different ways to do a reset. The
above is not among those implemented by (m)any mainboards I think. So to
keep this reliable because it was tested, I suggest we leave it for now.
It would be nice to see someone cleanup all the different reset methods,
but this is not going to be a fun job. It's highly likely that we
actually use the wrong reset in many places.
./pc80/mc146818rtc_early.c: outb(0x06, 0xcf9);
./northbridge/intel/i945/raminit.c: outb(0x00, 0xcf9);
./northbridge/intel/i945/raminit.c: outb(0x0e, 0xcf9);
./northbridge/intel/i945/raminit.c: outb(0x00, 0xcf9);
./northbridge/intel/i945/raminit.c: outb(0x0e, 0xcf9);
./northbridge/intel/i945/early_init.c: outb(0x06, 0xcf9);
./northbridge/via/cx700/reset.c:outb((1 2) | (1 1), 0xcf9);
./northbridge/via/vx800/examples/romstage.c:outb(6, 0xcf9);
./southbridge/nvidia/mcp55/reset.c: outb((0 3)|(02)|(11), 0xcf9);
./southbridge/nvidia/mcp55/reset.c: outb((0 3)|(12)|(11), 0xcf9);
./southbridge/nvidia/ck804/reset.c: outb((0 3) | (0 2) | (1 1),
0xcf9);
./southbridge/nvidia/ck804/reset.c: outb((0 3) | (1 2) | (1 1),
0xcf9);
./southbridge/intel/sch/reset.c:outb(0x04, 0xcf9);
./southbridge/intel/sch/reset.c:outb(0x02, 0xcf9);
./southbridge/intel/sch/reset.c:outb(0x06, 0xcf9);
./southbridge/intel/i82801ex/reset.c:outb((0 3)|(12)|(11), 0xcf9);
./southbridge/intel/i82801bx/reset.c: outb((1 2) | (1 1), 0xcf9);
./southbridge/intel/i82801cx/reset.c:outb((0 3)|(12)|(11), 0xcf9);
./southbridge/intel/i82801gx/reset.c:outb(0x04, 0xcf9);
./southbridge/intel/i82801gx/reset.c: outb((1 2) | (1 1), 0xcf9);
./southbridge/intel/i82801gx/reset.c:outb(0x02, 0xcf9);
./southbridge/intel/i82801gx/reset.c:outb(0x06, 0xcf9);
./southbridge/intel/i82801dx/reset.c: outb((0 3) | (1 2) | (1 1),
0xcf9);
./southbridge/intel/i82801ax/reset.c: outb((1 2) | (1 1), 0xcf9);
./southbridge/intel/i82371eb/i82371eb.h:#define RC 0xcf9 /*
Reset control register */
./southbridge/intel/esb6300/reset.c:outb((0 3) | (1 2) | (1 1),
0xcf9);
./southbridge/intel/i3100/reset.c: outb(0x06, 0xcf9);
./southbridge/sis/sis966/reset.c: outb((0 3)|(02)|(11), 0xcf9);
./southbridge/sis/sis966/reset.c: outb((0 3)|(12)|(11), 0xcf9);
./southbridge/amd/sb700/reset.c:outb((0 3) | (0 2) | (1 1),
0xcf9);
./southbridge/amd/sb700/reset.c:outb((0 3) | (1 2) | (1 1),
0xcf9);
./southbridge/amd/sb600/reset.c:outb((0 3) | (0 2) | (1 1),
0xcf9);
./southbridge/amd/sb600/reset.c:outb((0 3) | (1 2) | (1 1),
0xcf9);
./southbridge/broadcom/bcm5785/reset.c: outb((0 3)|(02)|(11), 0xcf9);
./southbridge/broadcom/bcm5785/reset.c: outb((0 3)|(12)|(11),
0xcf9);
./mainboard/intel/eagleheights/reset.c: outb(0x04, 0xcf9);
./mainboard/intel/eagleheights/reset.c: outb(0x06, 0xcf9);
./mainboard/intel/jarrell/reset.c:outb(0x04, 0xcf9);
./mainboard/intel/jarrell/reset.c:outb(0x02, 0xcf9);
./mainboard/intel/jarrell/reset.c:outb(0x06, 0xcf9);
./mainboard/intel/jarrell/reset.c:outb(0x0e, 0xcf9);
./mainboard/via/epia-m700/romstage.c: outb(6, 0xcf9);
./mainboard/supermicro/x6dhr_ig2/reset.c:outb(0x04, 0xcf9);
./mainboard/supermicro/x6dhr_ig2/reset.c:outb(0x02, 0xcf9);
./mainboard/supermicro/x6dhr_ig2/reset.c:outb(0x06, 0xcf9);
./mainboard/supermicro/x6dhe_g/reset.c:outb(0x04, 0xcf9);
./mainboard
Re: [coreboot] [commit] r5902 - in trunk/src: cpu/amd/car cpu/intel/car cpu/intel/model_106cx cpu/intel/model_6ex cpu/intel/model_6fx cpu/via/car include/cpu/x86
* Kevin O'Connor ke...@koconnor.net [110116 20:04]: On Fri, Oct 01, 2010 at 11:46:05PM +0200, repository service wrote: Author: uwe Date: Fri Oct 1 23:46:04 2010 New Revision: 5902 URL: https://tracker.coreboot.org/trac/coreboot/changeset/5902 Log: Factor out common CAR asm snippets. This makes the CAR implementations a lot more readable, shorter and easier to follow, and also reduces the amount of uselessly duplicated code. For example there are more than 12 open-coded enable cache instances spread all over the place (and 12 disable cache ones), multiple enable mtrr, save BIST, restore BIST, etc. etc. Signed-off-by: Uwe Hermann u...@hermann-uwe.de Acked-by: Peter Stuge pe...@stuge.se I'd like to express my disapointment that this patch went in. Today I updated my repo and went to find out why my epia-cn reverted (yet again) to doing lzma uncompression without caching. I had to wade through the effects of this patch. This patch is a regression - it makes the code harder to understand. -Kevin I agree. And I would like to back it out. Will do so if I get 2 acks. Signed-off-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Via CAR code should cache CONFIG_RAMBASE..CONFIG_RAMTOP for ramstage.
* Kevin O'Connor ke...@koconnor.net [110116 20:50]: Now that the VIA code is run above 1Meg (like other boards), it should cache that range instead of the first 1Meg. This reduces boot time by about 1 second on epia-cn. This patch also adds a MTRRphysMaskValid bit definition. Signed-off-by: Kevin O'Connor ke...@koconnor.net Acked-by: Stefan Reinauer ste...@coreboot.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PATCH for NOKIA IP530
* Marc Bertens mbert...@xs4all.nl [110116 21:57]: Hi all, Acked-by: Marc Bertens mbertens.xs4all.nl Tested-by: Marc Bertens mbertens.xs4all.nl Guess it needs a Signed-off-by from you... http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure Acked-by: Stefan Reinauer ste...@coreboot.org Stefan Here is a new patch for the Nokia IP530, it contains; * Selection of the P3 cup in the Kconfig * In Kconfig the board revision can be selected. * In the devicetree,cb added comments and commented-out some things that where not needed, but for now left them in the file. * New PIRQ table for board revision B, did this by some macros to keep it simple. Marc Bertens -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix compile failure when VGA_ROM_RUN disabled on epia-cn.
* Kevin O'Connor ke...@koconnor.net [110116 18:59]:
The cn700.c code references mainboard_interrupt_handlers() which isn't
defined if VGA_ROM_RUN is off. Define a dummy implementation of that
function for this case.
Signed-off-by: Kevin O'Connor ke...@koconnor.net
Acked-by: Stefan Reinauer ste...@coreboot.org
And I think the extern should also be removed. It's not needed for
functions.
---
src/arch/x86/include/arch/interrupt.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/arch/x86/include/arch/interrupt.h
b/src/arch/x86/include/arch/interrupt.h
index 2d2330b..c3cda30 100644
--- a/src/arch/x86/include/arch/interrupt.h
+++ b/src/arch/x86/include/arch/interrupt.h
@@ -22,4 +22,8 @@
#include registers.h
/* setup interrupt handlers for mainboard */
+#if defined(CONFIG_PCI_OPTION_ROM_RUN_REALMODE)
CONFIG_PCI_OPTION_ROM_RUN_REALMODE
extern void mainboard_interrupt_handlers(int intXX, void *intXX_func);
+#else
+static inline void mainboard_interrupt_handlers(int intXX, void *intXX_func)
{ }
+#endif
--
1.7.3.4
--
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
