coreboot June 2008

coreboot@coreboot.org

75 participants
230 discussions

Start a nNew thread

flashrom patch: Force read unknown flash chips
by Peter Stuge 18 Jun '08

18 Jun '08

Patch attached. //Peter

3 4

r3367 - trunk/util/flashrom
by svn＠coreboot.org 18 Jun '08

18 Jun '08

Author: stuge Date: 2008-06-18 04:08:40 +0200 (Wed, 18 Jun 2008) New Revision: 3367 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashrom.c trunk/util/flashrom/layout.c Log: flashrom: Force read unknown flash chips When flash chip detection fails, it is still useful and possible to read the flash chip contents. If no flash chip is found in normal probes and the -f -r -c CHIPNAME options are given, a successful probe for the specified chip is forced, and then flashrom reads the flash chip using either the read function for the specified chip, or if there is none, a simple memcpy(). The patch also moves the global variable int force in flashrom.c into main() and passes it as a parameter to layout.c:show_id(), which was the only other function that used the variable. This is needed to avoid confusion with the new parameter int force which is added to flashrom.c:probe_flash() and used to force probe success for the chip named in char *chip_to_probe. Signed-off-by: Peter Stuge <peter(a)stuge.se> Acked-by: Ward Vandewege <ward(a)gnu.org> Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2008-06-13 01:39:45 UTC (rev 3366) +++ trunk/util/flashrom/flash.h 2008-06-18 02:08:40 UTC (rev 3367) @@ -394,7 +394,7 @@ int map_flash_registers(struct flashchip *flash); /* layout.c */ -int show_id(uint8_t *bios, int size); +int show_id(uint8_t *bios, int size, int force); int read_romlayout(char *name); int find_romentry(char *name); int handle_romentries(uint8_t *buffer, uint8_t *content); Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2008-06-13 01:39:45 UTC (rev 3366) +++ trunk/util/flashrom/flashrom.c 2008-06-18 02:08:40 UTC (rev 3367) @@ -43,7 +43,7 @@ char *chip_to_probe = NULL; struct pci_access *pacc; /* For board and chipset_enable */ int exclude_start_page, exclude_end_page; -int force = 0, verbose = 0; +int verbose = 0; int fd_mem; struct pci_dev *pci_dev_find(uint16_t vendor, uint16_t device) @@ -99,7 +99,7 @@ return 0; } -struct flashchip *probe_flash(struct flashchip *flash) +struct flashchip *probe_flash(struct flashchip *flash, int force) { volatile uint8_t *bios; unsigned long flash_baseaddr, size; @@ -111,7 +111,7 @@ } printf_debug("Probing for %s %s, %d KB: ", flash->vendor, flash->name, flash->total_size); - if (!flash->probe) { + if (!flash->probe && !force) { printf_debug("failed! flashrom has no probe function for this flash chip.\n"); flash++; continue; @@ -150,7 +150,7 @@ } flash->virtual_memory = bios; - if (flash->probe(flash) == 1) { + if (force || flash->probe(flash) == 1) { printf("Found chip \"%s %s\" (%d KB) at physical address 0x%lx.\n", flash->vendor, flash->name, flash->total_size, flash_baseaddr); @@ -251,6 +251,7 @@ struct flashchip *flash, *flashes[3]; int opt; int option_index = 0; + int force = 0; int read_it = 0, write_it = 0, erase_it = 0, verify_it = 0; int ret = 0, i; #ifdef __FreeBSD__ @@ -413,7 +414,7 @@ board_flash_enable(lb_vendor, lb_part); for (i = 0; i < ARRAY_SIZE(flashes); i++) { - flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips); + flashes[i] = probe_flash(i ? flashes[i - 1] + 1 : flashchips, 0); if (!flashes[i]) for (i++; i < ARRAY_SIZE(flashes); i++) flashes[i] = NULL; @@ -427,6 +428,44 @@ exit(1); } else if (!flashes[0]) { printf("No EEPROM/flash device found.\n"); + if (!force || !chip_to_probe) { + printf("If you know which flash chip you have, and if this version of flashrom\n"); + printf("supports a similar flash chip, you can try to force read your chip. Run:\n"); + printf("flashrom -f -r -c similar_supported_flash_chip filename\n"); + printf("\n"); + printf("Note: flashrom can never write when the flash chip isn't found automatically.\n"); + } + if (force && read_it && chip_to_probe) { + printf("Force read (-f -r -c) requested, forcing chip probe success:\n"); + flashes[0] = probe_flash(flashchips, 1); + if (!flashes[0]) { + printf("flashrom does not support a flash chip named '%s'.\n", chip_to_probe); + printf("Run flashrom -L to view the hardware supported in this flashrom version.\n"); + exit(1); + } + size = flashes[0]->total_size * 1024; + buf = (uint8_t *) calloc(size, sizeof(char)); + + if ((image = fopen(filename, "w")) == NULL) { + perror(filename); + exit(1); + } + printf("Force reading flash..."); + if (!flashes[0]->read) + memcpy(buf, (const char *)flashes[0]->virtual_memory, size); + else + flashes[0]->read(flashes[0], buf); + + if (exclude_end_position - exclude_start_position > 0) + memset(buf + exclude_start_position, 0, + exclude_end_position - exclude_start_position); + + fwrite(buf, sizeof(char), size, image); + fclose(image); + printf("done\n"); + free(buf); + exit(0); + } // FIXME: flash writes stay enabled! exit(1); } @@ -522,7 +561,7 @@ } fread(buf, sizeof(char), size, image); - show_id(buf, size); + show_id(buf, size, force); fclose(image); } Modified: trunk/util/flashrom/layout.c =================================================================== --- trunk/util/flashrom/layout.c 2008-06-13 01:39:45 UTC (rev 3366) +++ trunk/util/flashrom/layout.c 2008-06-18 02:08:40 UTC (rev 3367) @@ -28,8 +28,6 @@ char *mainboard_part = NULL; int romimages = 0; -extern int force; - #define MAX_ROMLAYOUT 16 typedef struct { @@ -43,7 +41,7 @@ static char *def_name = "DEFAULT"; -int show_id(uint8_t *bios, int size) +int show_id(uint8_t *bios, int size, int force) { unsigned int *walk;

1 0

patch: supermicro h8qm8
by ron minnich 18 Jun '08

18 Jun '08

coreboot for this board. I'd like to get this in so some folks who need to see it can see it. This is assembled from other boards so far. Once I start real changes I'll modify copyright as needed. thanks ron

2 1

Thin Client Compaq Evo T20
by Philip Loewen 17 Jun '08

17 Jun '08

I'm thinking about trying coreboot on the Compaq Evo T20 thin client. This is a Geode GX1 machine with CS5530 companion chip and National Semiconductor DP83815 ethernet card. It has 48MB of flash memory and 64 MB of RAM (soldered). The superiotool from coreboot can't find any evidence of super-I/O. The mainboard contains a chip that looks like a socketed PLCC BIOS chip, Winbond 29C020... with a sticker on top giving credit to Wyse Tech 01'V9.0. The keyboard and mouse use a USB 1.1 interface. `lspci` says 00:13.0 USB Controller: Compaq ... ZFMicro Chipset USB (rev 06) Expert advice on these questions would be very welcome: 1. Does coreboot support this setup? (Particularly the USB devices?) 2. What advantages will coreboot offer over the manufacturer's original BIOS? E.g., will I get a BIOS control screen I can use to change settings until they work? 3. I don't have too much time to indulge in hardware hacking. I'm hoping for an approach that would not require me to even open the Evo's case! And this might be possible: like the Wyse Winterm, the Evo boots from on-board flash memory that can be rewritten using 'netxfer'. One of the files that netxfer delivers to the thin client is called "the BIOS" by people who know these things. Tradition among users like me is to treat that file with great respect, making sure an exact copy of the factory original is present whenever other files in the bundle are replaced. Here's my main question: can I replace that file (named ulc_code.ce, size 4 MB) with something from coreboot and use 'netxfer' to get a working alternative to the factory BIOS? What can I test before trying this to make sure I don't turn my little device into a brick? Are there some magic bytes or signatures to look for in the factory-file to confirm that it really is some kind of BIOS, and that program execution starts from the same location in the commercial file as it will in coreboot? What else should I be watching for? Thanks in advance for any comments or pointers. Philip

8 12

r203 - buildrom-devel/config/platforms
by svn＠coreboot.org 17 Jun '08

17 Jun '08

Author: ward Date: 2008-06-17 18:38:56 +0200 (Tue, 17 Jun 2008) New Revision: 203 Modified: buildrom-devel/config/platforms/qemu.conf Log: Fix LAB builds for qemu - we were not using the right kernel version. This is a trivial patch. Signed-off-by: Ward Vandewege <ward(a)gnu.org> Acked-by: Ward Vandewege <ward(a)gnu.org> Modified: buildrom-devel/config/platforms/qemu.conf =================================================================== --- buildrom-devel/config/platforms/qemu.conf 2008-06-17 15:29:59 UTC (rev 202) +++ buildrom-devel/config/platforms/qemu.conf 2008-06-17 16:38:56 UTC (rev 203) @@ -7,8 +7,8 @@ # kernel configuration (for LAB) -KERNEL_VERSION=2.6.20 -KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-qemu-2.6.20 +KERNEL_VERSION=2.6.22.2 +KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-qemu UCLIBC_VER=0.9.29 # Etherboot configuration

1 0

dbe62 status
by ron minnich 17 Jun '08

17 Jun '08

X11 still gets very bad errors. I think the memory is not quite right: BUG: unable to handle kernel paging request at fd1c858b IP: [<d08e1430>] :nfs:nfs_readpage+0x15/0x211 *pde = 00000000 Oops: 0000 [#2] Modules linked in: nfs lockd sunrpc via_velocity 9p 9pnet Pid: 1219, comm: python Tainted: G D (2.6.25.7-faro #1) EIP: 0060:[<d08e1430>] EFLAGS: 00010246 CPU: 0 EIP is at nfs_readpage+0x15/0x211 [nfs] EAX: fd1c858b EBX: ce10bf40 ECX: d08f49a0 EDX: c1026980 ESI: ce380470 EDI: c1026980 EBP: ce38ff28 ESP: ce38feb8 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process python (pid: 1219, ti=ce38e000 task=ce836550 task.ti=ce38e000) Stack: fffffffe 05f08f17 0000000d d0908194 ce5a9f14 00000002 c1026980 ce380470 ce10bf40 ce38ff28 c012f271 ce380470 ce5a9f14 ce10bf84 ce5a9e78 00000000 00000004 ce38ff44 c014bb95 d0908194 ce380470 ce836550 ce1f5060 c013659d Call Trace: [<c012f271>] filemap_fault+0x288/0x2e0 [<c014bb95>] do_path_lookup+0xf3/0x10c [<c013659d>] __do_fault+0x4e/0x2d2 [<c0137738>] handle_mm_fault+0x1fc/0x439 [<c010d152>] do_page_fault+0x1f9/0x513 [<c010cf59>] do_page_fault+0x0/0x513 [<c02925da>] error_code+0x6a/0x70 ======================= Code: 75 04 0f ba 2b 03 89 f0 5b 5e 5f 5d e9 7b f9 ff ff 5b 5e 5f 5d c3 55 57 89 d7 56 53 89 c3 83 ec 18 8b 42 10 f6 05 2c 45 89 d0 08 <8b> 28 74 16 ff 72 EIP: [<d08e1430>] nfs_readpage+0x15/0x211 [nfs] SS:ESP 0068:ce38feb8 ---[ end trace a6f30bfb7037e608 ]--- Eeek! page_mapcount(page) went negative! (-2050490369) page pfn = 134e page->flags = fffffdb4 BUG: unable to handle kernel paging request at fffffe9c IP: [<c013b8ad>] page_remove_rmap+0x62/0xf6 *pde = 00001067 *pte = 00000000 Oops: 0000 [#3] Ouch. OK, so, dbe62 owners, let's try to work out memory. ron

2 2

r202 - buildrom-devel/packages/qemu
by svn＠coreboot.org 17 Jun '08

17 Jun '08

Author: ward Date: 2008-06-17 17:29:59 +0200 (Tue, 17 Jun 2008) New Revision: 202 Modified: buildrom-devel/packages/qemu/qemu.mk Log: The download URL for QEMU has changed. This is a trivial patch. Signed-off-by: Ward Vandewege <ward(a)gnu.org> Acked-by: Ward Vandewege <ward(a)gnu.org> Modified: buildrom-devel/packages/qemu/qemu.mk =================================================================== --- buildrom-devel/packages/qemu/qemu.mk 2008-06-05 14:54:13 UTC (rev 201) +++ buildrom-devel/packages/qemu/qemu.mk 2008-06-17 15:29:59 UTC (rev 202) @@ -1,4 +1,4 @@ -QEMU_URL=http://fabrice.bellard.free.fr/qemu/ +QEMU_URL=http://bellard.org/qemu/ QEMU_SOURCE=qemu-0.9.0.tar.gz QEMU_DIR=$(BUILD_DIR)/qemu QEMU_SRC_DIR=$(QEMU_DIR)/qemu-0.9.0

1 0

flashrom image identification problem/coreboot signature RFC
by Peter Stuge 16 Jun '08

16 Jun '08

On Fri, Jun 13, 2008 at 02:30:31PM -0700, Victor Zele wrote: > bash-3.00# ./flashrom -vw sa6k14.rom .. > coreboot last image size (not ROM size) is -1791885312 bytes. > Segmentation fault Victor used the factory flashing utility to update his factory BIOS, then he read back the sa6k14.rom file using flashrom. When trying to write sa6k14.rom, flashrom mistakes it for a coreboot image and crashes because it is in fact not a coreboot image, and where coreboot stores hints for flashrom, sa6k14.rom has data which is garbage to flashrom. The problem lies in layout.c:show_id() which does this to identify a factory BIOS: --8<-- walk = (unsigned int *)(bios + size - 0x10); walk--; if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) { /* We might have an Nvidia chipset bios * which stores the id information at a * different location. */ walk = (unsigned int *)(bios + size - 0x80); walk--; } if ((*walk) == 0 || ((*walk) & 0x3ff) != 0) { printf("Flash image seems to be a legacy BIOS. mainboard_vendor = def_name; mainboard_part = def_name; return 0; } -->8-- Seems that the 4 last bytes before the reset vector are checked, and that flashrom considers the image to be coreboot when bits 9-0 are 0 and one or more of bits 31-10 are 1. This heuristic is no longer good enough. Any ideas for a nice and simple coreboot signature? //Peter

3 9

Athlon 64 X2, coreboot, and ECC memory
by Chris Frey 16 Jun '08

16 Jun '08

Hi, I'm looking through specs and lists of supported motherboards and mailing list posts, and I see some conflicting reports about the Athlon 64 X2 and its ECC support. As this processor apparently has ECC support in it, does it matter what motherboard is used? Does anyone have coreboot + Athlon 64 X2 + ECC working? - Chris

2 1

work on intel 440GX
by Marek Becka 16 Jun '08

16 Jun '08

Hi all, I have one older motherboard with Intel 440 GX chipset. During this summer I would like to try to port coreboot on it. I like idea of this project and I would like to support it and learn something new. There is already work on 440 BX chipset, so I can establish on it. Documentation from Intel is also available. The only problem should be Ali M5132 Super I/O. I haven't found anything about this chip. It is real problem?

3 2

← Newer
1
...
12
13
14
15
16
17
18
...
23
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 2008