coreboot November 2006

coreboot@coreboot.org

61 participants
260 discussions

[LinuxBIOS] r2502 build service
by LinuxBIOS information 22 Nov '06

22 Nov '06

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2502 to the LinuxBIOS source repository and caused the following changes: Change Log: Rename SM_ID to SYNCMOS_ID (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of iwill:dk8_htx is still broken Compilation of msi:ms9185 is still broken If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system

1 0

[LinuxBIOS] r2501 build service
by LinuxBIOS information 22 Nov '06

22 Nov '06

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2501 to the LinuxBIOS source repository and caused the following changes: Change Log: Add support for the SyncMOS S29C51001T, S29C51004T, and S29C31004T flash chips to flashrom (closes: #50). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Build Log: Compilation of iwill:dk8_htx is still broken Compilation of msi:ms9185 is still broken If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system

1 0

[LinuxBIOS] digitallogic/adl855pc will not link
by Jon Dufresne 22 Nov '06

22 Nov '06

When I try to make the digitallogic/adl855pc target I receive an error with the following message. /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom [fffd632e -> fffe1d7f] /usr/bin/ld: section .id [fffdffce -> fffdffef] overlaps section .rom [fffd632e -> fffe1d7f] /usr/bin/ld: linuxbios: section .id lma 0xfffdffce overlaps previous sections /usr/bin/ld: linuxbios: section .text lma 0xfffdfff0 overlaps previous sections /usr/bin/ld: linuxbios: section .data lma 0xfffdfff0 overlaps previous sections /usr/bin/ld: linuxbios: section .reset lma 0xfffdfff0 overlaps previous sectionscollect2: ld returned 1 exit status make[1]: *** [linuxbios] Error 1 make[1]: Leaving directory `/root/temp/LinuxBIOSv2/targets/digitallogic/adl855pc/adl855pc/normal' make: *** [normal/linuxbios.rom] Error 1 When I use abuild it says that it builds fine. Any idea why I can't get this to link using make? Also, is the linuxbios.rom file in the abuild directory good? Or do you suspect that it has the same linking error I get when I use make. Thanks, Jon

7 13

[LinuxBIOS] r2500 build service
by LinuxBIOS information 22 Nov '06

22 Nov '06

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2500 to the LinuxBIOS source repository and caused the following changes: Change Log: Cosmetic fixes and typos (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of iwill:dk8_htx is still broken Compilation of msi:ms9185 is still broken If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system

1 0

[LinuxBIOS] r2499 build service
by LinuxBIOS information 22 Nov '06

22 Nov '06

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2499 to the LinuxBIOS source repository and caused the following changes: Change Log: Support for the 256K SyncMos S29C51002T flash. Signed-off-by: Giampiero Giancipoli <gianci(a)email.it> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of iwill:dk8_htx is still broken Compilation of msi:ms9185 is still broken If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system

1 0

[LinuxBIOS] r2505 - trunk/LinuxBIOSv2/util/flashrom
by svn＠openbios.org 22 Nov '06

22 Nov '06

Author: stepan Date: 2006-11-22 01:29:51 +0100 (Wed, 22 Nov 2006) New Revision: 2505 Modified: trunk/LinuxBIOSv2/util/flashrom/Makefile trunk/LinuxBIOSv2/util/flashrom/jedec.c Log: apply patch from Giampiero Giancipoli <gianci(a)email.it>: Fixed write_page_write_jedec() in jedec.c. Added a check-reprogram loop in the same function, to come around the high page write failure rate on some boards. This patch includes the changes suggested by Ron to simplify the control flow. It also includes trivial changes by me to make flashrom build on newer systems (libpci needs libz now). I also made a small type case compile fix and proper return code handling in one or two places. Signed-off-by: Giampiero Giancipoli <gianci(a)email.it> Signed-off-by: Ronald G Minnich <rminnich(a)gmail.com> Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/LinuxBIOSv2/util/flashrom/Makefile =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/Makefile 2006-11-21 23:51:08 UTC (rev 2504) +++ trunk/LinuxBIOSv2/util/flashrom/Makefile 2006-11-22 00:29:51 UTC (rev 2505) @@ -10,7 +10,7 @@ STRIP = strip #CFLAGS = -O2 -g -Wall -Werror CFLAGS = -Os -Wall -Werror -DDISABLE_DOC # -DTS5300 -LDFLAGS = -lpci -static +LDFLAGS = -lpci -lz -static OBJS = flash_enable.o udelay.o jedec.o sst28sf040.o am29f040b.o mx29f002.o \ Modified: trunk/LinuxBIOSv2/util/flashrom/jedec.c =================================================================== --- trunk/LinuxBIOSv2/util/flashrom/jedec.c 2006-11-21 23:51:08 UTC (rev 2504) +++ trunk/LinuxBIOSv2/util/flashrom/jedec.c 2006-11-22 00:29:51 UTC (rev 2505) @@ -3,6 +3,8 @@ * * * Copyright 2000 Silicon Integrated System Corporation + * Copyright 2006 Giampiero Giancipoli <gianci(a)email.it> + * Copyright 2006 coresystems GmbH <info(a)coresystems.de> * * 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 @@ -29,6 +31,8 @@ #include "jedec.h" #include "debug.h" +#define MAX_REFLASH_TRIES 0x10 + int probe_jedec(struct flashchip *flash) { volatile uint8_t *bios = flash->virt_addr; @@ -134,34 +138,58 @@ int write_page_write_jedec(volatile uint8_t *bios, uint8_t *src, volatile uint8_t *dst, int page_size) { - int i; + int i, tried = 0, start_index = 0, ok; + volatile uint8_t *d = dst; + uint8_t *s = src; +retry: /* Issue JEDEC Data Unprotect comand */ *(volatile uint8_t *) (bios + 0x5555) = 0xAA; *(volatile uint8_t *) (bios + 0x2AAA) = 0x55; *(volatile uint8_t *) (bios + 0x5555) = 0xA0; /* transfer data from source to destination */ - for (i = 0; i < page_size; i++) { + for (i = start_index; i < page_size; i++) { /* If the data is 0xFF, don't program it */ - if (*src == 0xFF) - continue; - *dst++ = *src++; + if (*src != 0xFF ) + *dst = *src; + dst++; + src++; } toggle_ready_jedec(dst - 1); - return 0; + dst = d; + src = s; + ok = 1; + for (i = 0; i < page_size; i++) { + if ( *dst != *src ) + { + ok = 0; + break; + } + dst++; + src++; + } + + if (!ok && tried++ < MAX_REFLASH_TRIES) { + start_index = i; + goto retry; + } + if (!ok) { + fprintf( stderr, " page %d failed!\n", (unsigned int)(d-bios)/page_size ); + } + return (!ok); } int write_byte_program_jedec(volatile uint8_t *bios, uint8_t *src, volatile uint8_t *dst) { - int tried = 0; + int tried = 0, ok = 1; /* If the data is 0xFF, don't program it */ if (*src == 0xFF) { - return 0; + return -1; } retry: @@ -174,11 +202,14 @@ *dst = *src; toggle_ready_jedec(bios); - if (*dst != *src && tried++ < 0x10) { + if (*dst != *src && tried++ < MAX_REFLASH_TRIES) { goto retry; } - return 0; + if (tried >= MAX_REFLASH_TRIES) + ok=0; + + return (!ok); } int write_sector_jedec(volatile uint8_t *bios, uint8_t *src, @@ -202,10 +233,14 @@ volatile uint8_t *bios = flash->virt_addr; erase_chip_jedec(flash); - if (*bios != (uint8_t) 0xff) { - printf("ERASE FAILED\n"); - return -1; - } + // dumb check if erase was successful. + for (i=0; i < total_size; i++) { + if (bios[i] != (uint8_t)0xff) { + printf("ERASE FAILED\n"); + return -1; + } + } + printf("Programming Page: "); for (i = 0; i < total_size / page_size; i++) { printf("%04d at address: 0x%08x", i, i * page_size);

1 0

Re: [LinuxBIOS] #49: TPM support for LinuxBIOS
by LinuxBIOS 22 Nov '06

22 Nov '06

#49: TPM support for LinuxBIOS ----------------------------+----------------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: code | Version: v2 Resolution: | Keywords: security, tpm Dependencies: | Patchstatus: there is no patch ----------------------------+----------------------------------------------- Changes (by uwe): * keywords: security => security, tpm Old description: > Do we want to add support for TPM and related parts of "Trusted > Computing" to LinuxBIOS? > > I do understand that "Trusted Computing" might/will be abused in the > future, but it has some positive sides, too. It would be a good selling- > point for LinuxBIOS in security-related scenarious ("secure boot"). > > Of course, this should be an option (enable/disable). New description: Do we want to add support for TPM and related parts of "Trusted Computing" to LinuxBIOS? I do understand that "Trusted Computing" might/will be abused in the future, but it has some positive sides, too. It would be a good selling- point for LinuxBIOS in security-related scenarios ("secure boot"). Of course, this should be an option (enable/disable). -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/49#comment:1> LinuxBIOS <http://www.linuxbios.org/>

1 0

Re: [LinuxBIOS] #48: Ready-made, downloadable QEMU images with various payloads
by LinuxBIOS 22 Nov '06

22 Nov '06

#48: Ready-made, downloadable QEMU images with various payloads -------------------------------------+-------------------------------------- Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: critical | Milestone: Going mainstream Component: wiki/website/tracker | Version: v2 Resolution: | Keywords: Dependencies: | Patchstatus: there is no patch -------------------------------------+-------------------------------------- Comment (by stepan): Some such images are available with FILO payload at http://qa.linuxbios.org/overview.php We need the whole thing with other payloads as well. -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/48#comment:1> LinuxBIOS <http://www.linuxbios.org/>

1 0

Re: [LinuxBIOS] #41: Re: #40: Decide on common header #ifndef names or standards for usage
by LinuxBIOS 22 Nov '06

22 Nov '06

#41: Re: [LinuxBIOS] #40: Decide on common header #ifndef names or standards for usage --------------------------------------------------------+------------------- Reporter: Stefan Reinauer <stepan(a)coresystems.de> | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: Component: code | Version: v2 Resolution: duplicate | Keywords: Dependencies: #40 | Patchstatus: there is no patch --------------------------------------------------------+------------------- Changes (by stepan): * status: new => closed * dependencies: => #40 * resolution: => duplicate Old description: > I think I've mostly been using these: > > > __FOO_H__ > > these are used by glibc and Linux: > > _PATH_TO_FOO_H > > Maybe we want to use those? > > which ones have we been using most? (Smallest change commandment) > > > Is there a special convention or agreement on when to use which? If > yes, > > it should be documented. If no, we should standardize on one format > and > > use it consistently. > > Lets make a standard now and use it. It should go to the Coding > Guide Lines > > Stefan New description: I think I've mostly been using these: > __FOO_H__ these are used by glibc and Linux: _PATH_TO_FOO_H Maybe we want to use those? which ones have we been using most? (Smallest change commandment) > Is there a special convention or agreement on when to use which? If yes, > it should be documented. If no, we should standardize on one format and > use it consistently. Lets make a standard now and use it. It should go to the Coding Guide Lines Stefan Comment: this is a duplicate of #40. closing it -- Ticket URL: <http://tracker.linuxbios.org/trac/LinuxBIOS/ticket/41#comment:1> LinuxBIOS <http://www.linuxbios.org/>

1 0

[LinuxBIOS] r2498 build service
by LinuxBIOS information 22 Nov '06

22 Nov '06

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "stepan" checked in revision 2498 to the LinuxBIOS source repository and caused the following changes: Change Log: Fix hardcoding of iasl path. iasl is in the user path in the pmtools packages of upcoming SUSE 10.2, too, so the problem will go away. (new package installed on linuxbios.org, too) See also http://www.linuxbios.org/pipermail/linuxbios/2006-September/015968.html Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Compilation of iwill:dk8_htx has been broken Compilation of msi:ms9185 has been broken 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 will be backed out. Yours truely, LinuxBIOS automatic build system

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
26
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 November 2006