coreboot April 2009

coreboot@coreboot.org

69 participants
583 discussions

[PATCH]romfs: change the mechanism that builds the romtool utility
by Patrick Georgi 04 Apr '09

04 Apr '09

Hi, right now, we still have one victim to the romfs change in the build test, the first board in the list. Concurrent build, absolute paths and make's inability to combine these two unusual traits of a makefile come into play. The following patch fixes that, and creates a romtool per-build (even though that should not be necessary). Whitespace might be off, I can do a commit tomorrow, if I get an ack. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Index: util/newconfig/config.g =================================================================== --- util/newconfig/config.g (Revision 4059) +++ util/newconfig/config.g (Arbeitskopie) @@ -2225,13 +2225,15 @@ writemakefileheader(file, makefilepath) # main rule - file.write("\nall: romtool") + file.write("\nall: ") for i in buildroms: file.write(" %sfs" % i.name) file.write("\n\n") # romtool rules - file.write("\nromtool:\n\tcd $(TOP)/util/romtool; make\n") + file.write("\nromtool:\n\t$(MAKE) -C $(TOP)/util/romtool clean all\n\tmkdir -p tools\n") + file.write("\tcp $(TOP)/util/romtool/tools/rom-mkpayload $(TOP)/util/romtool/tools/rom-mkstage tools\n\tcp $(TOP)/util/romtool/romtool romtool\n") + file.write("\t$(MAKE) -C $(TOP)/util/romtool clean\n") file.write("include Makefile.settings\n\n") for i, o in romimages.items(): @@ -2268,15 +2270,15 @@ romsize = getoption("ROM_SIZE", image) # i.name? That can not be right, can it? - file.write("%sfs: %s $(TOP)/util/romtool/romtool\n" %(i.name,i.name)); + file.write("%sfs: %s romtool\n" %(i.name,i.name)); file.write("\trm -f coreboot.romfs\n"); - file.write("\t$(TOP)/util/romtool/romtool %sfs create %s %s %s.bootblock\n" % (i.name, romsize, bootblocksize, i.name)) + file.write("\t./romtool %sfs create %s %s %s.bootblock\n" % (i.name, romsize, bootblocksize, i.name)) for i in buildroms: for j in i.roms: #failover is a hack that will go away soon. if (j != "failover") and (rommapping[j] != "/dev/null"): - file.write("\tif [ -f %s/romfs-support ]; then $(TOP)/util/romtool/romtool %sfs add-payload %s %s/payload `cat %s/romfs-support`; fi\n" % (j, i.name, rommapping[j], j, j)) - file.write("\t $(TOP)/util/romtool/romtool %sfs print\n" % i.name) + file.write("\tif [ -f %s/romfs-support ]; then ./romtool %sfs add-payload %s %s/payload `cat %s/romfs-support`; fi\n" % (j, i.name, rommapping[j], j, j)) + file.write("\t ./romtool %sfs print\n" % i.name) file.write(".PHONY: all clean romtool") for i in romimages.keys():

5 9

Quick questions on the mtrr setup code
by Corey Osgood 04 Apr '09

04 Apr '09

I'm poking around mtrr.c (v2 and v3 are almost identical, but I'm looking at v3), and I'm trying to understand set_var_mtrr_resource(). It looks to me like the code is setting up the mtrrs for the var_mtrr_state struct, then setting var_mtrr_state struct to equal the values passed by the resource struct, so it's always one base/size behind. This then has to be corrected for in x86_setup_var_mtrrs(), which writes the last mtrr. It would make more sense to me for var_mtrr_state to be the state of the mtrrs AFTER the function runs, and for the function to be setting up the mtrrs for the resource it was just passed. It would also make the code to automagically figure out if it's better to use additive or subtractive mtrrs marginally simpler to write. Is there any reason for it to work this way, or was it just pulled from kernel source that way? Also, does anyone know of any CPUs or situations where a subtractive MTRR setup would break things? Thanks, Corey

2 1

Name change for romfs
by Peter Stuge 04 Apr '09

04 Apr '09

Is someone owning this issue? If not, will anything else happen with the code this weekend? Thanks //Peter

5 4

build service results for r4060
by coreboot information 04 Apr '09

04 Apr '09

Dear coreboot readers! This is the automatic build system of coreboot. The developer "rminnich" checked in revision 4060 to the coreboot repository. This caused the following changes: Change Log: These are some cleanups and changes. These are build and boot tested on qemu. Some changes for option roms: - don't make users pick the name. Names for option roms are in the v3-defined format of pci%04x,%04x.rom with the vendor and device id filling in the %04x. - users pass in vendor and device id. - users pass in a dest. If the dest is 0, the address of the ROM image in FLASH is returned. If the address is non-zero, then the decmpressor is called, and it will make sure the ROM image is copied to the destination (even in the uncompressed case). And some type and print cleanup. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Myles Watson <mylesgw(a)gmail.com> Build Log: Compilation of a-trend:atc-6220 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4060&device=atc-6220&vendo… Configuration of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4060&device=ep405pc&vendor… Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4060&device=sandpointx3_al… Configuration of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4060&device=briq&vendor=to… If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

changes to romfs for expansion rom loading
by ron minnich 04 Apr '09

04 Apr '09

attached. ron

2 2

[v2] r4060 - in trunk/coreboot-v2/src: include lib
by svn＠coreboot.org 04 Apr '09

04 Apr '09

