[coreboot] [PATCH]Make macros in Makefile more readable
Hi, attached patch should help devs to more easily understand the main loop that includes Makefile.incs. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Index: Makefile === --- Makefile(revision 5186) +++ Makefile(working copy) @@ -119,9 +119,33 @@ crt0s:= ldscripts:= types:=obj initobj driver smmobj -includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) $(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval $(type)s+=$$(patsubst util/%,$(obj)/util/%,$$(patsubst src/%,$(obj)/%,$$(addprefix $(dir $(1)),$$($(type)-y))) $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y) -evaluate_subdirs=$(eval cursubdirs:=$(subdirs)) $(eval subdirs:=) $(foreach dir,$(cursubdirs),$(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1 $(if $(subdirs),$(eval $(call evaluate_subdirs, $(1 +# Clean -y variables, include Makefile.inc +# If $(3) is non-empty, add paths to files in X-y, and add them to Xs +# Add subdirs-y to subdirs +includemakefiles= \ + $(foreach type,$(2), $(eval $(type)-y:=)) \ + $(eval subdirs-y:=) \ + $(eval -include $(1)) \ + $(if $(strip $(3)), \ + $(foreach type,$(2), \ + $(eval $(type)s+= \ + $$(patsubst util/%, \ + $(obj)/util/%, \ + $$(patsubst src/%, \ + $(obj)/%, \ + $$(addprefix $(dir $(1)),$$($(type)-y))) \ + $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y) + +# For each path in $(subdirs) call includemakefiles, passing $(1) as $(3) +# Repeat until subdirs is empty +evaluate_subdirs= \ + $(eval cursubdirs:=$(subdirs)) \ + $(eval subdirs:=) \ + $(foreach dir,$(cursubdirs), \ + $(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1 \ + $(if $(subdirs),$(eval $(call evaluate_subdirs, $(1 + # collect all object files eligible for building subdirs:=$(PLATFORM-y) $(BUILD-y) $(eval $(call evaluate_subdirs, modify)) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-) Regards, Darmawan On 3/5/10, Marc Jones marcj...@gmail.com wrote: On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi, Google Summer of Code 2010 is approaching quickly. I hope coreboot/flashrom are going to participate again, and to do that, we have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12). Do we want to participate? Who is willing to mentor? Any developers who want to apply as students? Who will serve as organization administrator? Are there any good ideas for GSoC (coreboot or flashrom)? I would like for coreboot to do GSoC again. I think it is great exposure for the project and I would be happy to be a mentor again. I'll put some thought into what prospective students might work on. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- -= Human knowledge belongs to the world =- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]: Disable ExtINT in ioapic.c
On 3/5/10 11:02 PM, Marc Jones wrote: You are right. The sb600 was really doing a clear_ioapic() previously. I don't yet understand why the virtual wire mode causes problems. It is either an additional sb600 setup issue or a mainboard problem with how EXTINT is connected. The setup_ioapic() should probably have more options as EXTINT doesn't have to be connected to the APIC. Signed-off-by: Marc Jones marcj...@gmail.com Marc Acked-by: Stefan Reinauer ste...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]Make macros in Makefile more readable
On 3/6/10 9:08 AM, Patrick Georgi wrote: Hi, attached patch should help devs to more easily understand the main loop that includes Makefile.incs. Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
does coreboot and flashrom will join gsoc 2010 as an union or else? i am thinking who about making flashrom can be used under windows? On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun darmawan.sali...@gmail.com wrote: Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-) Regards, Darmawan On 3/5/10, Marc Jones marcj...@gmail.com wrote: On Thu, Mar 4, 2010 at 8:55 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi, Google Summer of Code 2010 is approaching quickly. I hope coreboot/flashrom are going to participate again, and to do that, we have to apply between 2010-03-08 and 2010-03-12 (March 8 - March 12). Do we want to participate? Who is willing to mentor? Any developers who want to apply as students? Who will serve as organization administrator? Are there any good ideas for GSoC (coreboot or flashrom)? I would like for coreboot to do GSoC again. I think it is great exposure for the project and I would be happy to be a mentor again. I'll put some thought into what prospective students might work on. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- -= Human knowledge belongs to the world =- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- Wang Qing Pei MSN:wangqing...@hotmail.com msn%3awangqing...@hotmail.com Gmail:wangqing...@gmail.com gmail%3awangqing...@gmail.com Phone:86+13426369984 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 10:03, Jason Wang wrote: On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote: Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-) i am thinking who about making flashrom can be used under windows? I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet. does coreboot and flashrom will join gsoc 2010 as an union or else? Yes, coreboot and flashrom will have one joint project for GSoC 2010. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] consolidate K8M890 VGA code - take2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Following patch changes the K8M890 VGA handling. It reverts the framebuffer size
to option based (similar what Uwe did) and also it uses GFXUMA to handle the
high_tables_start offset from memory top.
To satisfy the CMOS option users (Hi, libv! ;) I added also a possibility to do
that through CMOS.
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
Works here, maybe delete that old version from patchwork (from 28.10.2009
22:53)?
Thanks,
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuSW7cACgkQ3J9wPJqZRNWa3wCgj5Fv/0CkqJXdtSWlvK9X2DW+
i7wAniOA+1D8GBoNjv3VYrbh2xyn+THB
=bTQ6
-END PGP SIGNATURE-
Index: src/southbridge/via/k8t890/Kconfig
===
--- src/southbridge/via/k8t890/Kconfig (revision 5169)
+++ src/southbridge/via/k8t890/Kconfig (working copy)
@@ -1,3 +1,38 @@
config SOUTHBRIDGE_VIA_K8T890
bool
+config SOUTHBRIDGE_VIA_K8T890_VGA_EN
+ bool Enable onboard K8M890 graphics
+ default y
+ depends on SOUTHBRIDGE_VIA_K8T890
+ select VGA
+ select GFXUMA
+
+choice
+ prompt Framebuffer size
+ default K8M890_VIDEO_MB_32MB
+ depends on SOUTHBRIDGE_VIA_K8T890_VGA_EN
+
+config K8M890_VIDEO_MB_32MB
+ bool 32MB
+config K8M890_VIDEO_MB_64MB
+ bool 64MB
+config K8M890_VIDEO_MB_128MB
+ bool 128MB
+config K8M890_VIDEO_MB_256MB
+ bool 256MB
+config K8M890_VIDEO_MB_CMOS
+ bool Use CMOS option
+
+endchoice
+
+config VIDEO_MB
+ int
+ default 0 if K8M890_VIDEO_MB_OFF
+ default 32 if K8M890_VIDEO_MB_32MB
+ default 64 if K8M890_VIDEO_MB_64MB
+ default 128 if K8M890_VIDEO_MB_128MB
+ default 256 if K8M890_VIDEO_MB_256MB
+ default -1 if K8M890_VIDEO_MB_CMOS
+ depends on SOUTHBRIDGE_VIA_K8T890_VGA_EN
+
Index: src/southbridge/via/k8t890/k8t890_dram.c
===
--- src/southbridge/via/k8t890/k8t890_dram.c (revision 5169)
+++ src/southbridge/via/k8t890/k8t890_dram.c (working copy)
@@ -67,47 +67,44 @@
}
+#if CONFIG_GFXUMA
+extern uint64_t uma_memory_base, uma_memory_size;
+#endif
+
static void dram_enable_k8m890(struct device *dev)
{
- dram_enable(dev);
+#if CONFIG_GFXUMA
+ msr_t msr;
+ int ret;
+ unsigned int fbbits;
- /* enable VGA, so the bridges gets VGA_EN and resources are set */
- pci_write_config8(dev, 0xa1, 0x80);
-}
+ /* use CMOS */
+ if (CONFIG_VIDEO_MB == -1) {
+ ret = get_option(fbbits, videoram_size);
+ if (ret) {
+ printk_warning(Failed to get videoram size (error %d), using default.\n, ret);
+ fbbits = 5;
+ }
-static struct resource *resmax;
-
-static void get_memres(void *gp, struct device *dev, struct resource *res)
-{
- unsigned int *fbsize = (unsigned int *) gp;
- uint64_t proposed_base = res-base + res-size - *fbsize;
-
- printk_debug(get_memres: res-base=%llx res-size=%llx %d %d %d\n,
- res-base, res-size, (res-size *fbsize),
- (!(proposed_base (*fbsize - 1))),
- (proposed_base ((uint64_t) 0x)));
-
- /* if we fit and also align OK, and must be below 4GB */
- if ((res-size *fbsize) (!(proposed_base (*fbsize - 1)))
- (proposed_base ((uint64_t) 0x) )) {
- resmax = res;
+ if ((fbbits 1) || (fbbits 7)) {
+ printk_warning(Invalid videoram size (%d), using default.\n,
+ 4 fbbits);
+ fbbits = 5;
}
-#if CONFIG_WRITE_HIGH_TABLES==1
-/* in arch/i386/boot/tables.c */
-extern uint64_t high_tables_base, high_tables_size;
-
- if ((high_tables_base) ((high_tables_base proposed_base)
- (high_tables_base (res-base + res-size {
- high_tables_base = proposed_base - high_tables_size;
- printk_debug(Moving the high_tables_base pointer to
-new base %llx\n, high_tables_base);
+ uma_memory_size = 4 (fbbits + 20);
+ } else {
+ uma_memory_size = (CONFIG_VIDEO_MB 20);
}
+
+ msr = rdmsr(TOP_MEM);
+ uma_memory_base = msr.lo - uma_memory_size;
+ printk_info(K8M890: UMA base is %llx size is %d (MB)\n, uma_memory_base, uma_memory_size / 1024 / 1024);
+ /* enable VGA, so the bridges gets VGA_EN and resources are set */
+ pci_write_config8(dev, 0xa1, 0x80);
#endif
+ dram_enable(dev);
}
-/*
- *
- */
int
k8m890_host_fb_size_get(void)
{
@@ -125,57 +122,29 @@
static void dram_init_fb(struct device *dev)
{
+#if CONFIG_GFXUMA
/* Important bits:
* Enable the internal GFX bit 7 of reg 0xa1 plus in same reg:
* bits 6:4 X fbuffer size will be 2^(X+2) or 100 = 64MB, 101 = 128MB
* bits 3:0 BASE [31:28]
* reg 0xa0 bits 7:1 BASE [27:21] bit0 enable CPU access
*/
- u8 tmp;
- uint64_t proposed_base;
unsigned int fbbits = 0;
- unsigned int fbsize;
+ u8 tmp;
int ret;
+ fbbits = ((log2(uma_memory_size 20) - 2) 4);
+ printk_info(K8M890: Using a %dMB framebuffer.\n, (unsigned int) (uma_memory_size 20));
- ret = get_option(fbbits, videoram_size);
- if (ret) {
- printk_warning(Failed to get videoram size (error %d), using default.\n, ret);
- fbbits
Re: [coreboot] Hi...all
On Sat, Mar 06, 2010 at 01:12:51AM +0100, Carl-Daniel Hailfinger wrote: On 05.03.2010 19:26, ron minnich wrote: What would coreboot need to do to support IPMI BMC? Depends on the IPMI BMC. If you're lucky, it works out of the box, and if you're unlucky, you have to implement undocumented BIOS interfaces. The easiest solution is to buy a card and try it, and if it doesn't work, reverse engineer it or try another card. Besides that, IPMI is a security nightmare (see the discussions on the linux-kernel mailing list about IPMI bypassing host network security). Even worse - I have yet to encounter a reliable IPMI card. The sorts of problems I've encountered are: * specific packets can 'kill' the IPMI controller. Once the thing is hung, the only fix is a *cold* boot of the entire machine. * I've seen machines crash, taking the IPMI controller with them. Makes the whole thing kind of pointless... * general reliability issues. IPMI controllers also seem to like to hang themselves occasionally I really tried to make IPMI work reliably; I have an 80 machine cluster full of these things. I wasted a ton of time on them (3 different generations from 2 vendors - Tyan and Supermicro). I think that those issues were largely caused by extremely crappy proprietary firmware. But there is a more fundamental issue; the IPMI BMC is pretty tightly connected into the mainboard, by design. That's bad - how can you guarantee that IPMI BMC will always be available, fully out of band, when it is not 100% independent of the mainboard? In the end I gave up; I now use serial console servers (opengear is highly recommended) and switched PDUs (I've tried various brands, so far I like Raritan's Dominion series the best). That works, 100% of the time. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 14:45, Carl-Daniel Hailfinger wrote: On 06.03.2010 10:03, Jason Wang wrote: On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote: Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-) i am thinking who about making flashrom can be used under windows? I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet. To summarize: I don't think porting flashrom to Windows would be a good GSoC task. Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
Carl-Daniel Hailfinger wrote: I have no idea if our coding style allows usage of old compilers for DOS. Use a DOS extender and it should be fine. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task. Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS. Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reina...@coresystems.de wrote: On 06.03.2010, at 15:50, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task. Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS. Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS. YES! Flashrom as a coreboot payload would be truly awesome! -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi...all
So, if you're looking to buy 150 or so nodes, what's a reasonable coreboot-capable node *without* any sort of BMC/IPMI? I really need these IPMI-free boards and the vendors keep trying to shove this IPMI nonsense down our throats -- in spite of the fact that IPMI is such a failure. It's easy to see why, they get to charge a pretty nice premium for the presence of those BMCs. Coreboot would be a huge plus. A 45-second POST, in this day and age, is just simply ridiculous. Even were we to accept that 45-second post, the BIOS on this Nehalem new board is so defective that it's just unusuable for what we need -- it doesn't always come out of a reset. Ward, what's the latest thing you know of? thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 16:19, Joseph Smith wrote: On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reina...@coresystems.de wrote: On 06.03.2010, at 15:50, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task. Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS. Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS. YES! Flashrom as a coreboot payload would be truly awesome! Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.) Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer: 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though. Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-) Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5193 - trunk/src/cpu/intel/model_6xx
Author: uwe
Date: Sat Mar 6 17:19:11 2010
New Revision: 5193
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5193
Log:
Add support for the 0x06B1 CPU ID for Celeron (Tualatin).
Signed-off-by: Keith Hui buu...@gmail.com
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/src/cpu/intel/model_6xx/model_6xx_init.c
Modified: trunk/src/cpu/intel/model_6xx/model_6xx_init.c
==
--- trunk/src/cpu/intel/model_6xx/model_6xx_init.c Fri Mar 5 20:12:34
2010(r5192)
+++ trunk/src/cpu/intel/model_6xx/model_6xx_init.c Sat Mar 6 17:19:11
2010(r5193)
@@ -58,6 +58,7 @@
{ X86_VENDOR_INTEL, 0x06A1 },
{ X86_VENDOR_INTEL, 0x06A4 },
{ X86_VENDOR_INTEL, 0x06B0 }, /* Mobile Celeron FCBGA */
+ { X86_VENDOR_INTEL, 0x06B1 }, /* Celeron (Tualatin) */
{ X86_VENDOR_INTEL, 0x06B4 },
{ 0, 0 },
};
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 06.03.2010 16:19, Joseph Smith wrote: On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reina...@coresystems.de wrote: On 06.03.2010, at 15:50, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task. Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS. Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS. YES! Flashrom as a coreboot payload would be truly awesome! Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.) Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer: 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though. Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-) What about Variant 1 but with Kconfig options to choose only certain flash chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible :-) -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On Sat, 06 Mar 2010 11:22:06 -0500, Joseph Smith j...@settoplinux.org wrote: On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 06.03.2010 16:19, Joseph Smith wrote: On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reina...@coresystems.de wrote: On 06.03.2010, at 15:50, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: To summarize: I don't think porting flashrom to Windows would be a good GSoC task. Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS. Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS. YES! Flashrom as a coreboot payload would be truly awesome! Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.) Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer: 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though. Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-) What about Variant 1 but with Kconfig options to choose only certain flash chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible :-) Or like Stefan said, just make it part of FILO, that way it already has disk access to find the bios image to flash. -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
As a project, I'd still like to see someone try the serialice as bootblock and see how it goes. Let me explain. At the meeting in 2006, we decided it would be nice to have an all is lost mode wherein we'd flash a new image from the serial port. I still like this idea. I think serialice would be the foundation of this capability. If a given mainboard could be extended to include the basic commands for flashing, then we could experiment with this model. Coreboot would need to be modified, mainly to allow it to be loaded into lower-than-top-64k, but we do this already: it's called the normal build. I think all the bits are there, they just need assembly. This model would be *ideal* for me on the Dell cluster, even better than the old normal/fallback model. Not well defined, I realize, but I'd be happy to mentor someone who wanted to give this a try. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 3/6/10 5:13 PM, Carl-Daniel Hailfinger wrote: Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer: 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). Just having it as a FILO add-on would be the best solution. Then it can use all the FILO infrastructure (reading lots of filesystems, using a recovery with a nice menu on a USB stick, integrate with the flash protection that FILO offers (lock flash writes before FILO executes external code for example) Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though. I agree all those variants have some drawbacks... Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 18:12, ron minnich wrote: As a project, I'd still like to see someone try the serialice as bootblock and see how it goes. Let me explain. At the meeting in 2006, we decided it would be nice to have an all is lost mode wherein we'd flash a new image from the serial port. I still like this idea. I think serialice would be the foundation of this capability. If a given mainboard could be extended to include the basic commands for flashing, then we could experiment with this model. Coreboot would need to be modified, mainly to allow it to be loaded into lower-than-top-64k, but we do this already: it's called the normal build. I think all the bits are there, they just need assembly. This model would be *ideal* for me on the Dell cluster, even better than the old normal/fallback model. Not well defined, I realize, but I'd be happy to mentor someone who wanted to give this a try. Oh, I would definitely be interested (well, it is variant 2 of my proposal), but due to the hard requirements of flashing, the code either has to run from CAR or from RAM. Not only the stack, but also the code has to be outside flash. Why? Simple. During write or erase of any Parallel/LPC/FWH chip, all reads are guaranteed to return garbage (bit 6 and 7 are reserved for JEDEC completion detection on some chips, other chips simply return the status register instead of valid data). That means instruction fetch from ROM has to be avoided at all costs. SPI isn't much better, many datasheets mention that the results of reads during erase/write are undefined. Please note that this is not the fault of flashrom (no other flashing software would be able to cope either). There are three points in time where the all is lost code can be run in theory: 1. Without CAR or RAM. No reflashing possible (see above). 2. With CAR and without RAM. Works as long as the CPU can execute code from CAR and at the same time have either a stack in CAR (neat) or store a few bytes elsewhere (but it needs ROMCC for that). 3. With RAM. No limitations here. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 17:22, Joseph Smith wrote: On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 06.03.2010 16:19, Joseph Smith wrote: YES! Flashrom as a coreboot payload would be truly awesome! 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. What about Variant 1 but with Kconfig options to choose only certain flash chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible :-) While it would be cool, this needs a completely working coreboot including VGA init (how would you interact with the system otherwise), and if that works, you can usually run Linux anyway or at least load some code from disk or from the network (the place where the new image would live). So yes, would be a neat gimmick, but IMHO of limited value. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5194 - trunk/src/northbridge/intel/i440bx
Author: uwe Date: Sat Mar 6 19:16:25 2010 New Revision: 5194 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5194 Log: 440BX: Do not hardcode DIMM number + size anymore. The code currently assumes a 4-DIMM-slots board, this will be fixed soon. Signed-off-by: Keith Hui buu...@gmail.com Acked-by: Uwe Hermann u...@hermann-uwe.de Modified: trunk/src/northbridge/intel/i440bx/i440bx.h trunk/src/northbridge/intel/i440bx/raminit.c Modified: trunk/src/northbridge/intel/i440bx/i440bx.h == --- trunk/src/northbridge/intel/i440bx/i440bx.h Sat Mar 6 17:19:11 2010 (r5193) +++ trunk/src/northbridge/intel/i440bx/i440bx.h Sat Mar 6 19:16:25 2010 (r5194) @@ -32,11 +32,27 @@ * Any addresses between 0x00 and 0xff not listed below are either * Reserved or Intel Reserved and should not be touched. */ + #define NBXCFG 0x50 /* 440BX Configuration (0x:00S0__000S_0S00b). */ #define DRAMC 0x57 /* DRAM Control (00S0_b). */ #define DRAMT 0x58 /* DRAM Timing (0x03). */ #define PAM 0x59 /* Programmable Attribute Map, 7 registers (0x00). */ +#define PAM00x59 +#define PAM10x5a +#define PAM20x5b +#define PAM30x5c +#define PAM40x5d +#define PAM50x5e +#define PAM60x5f #define DRB 0x60 /* DRAM Row Boundary, 8 registers (0x01). */ +#define DRB00x60 +#define DRB10x61 +#define DRB20x62 +#define DRB30x63 +#define DRB40x64 +#define DRB50x65 +#define DRB60x66 +#define DRB70x67 #define FDHC0x68 /* Fixed SDRAM Hole Control (0x00). */ #define MBSC0x69 /* Memory Buffer Strength Control (0x--). */ #define SMRAM 0x72 /* System Management RAM Control (0x02). */ @@ -50,27 +66,24 @@ #define ERRCMD 0x90 /* Error Command Register (0x80). */ #define ERRSTS 0x91 /* Error Status (0x). */ // TODO: AGP stuff. +#define ACAPID 0xa0 /* AGP Capability Identifier (0x0012 or 0x) */ +#define AGPSTAT 0xa4 /* AGP Status Register (0x1f000203, read only) */ +#define AGPCMD 0xa8 /* AGP Command Register (0x) */ +#define AGPCTRL 0xb0 /* AGP Control Register (0x) */ +#define APSIZE 0xb4 /* Aperture Size Control Register (0x00) */ +#define ATTBASE 0xb8 /* Aperture Translation Table (0x) */ + #define MBFS0xca /* Memory Buffer Frequency Select (0x00). */ #define BSPAD 0xd0 /* BIOS Scratch Pad (0x000..000). */ +#define BSPAD0 0xd0 /* These are free for our use. */ +#define BSPAD1 0xd1 +#define BSPAD2 0xd2 +#define BSPAD3 0xd3 +#define BSPAD4 0xd4 +#define BSPAD5 0xd5 +#define BSPAD6 0xd6 +#define BSPAD7 0xd7 #define DWTC0xe0 /* DRAM Write Thermal Throttling Control (0x000..000). */ #define DRTC0xe8 /* DRAM Read Thermal Throttling Control (0x000..000). */ #define BUFFC 0xf0 /* Buffer Control Register (0x). */ -/* For convenience: */ -#define DRB00x60 -#define DRB10x61 -#define DRB20x62 -#define DRB30x63 -#define DRB40x64 -#define DRB50x65 -#define DRB60x66 -#define DRB70x67 - -#define PAM00x59 -#define PAM10x5a -#define PAM20x5b -#define PAM30x5c -#define PAM40x5d -#define PAM50x5e -#define PAM60x5f - Modified: trunk/src/northbridge/intel/i440bx/raminit.c == --- trunk/src/northbridge/intel/i440bx/raminit.cSat Mar 6 17:19:11 2010(r5193) +++ trunk/src/northbridge/intel/i440bx/raminit.cSat Mar 6 19:16:25 2010(r5194) @@ -2,6 +2,7 @@ * This file is part of the coreboot project. * * Copyright (C) 2007-2008 Uwe Hermann u...@hermann-uwe.de + * Copyright (C) 2010 Keith Hui buu...@gmail.com * * 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 @@ -23,6 +24,7 @@ #include delay.h #include stdlib.h #include i440bx.h +#include raminit.h /*- Macros and definitions. @@ -185,14 +187,23 @@ * 10 = Write Only (Writes to DRAM, reads to memory mapped I/O space) * 11 = Read/Write (all access goes to DRAM) */ - // TODO - PAM0, 0x00, 0x00, - PAM1, 0x00, 0x00, - PAM2, 0x00, 0x00, - PAM3, 0x00, 0x00, - PAM4, 0x00, 0x00, - PAM5, 0x00, 0x00, - PAM6, 0x00, 0x00, + + /* +* Map all legacy regions to RAM (read/write). This is required if +* you want to use the RAM area from 768 KB - 1 MB. If the PAM +* registers are not set here appropriately, the RAM in that region +* will not be accessible, thus a RAM check of it will also fail. +* +* TODO: This was set in sdram_set_spd_registers(). +* Test if it still works when set here. +*/ + PAM0, 0x00, 0x30, + PAM1, 0x00, 0x33, + PAM2, 0x00,
Re: [coreboot] GSoC 2010
On 06.03.2010 18:50, Stefan Reinauer wrote: On 3/6/10 5:13 PM, Carl-Daniel Hailfinger wrote: 1. Full flashrom with GUI as payload (may easily exceed 200 kB uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements). Just having it as a FILO add-on would be the best solution. Then it can use all the FILO infrastructure (reading lots of filesystems, using a recovery with a nice menu on a USB stick, OTOH, it could simply be an ELF loaded by FILO. That allows upgrades of flashrom as needed, and if FILO can load flash images from any media, it should be able to do the same with executable code. integrate with the flash protection that FILO offers (lock flash writes before FILO executes external code for example) Now that is indeed a compelling reason to have FILO support flashing. Then again, if flashrom-in-FILO doesn't check a cryptographic signature of the new flash image, the flash protection effect is rather limited. Anyway, I can do it if you let me do it. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs
Hi,
I think I reviewed and committed most of the stuff now, except for the
microcode updates, IIRC there will be some bigger patch handling those
in the near future anyway.
See some more notes below.
On Tue, Mar 02, 2010 at 11:19:24PM -0500, Keith Hui wrote:
- Adds Asus P2B-LS mainboard
Merged with some small cosmetic changes, thanks.
- Adds RAM detection for i440bx (based on i82830 code). We're no longer hard
coded for 64MB on one row!
Very nice! I did various smaller changes here, should be functionally
equivalent mostly though, except for these:
- In i440bx.h: I dropped the generic PCI register definitions, those
are not 440BX specific and already defined in pci_def.h.
- Dropped MLT / PCI_LATENCY_TIMER for now, should not be needed, and
raminit.c is probably the wrong place for this stuff anyway, I guess.
- Not sure about this change, omitted it for now (need to re-check
datasheets):
static const uint32_t refresh_rate_map[] = {
- 1, 5, 5, 2, 3, 4
+ 1, 1, 1, 2, 3, 4
};
Probably also some more stuff I forgot about. One thing I'd like to do
next is to factor out some stuff from set_dram_row_attributes(), that's
way too long and too nested for my taste.
- Adds a proper Slot 1 cpu under src/cpu/intel/slot_1. It's a stub copied
from slot_2 but addresses a few FIXMEs. My P2B-LS code refers to this.
Yep, thanks! I'll fixup the other slot 1 boards in a few minutes or so.
- Adds microcode for Intel Tualatin CPUs, cpuid 6B1 and 6B4.* Actually
loading them is pending.
Postponed for now, see above.
Will test the code on a few 440BX boards soonish, and fix the 3 vs. 4
DIMM slots issue.
Thanks, Uwe.
--
http://www.hermann-uwe.de | http://www.randomprojects.org
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
It would be nice, if a flashrom is in there, to also have some sort of security too I think. Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity. Is it even possible? The only thing I really trust is a jumper, but nobody seems to put those in any more. A pity. thanks ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs
This activity is really impressive. It got me to wondering: how old is the 440bx chipset? I know it's been around a while. It sure seems to live one ... ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 19:52, ron minnich wrote: It would be nice, if a flashrom is in there, to also have some sort of security too I think. Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity. Is it even possible? Well, I implemented signature checking for coreboot (so that only signed payloads would be executed). The big question is: Do you want to protect against 1. someone with full hardware access (developer), 2. someone sitting in front of the machine but without hardware access (computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware. Second category should be easily achieved by requiring a signed boot image for a non-lockdown boot. A default boot would be with locked down flash, and only a special kernel/payload/bootable-file-on-disk would be able to reflash. Needs chipset cooperation and/or one-shot GPIOs. Third category would allow the user to select an unlocked boot. Locked boot would be default, and the setting would not be stored anywhere to avoid circumvention. The only thing I really trust is a jumper, but nobody seems to put those in any more. A pity. At least one modern flash chip ignores the write protect pin for some erase commands. A jumper won't help here. Chipset lockdown can be circumvented as well. If you really want a rootkit-resistant protection, you need two flash chips and some additional circuitry. (I once worked as an infosec penetration tester, and it shows. I don't believe in magic, nor do I believe in correct operation of any chip under non-standard conditions.) Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] server hardware without IPMI / with coreboot
On Sat, Mar 06, 2010 at 08:03:40AM -0800, ron minnich wrote: So, if you're looking to buy 150 or so nodes, what's a reasonable coreboot-capable node *without* any sort of BMC/IPMI? I really need these IPMI-free boards and the vendors keep trying to shove this IPMI nonsense down our throats -- in spite of the fact that IPMI is such a failure. It's easy to see why, they get to charge a pretty nice premium for the presence of those BMCs. While the IPMI BMC is tightly integrated with the mainboard, it tends to be an optional module on Supermicro (and Tyan, I guess, I have not looked recently though) boards. So you can definitely order without the module. Coreboot would be a huge plus. A 45-second POST, in this day and age, is just simply ridiculous. Even were we to accept that 45-second post, the BIOS on this Nehalem new board is so defective that it's just unusuable for what we need -- it doesn't always come out of a reset. Ward, what's the latest thing you know of? I still like Opteron a lot. Here's the current list of Supermicro boards based on the latest SR56x0/SP5100 chipset: http://www.supermicro.com/Aplus/motherboard/Opteron2000/ I wonder if these boards will take the 8 and 12 core CPUs AMD is due to release at the end of this month. Silicon Mechanics has a few systems built on those boards, but so far only a 2U (nServ A346) and 3U (A362). They should be able to to tell you when they will have 1U systems (assuming that's what you are looking for here). There are also very nifty 'twin' systems (1U) and 2x2 twin systems (4 boards, hot swappable, in a 2U chassis with redundant power and 12 disk bays). Sadly, I've only seen the 2x2 with Intel boards, so far... My experience is that if you talk to a vendor like Silicon Mechanics or Aspen Systems and tell them you want to buy 150 systems, they will at least *try* to help with coreboot by talking to their suppliers. I guess the most important thing right now would be to get AMD to release docs (and code?) for the SR56x0/SP5100 chipset. With that, supporting any of the boards listed above might be possible. This chipset is likely to be around for a while (5 years?). Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 06.03.2010 19:52, ron minnich wrote: It would be nice, if a flashrom is in there, to also have some sort of security too I think. Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity. Is it even possible? Well, I implemented signature checking for coreboot (so that only signed payloads would be executed). The big question is: Do you want to protect against 1. someone with full hardware access (developer), 2. someone sitting in front of the machine but without hardware access (computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware. I agree completely. Second category should be easily achieved by requiring a signed boot image for a non-lockdown boot. A default boot would be with locked down flash, and only a special kernel/payload/bootable-file-on-disk would be able to reflash. Needs chipset cooperation and/or one-shot GPIOs. Third category would allow the user to select an unlocked boot. Locked boot would be default, and the setting would not be stored anywhere to avoid circumvention. 3 is the biggest concern. For me, anyway. (2) is close however. At least one modern flash chip ignores the write protect pin for some erase commands. A jumper won't help here. WHO designs this stuff? it would be nice to have a blacklist for such poor designs. Chipset lockdown can be circumvented as well. If you really want a rootkit-resistant protection, you need two flash chips and some additional circuitry. (I once worked as an infosec penetration tester, and it shows. I don't believe in magic, nor do I believe in correct operation of any chip under non-standard conditions.) I'm glad you're on OUR side :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] ASUS P2B-LS support, RAM detection for 440BX, add Slot 1 CPU, Microcode for Intel Tualatin CPUs
On Saturday 06 March 2010 20:01:11 ron minnich wrote: This activity is really impressive. It got me to wondering: how old is the 440bx chipset? it was released in april 1998 Christian -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi...all
On Fri, Mar 5, 2010 at 10:26 AM, ron minnich rminn...@gmail.com wrote: What would coreboot need to do to support IPMI BMC? need to use BT or KCS interface to tell FRU list esp for the devices there is side band access from BMC also may need to abitritry etc to make sure BMC and host don't access some devices at same time like GPIO, and i2c... YH -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Hi...all
On Sat, Mar 6, 2010 at 12:24 PM, yhlu yingha...@gmail.com wrote: On Fri, Mar 5, 2010 at 10:26 AM, ron minnich rminn...@gmail.com wrote: What would coreboot need to do to support IPMI BMC? need to use BT or KCS interface to tell FRU list esp for the devices there is side band access from BMC also may need to abitritry etc to make sure BMC and host don't access some devices at same time like GPIO, and i2c... ah. You just gave me another reason to never want a BMC on board :-) OK, good to know. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5195 - trunk
Author: oxygene Date: Sat Mar 6 22:18:43 2010 New Revision: 5195 URL: http://tracker.coreboot.org/trac/coreboot/changeset/5195 Log: More readable recursive descent macro in Makefile Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/Makefile Modified: trunk/Makefile == --- trunk/Makefile Sat Mar 6 19:16:25 2010(r5194) +++ trunk/Makefile Sat Mar 6 22:18:43 2010(r5195) @@ -119,8 +119,32 @@ crt0s:= ldscripts:= types:=obj initobj driver smmobj -includemakefiles=$(foreach type,$(2), $(eval $(type)-y:=)) $(eval subdirs-y:=) $(eval -include $(1)) $(if $(strip $(3)),$(foreach type,$(2),$(eval $(type)s+=$$(patsubst util/%,$(obj)/util/%,$$(patsubst src/%,$(obj)/%,$$(addprefix $(dir $(1)),$$($(type)-y))) $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y) -evaluate_subdirs=$(eval cursubdirs:=$(subdirs)) $(eval subdirs:=) $(foreach dir,$(cursubdirs),$(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1 $(if $(subdirs),$(eval $(call evaluate_subdirs, $(1 + +# Clean -y variables, include Makefile.inc +# If $(3) is non-empty, add paths to files in X-y, and add them to Xs +# Add subdirs-y to subdirs +includemakefiles= \ + $(foreach type,$(2), $(eval $(type)-y:=)) \ + $(eval subdirs-y:=) \ + $(eval -include $(1)) \ + $(if $(strip $(3)), \ + $(foreach type,$(2), \ + $(eval $(type)s+= \ + $$(patsubst util/%, \ + $(obj)/util/%, \ + $$(patsubst src/%, \ + $(obj)/%, \ + $$(addprefix $(dir $(1)),$$($(type)-y))) \ + $(eval subdirs+=$$(subst $(PWD)/,,$$(abspath $$(addprefix $(dir $(1)),$$(subdirs-y) + +# For each path in $(subdirs) call includemakefiles, passing $(1) as $(3) +# Repeat until subdirs is empty +evaluate_subdirs= \ + $(eval cursubdirs:=$(subdirs)) \ + $(eval subdirs:=) \ + $(foreach dir,$(cursubdirs), \ + $(eval $(call includemakefiles,$(dir)/Makefile.inc,$(types),$(1 \ + $(if $(subdirs),$(eval $(call evaluate_subdirs, $(1 # collect all object files eligible for building subdirs:=$(PLATFORM-y) $(BUILD-y) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not what I meant. AFAIK DJGPP is based on gcc 2.72, and that may not support the C99 features flashrom is using. Well then compile with libpayload and write simple DOS wrapper to load it ;) Rudolf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuS23oACgkQ3J9wPJqZRNUhQwCg3XOzh4VT5dRdgEuPWvRELhzU qYoAoKW7o86UtVV/b7UQJEu3GKh5l3Zp =UCy5 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 3/6/10 8:28 PM, Carl-Daniel Hailfinger wrote: On 06.03.2010 19:52, ron minnich wrote: It would be nice, if a flashrom is in there, to also have some sort of security too I think. Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity. Is it even possible? Well, I implemented signature checking for coreboot (so that only signed payloads would be executed). When coresystems developed our first version of hard crypto signature checking for firmware in 2007/2008 we explicitly decided to not check the payload but only let the payload check further stages. The reason was that if you're able to compromise the flash chip, you're able to reprogram coreboot just as well as the payload. Also, we didn't want feel comfortable to duplicate the amount of crypto code in the flash, and there is no serious mechanism around that protects only the bootblock, at least not on commonly used systems. So I'm interested to hear your reasons to do this in coreboot itself... Is your code publically available somewhere? Regards, Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 3/6/10 9:17 PM, ron minnich wrote: On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 06.03.2010 19:52, ron minnich wrote: It would be nice, if a flashrom is in there, to also have some sort of security too I think. Something that is not as easily compromised as the stuff that's out there now, which relies on security through obscurity. Is it even possible? Well, I implemented signature checking for coreboot (so that only signed payloads would be executed). The big question is: Do you want to protect against 1. someone with full hardware access (developer), 2. someone sitting in front of the machine but without hardware access (computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware. I agree completely. Also, the question is what kind of privilege escalation can be caused by a security breach. While you can always solder a new flash chip on an x86 system these days you can still encrypt your data in order to protect (read) access. 3 is the biggest concern. For me, anyway. (2) is close however. Someone sitting in front of the machine usually does have hardware access, so the differentiation is kind of artificial unless you count the people forgetting to bring soldering irons and screw drivers. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 07.03.2010 00:02, Stefan Reinauer wrote: On 3/6/10 9:17 PM, ron minnich wrote: On Sat, Mar 6, 2010 at 11:28 AM, Carl-Daniel Hailfinger wrote: Well, I implemented signature checking for coreboot (so that only signed payloads would be executed). The big question is: Do you want to protect against 1. someone with full hardware access (developer), 2. someone sitting in front of the machine but without hardware access (computer pool), 3. against evil malware (including rootkits)? I'd say the first category is pointless with current x86 hardware. I agree completely. Also, the question is what kind of privilege escalation can be caused by a security breach. While you can always solder a new flash chip on an x86 system these days you can still encrypt your data in order to protect (read) access. It depends on the security model. If you store the encryption key in the ROM, people can read it out if they have hardware access. If there are protections in place against such readout, there is still the chance to rig something with the help of SerialICE. 3 is the biggest concern. For me, anyway. (2) is close however. Someone sitting in front of the machine usually does have hardware access, so the differentiation is kind of artificial unless you count the people forgetting to bring soldering irons and screw drivers. I hope someone questions/stops you if you decide to bring screwdrivers and a soldering iron to a shared student computer room and start taking apart one of the machines. Then again, doing this is basic social engineering, and if you are bold enough and ask loudly in that computer room for someone to assist you, most people will think the operation is entirely legit. In the end, what we need is a detailed security model which includes a good understanding of the threat we want to protect against. Doing many security things is not a fix for anything, but a hand-tailored solution has the chance of addressing one given problem. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
On 06.03.2010 23:47, Rudolf Marek wrote: Not what I meant. AFAIK DJGPP is based on gcc 2.72, and that may not support the C99 features flashrom is using. Well then compile with libpayload and write simple DOS wrapper to load it ;) Brilliant idea. Not exactly what I had in mind, but certainly an option. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
[followup to flash...@flashrom.org please] On 06.03.2010 22:07, Darmawan Salihun wrote: On 3/6/10, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 06.03.2010 10:03, Jason Wang wrote: On Sat, Mar 6, 2010 at 4:29 PM, Darmawan Salihun wrote: Flashrom used to have Windows port that I worked on back in 2007 (Winflashrom). I'm willing to help if any student want to port to Windows 7. I'm not a student anymore ;-) i am thinking who about making flashrom can be used under windows? I think Stefan Reinauer already ported flashrom to Windows 7, AFAIK somewhat based on the original Windows port. Look here: http://www.coreboot.org/pipermail/flashrom/2009-August/000239.html . Darmawan, it would be cool if you could look at this as well. flashrom now has a lot better abstraction than back when you did the original Windows port, and merging Stefan's patch should be possible. It's been a while, but I think DirectIO for Windows hasn't been released yet. OK. Looking into it now ;-). I'm not well versed with Windows 7 driver model yet. I'm gonna need to working on it nonetheless, for my book. I'll let you guys know. Cool, thanks. Regards, Carl-Daniel -- I do consider assignment statements and pointer variables to be among computer science's most valuable treasures. -- Donald E. Knuth -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC 2010
Hi, I updated http://www.coreboot.org/GSoC with my project ideas and some basic information. Please update the wiki with your own ideas and fix the stuff I forgot. Thank you. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
