coreboot June 2009

coreboot@coreboot.org

84 participants
500 discussions

[v2] r4370 - trunk/coreboot-v2/util/cbfstool
by svn＠coreboot.org 25 Jun '09

25 Jun '09

Author: myles Date: 2009-06-25 17:54:57 +0200 (Thu, 25 Jun 2009) New Revision: 4370 Modified: trunk/coreboot-v2/util/cbfstool/fs.c Log: The problem is that the check to see if we're at the end is never reached. I didn't look into it enough to know why fssize is 32 bytes larger than the offset. There may be another bug here. Maybe something with the CBFS header not being included or excluded from the calculation? Anyway, this patch fixes it for all cases size > 32. I also changed the error message so that it doesn't look like the ROM is full just because it can't find room for a file. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: trunk/coreboot-v2/util/cbfstool/fs.c =================================================================== --- trunk/coreboot-v2/util/cbfstool/fs.c 2009-06-24 00:35:07 UTC (rev 4369) +++ trunk/coreboot-v2/util/cbfstool/fs.c 2009-06-25 15:54:57 UTC (rev 4370) @@ -227,7 +227,7 @@ unsigned long nextoffset, truncoffset; struct cbfs_file *newfile = NULL; - while (offset < rom->fssize) { + while ((offset + size) < rom->fssize) { c = (struct cbfs_file *)ROM_PTR(rom, offset); @@ -406,7 +406,7 @@ c = rom_alloc(rom, name, size, type); if (c == NULL) { - ERROR("There is no more room in this ROM\n"); + ERROR("There is not enough room in this ROM\n"); return -1; }

1 0

Anyone know how to use emulation-qemu-x86.rom
by Rick Ant 25 Jun '09

25 Jun '09

Anyone know how to use emulation-qemu-x86.rom ron minnich send me one... Thanks

2 1

Re: [coreboot] I've got this message...
by Rick Ant 25 Jun '09

25 Jun '09

tell me how to use it? My system configuration is Intel PIII 82810 Northbridge and 82801 Southbridge 128 Mb Ram and 49LF004 Flash ROM I want to embed coreboot and Linux into 49LF004, so it will become thin client which will connect to the server... My development configuration is VIA Ester 1.8GHz, 512 Mb..witch Suse 10.1 on it Thanks --- On Wed, 6/24/09, ron minnich <rminnich(a)gmail.com> wrote: From: ron minnich <rminnich(a)gmail.com> Subject: Re: [coreboot] I've got this message... To: "Rick Ant" <rick_077(a)yahoo.com> Cc: coreboot(a)coreboot.org Date: Wednesday, June 24, 2009, 10:39 PM The qemu one is broken. I will send you a working one off-list. ron

3 2

which mainboard is the best reference for s3
by JasonZhao＠viatech.com.cn 25 Jun '09

25 Jun '09

Hi Rudolf , I want to update my vx855 code using the newest version of coreboot-v2, to take advantage of new functions(such as smi,AML-auto-generator) that appear on coreboot in the last months. And, since I also want to use as much of coreboot's existing code as possible(and to maintain a source that is not on coreboot's svn as easy as possible...), I wonder which mainboard is the best reference for S3 function for now? It seems that amdk8 now has good support of S3, but I didn't found S3 code on asus/m2v-mx_se. Many thanks. -jasonzhao

2 1

Corrupt rom -- found no header at 458720
by Rick Ant 25 Jun '09

25 Jun '09

I try to use $ mkelfImage --append="console=ttyS0" --initrd=initrd vmlinuz linux.elf When : telebit:~/Project/Kantor/Thin_client/coreboot-v2-4360/targets # ./buildtarget emulation/qemu-x86/Config.lb and do make.. I get coreboot.rom on 512Kbyte My initrd is 1Mbyte and vmlinuz 16Mbyte..is it ok? The make result is situated below... Is it ok ? if I want to change the chipset, what should i do? My chipset is 82810 North and 82801 South.. ==== ....................... Payload: 0 coreboot: 65536 ROM size: 65536 Left space: 0 if [ 0 -eq 1 -a 1 -eq 1 ]; then echo l > cbfs-support; fi make[1]: Leaving directory `/root/Project/Kantor/Thin_client/coreboot-v2-4360/targets/emulation/qemu-x86/qemu-x86/normal' rm -f ./coreboot.rom cat normal/coreboot.rom > ./coreboot.rom.bootblock ./cbfstool ./coreboot.rom create 524288 65536 ./coreboot.rom.bootblock ./cbfstool ./coreboot.rom add-payload /root/Project/Kantor/mkelfImage-2.7/linux.elf normal/payload Corrupt rom -- found no header at 458720 make: *** [coreboot.rom] Error 1 telebit:~/Project/Kantor/Thin_client/coreboot-v2-4360/targets/emulation/qemu-x86/qemu-x86 #

4 3

Current version of buildrom works
by Gregg C Levine 25 Jun '09

25 Jun '09

Hello! I just used buildrom to create a Qemu image for trying out the coreinfo payload. It worked perfectly with the prebuilt and unpatched version of Qemu that I collected from a repository for my distribution of Linux. I would hazard a guess that I can now use buildrom to create my images for an appropriate board, which presupposes that the board name (to be named later) is a known working one with Coreboot. -- Gregg C Levine hansolofalcon(a)worldnet.att.net "The Force will be with you always." Obi-Wan Kenobi

2 1

flashrom licensing
by Carl-Daniel Hailfinger 25 Jun '09

25 Jun '09

Hi, I wanted to add support for the TotalPhase Cheetah to flashrom, but I have to use the proprietary driver library for that. I'm not aware of any free alternative to that driver, so there may be a conflict with the GPL. If the Cheetah driver library is considered to be a system library, the GPL allows linking against that library. If the Cheetah driver library is not considered to be a system library, I need to add an exception for that library to my Cheetah external flasher driver. However, since my driver would be part of flashrom, I have no idea if I would have to get permission from all flashrom authors for that exception. The GPL FAQ of the FSF mentions that simply adding a free software wrapper above the proprietary library is not sufficient, but having process separation (calling another program via the command line) would be OK. Since external flasher drivers have to maintain state, this essentially means I'd have to add shared memory or socket trickery, resulting in slow, buggy and unreadable code. One of the possible solutions would be to say that driver libraries for external hardware which are already installed before installing flashrom are considered to be system libraries. (The problem is that the Cheetah driver library has internally conflicting licenses, some of which suggest linking GPL code against it is not allowed. I (or maybe someone with more leverage) will try to address this with TotalPhase.) Regards, Carl-Daniel

4 6

[PATCH] flashrom: use verify_range in write_page_write_jedec
by Urja Rannikko 25 Jun '09

25 Jun '09

Change chip_readb in loop to use verify_range in write_page_write_jedec (jedec.c). Signed-off-by: Urja Rannikko <urjaman(a)gmail.com> --- patch inlined: Index: jedec.c =================================================================== --- jedec.c (revision 595) +++ jedec.c (working copy) @@ -262,8 +262,8 @@ return 0; } -int write_page_write_jedec(chipaddr bios, uint8_t *src, - chipaddr dst, int page_size) +int write_page_write_jedec(struct flashchip *flash, chipaddr bios, + uint8_t *src, chipaddr dst, int page_size) { int i, tried = 0, start_index = 0, ok; chipaddr d = dst; @@ -288,15 +288,7 @@ dst = d; src = s; - ok = 1; - for (i = 0; i < page_size; i++) { - if (chip_readb(dst) != *src) { - ok = 0; - break; - } - dst++; - src++; - } + ok = !verify_range(flash,src,dst,page_size,NULL); if (!ok && tried++ < MAX_REFLASH_TRIES) { start_index = i; @@ -367,7 +359,7 @@ printf("Programming page: "); for (i = 0; i < total_size / page_size; i++) { printf("%04d at address: 0x%08x", i, i * page_size); - write_page_write_jedec(bios, buf + i * page_size, + write_page_write_jedec(flash, bios, buf + i * page_size, bios + i * page_size, page_size); printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); } -- urjaman

2 3

[flashrom] r632 - trunk
by svn＠coreboot.org 25 Jun '09

25 Jun '09

Author: hailfinger Date: 2009-06-25 15:57:31 +0200 (Thu, 25 Jun 2009) New Revision: 632 Modified: trunk/jedec.c Log: Change chip_readb in loop to use verify_range in write_page_write_jedec (jedec.c). Tested by Urja Rannikko with external flasher. Tested by Uwe Hermann with onboard flash. Signed-off-by: Urja Rannikko <urjaman(a)gmail.com> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Urja Rannikko <urjaman(a)gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/jedec.c =================================================================== --- trunk/jedec.c 2009-06-24 17:31:08 UTC (rev 631) +++ trunk/jedec.c 2009-06-25 13:57:31 UTC (rev 632) @@ -262,12 +262,14 @@ return 0; } -int write_page_write_jedec(chipaddr bios, uint8_t *src, - chipaddr dst, int page_size) +int write_page_write_jedec(struct flashchip *flash, uint8_t *src, + int start, int page_size) { int i, tried = 0, start_index = 0, ok; - chipaddr d = dst; uint8_t *s = src; + chipaddr bios = flash->virtual_memory; + chipaddr dst = bios + start; + chipaddr d = dst; retry: /* Issue JEDEC Data Unprotect comand */ @@ -288,15 +290,7 @@ dst = d; src = s; - ok = 1; - for (i = 0; i < page_size; i++) { - if (chip_readb(dst) != *src) { - ok = 0; - break; - } - dst++; - src++; - } + ok = !verify_range(flash, src, start, page_size, NULL); if (!ok && tried++ < MAX_REFLASH_TRIES) { start_index = i; @@ -367,8 +361,8 @@ printf("Programming page: "); for (i = 0; i < total_size / page_size; i++) { printf("%04d at address: 0x%08x", i, i * page_size); - write_page_write_jedec(bios, buf + i * page_size, - bios + i * page_size, page_size); + write_page_write_jedec(flash, buf + i * page_size, + i * page_size, page_size); printf("\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b"); } printf("\n");

1 0

EP80579 Mainboard support
by Arnaud Maye 25 Jun '09

25 Jun '09

Hello Everyone, We are designing a mainboard powered by an EP80579 and I came across coreboot. I've seen corebot v2 supports the Truxton EP80579 Development kit. However I cannot get any relevant information about Truxton. Is this the "official" intel development kit (EP80579TRXDK) or something else? I wanted to order the exact board coreboot supports and use this as a reference design. Could the people in charge of maintaining the EP80579 modules get back to me with this information? The initial stage would be to have Windows/Linux running on our board followed by VxWorks. Anyone around here as already used coreboot to "boot" a Vxworks system? Thank you! Arnaud Maye Embedded Systems Manager. www.4dsp.com * ** *

5 15

← Newer
1
...
10
11
12
13
14
15
16
...
50
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 June 2009