Author: rminnich Date: 2009-04-04 00:23:34 +0200 (Sat, 04 Apr 2009) New Revision: 4060 Modified: trunk/coreboot-v2/src/include/romfs.h trunk/coreboot-v2/src/lib/romfs.c Log: These are some cleanups and changes. These are build and boot tested on qemu. Some changes for option roms: - don't make users pick the name. Names for option roms are in the v3-defined format of pci%04x,%04x.rom with the vendor and device id filling in the %04x. - users pass in vendor and device id. - users pass in a dest. If the dest is 0, the address of the ROM image in FLASH is returned. If the address is non-zero, then the decmpressor is called, and it will make sure the ROM image is copied to the destination (even in the uncompressed case). And some type and print cleanup. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Myles Watson <mylesgw(a)gmail.com> Modified: trunk/coreboot-v2/src/include/romfs.h =================================================================== --- trunk/coreboot-v2/src/include/romfs.h 2009-04-03 20:14:59 UTC (rev 4059) +++ trunk/coreboot-v2/src/include/romfs.h 2009-04-03 22:23:34 UTC (rev 4060) @@ -162,8 +162,7 @@ void * romfs_load_stage(const char *name); int romfs_execute_stage(const char *name); void * romfs_get_file(const char *name); -int romfs_load_optionrom(const char *name, u32 dest); - +void *romfs_load_optionrom(u16 vendor, u16 device, void * dest); int run_address(void *f); #endif Modified: trunk/coreboot-v2/src/lib/romfs.c =================================================================== --- trunk/coreboot-v2/src/lib/romfs.c 2009-04-03 20:14:59 UTC (rev 4059) +++ trunk/coreboot-v2/src/lib/romfs.c 2009-04-03 22:23:34 UTC (rev 4060) @@ -73,7 +73,7 @@ { struct romfs_header *header; - unsigned long ptr = *((unsigned long *) ROMFS_HEADPTR_ADDR); + void *ptr = (void *)*((unsigned long *) ROMFS_HEADPTR_ADDR); printk_debug("Check ROMFS header at %p\n", ptr); header = (struct romfs_header *) ptr; @@ -130,22 +130,39 @@ return (void *) ROMFS_SUBHEADER(file); } -int romfs_load_optionrom(const char *name, u32 dest) +void *romfs_load_optionrom(u16 vendor, u16 device, void * dest) { - struct romfs_optionrom *orom = (struct romfs_optionrom *) + char name[17]; + struct romfs_optionrom *orom; + u8 *src; + + sprintf(name,"pci%04x,%04x.rom", vendor, device); + + orom = (struct romfs_optionrom *) romfs_find_file(name, ROMFS_TYPE_OPTIONROM); if (orom == NULL) - return -1; + return NULL; + /* They might have specified a dest address. If so, we can decompress. + * If not, there's not much hope of decompressing or relocating the rom. + * in the common case, the expansion rom is uncompressed, we + * pass 0 in for the dest, and all we have to do is find the rom and + * return a pointer to it. + */ + + src = ((unsigned char *) orom) + sizeof(struct romfs_optionrom); + + if (! dest) + return src; + if (romfs_decompress(ntohl(orom->compression), - ((unsigned char *) orom) + - sizeof(struct romfs_optionrom), - (void *) dest, + src, + dest, ntohl(orom->len))) - return -1; + return NULL; - return 0; + return dest; } void * romfs_load_payload(struct lb_memory *lb_mem, const char *name)

1 0

build service results for r4059
by coreboot information 03 Apr '09

03 Apr '09

Dear coreboot readers! This is the automatic build system of coreboot. The developer "oxygene" checked in revision 4059 to the coreboot repository. This caused the following changes: Change Log: Add u64 typedef to ppc (trivial) Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Build Log: Compilation of a-trend:atc-6220 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4059&device=atc-6220&vendo… Configuration of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4059&device=ep405pc&vendor… Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4059&device=sandpointx3_al… Configuration of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4059&device=briq&vendor=to… If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

[v2] r4059 - trunk/coreboot-v2/src/arch/ppc/include
by svn＠coreboot.org 03 Apr '09

03 Apr '09

Author: oxygene Date: 2009-04-03 22:14:59 +0200 (Fri, 03 Apr 2009) New Revision: 4059 Modified: trunk/coreboot-v2/src/arch/ppc/include/stdint.h Log: Add u64 typedef to ppc (trivial) Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Modified: trunk/coreboot-v2/src/arch/ppc/include/stdint.h =================================================================== --- trunk/coreboot-v2/src/arch/ppc/include/stdint.h 2009-04-03 16:40:44 UTC (rev 4058) +++ trunk/coreboot-v2/src/arch/ppc/include/stdint.h 2009-04-03 20:14:59 UTC (rev 4059) @@ -51,5 +51,6 @@ typedef uint8_t u8; typedef uint16_t u16; typedef uint32_t u32; +typedef uint64_t u64; #endif /* PPC_STDINT_H */

1 0

build service results for r4058
by coreboot information 03 Apr '09

03 Apr '09

Dear coreboot readers! This is the automatic build system of coreboot. The developer "hailfinger" checked in revision 4058 to the coreboot repository. This caused the following changes: Change Log: Fix up the incomplete commit in r4055. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Build Log: Compilation of a-trend:atc-6220 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4058&device=atc-6220&vendo… Configuration of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4058&device=ep405pc&vendor… Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4058&device=sandpointx3_al… Configuration of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4058&device=briq&vendor=to… If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

build service results for r4057
by coreboot information 03 Apr '09

03 Apr '09

Dear coreboot readers! This is the automatic build system of coreboot. The developer "stepan" checked in revision 4057 to the coreboot repository. This caused the following changes: Change Log: drop unused variables in generic smm handler. (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Compilation of a-trend:atc-6220 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4057&device=atc-6220&vendo… Configuration of embeddedplanet:ep405pc is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4057&device=ep405pc&vendor… Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4057&device=sandpointx3_al… Configuration of totalimpact:briq is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4057&device=briq&vendor=to… If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

← Newer
1
...
50
51
52
53
54
55
56
...
59
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2009