coreboot June 2009

coreboot@coreboot.org

84 participants
500 discussions

#113: problem
by coreboot 15 Jan '10

15 Jan '10

#113: problem ---------------------------------+------------------------------------------ Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: adlo | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ there is a bug -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/113> coreboot <http://www.coreboot.org/>

1 6

#106: flashrom: Add -T to automatically test all flash chip operations
by coreboot 15 Jan '10

15 Jan '10

#106: flashrom: Add -T to automatically test all flash chip operations ---------------------------------+------------------------------------------ Reporter: stuge | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: flashrom v1.0 Component: flashrom | Version: Keywords: testing | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ Maybe require -f to actually perform the test, since it will potentially fail to restore the flash chip to it's original state. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/106> coreboot <http://www.coreboot.org/>

1 6

#141: flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode
by coreboot 15 Jan '10

15 Jan '10

#141: flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: critical | Milestone: Component: flashrom | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ We should make a table in the flashrom code which tells it how much a given (detected/supported) southbridge can decode. Then, if the user tries to read/write/erase/verify a chip which is _bigger_ (e.g. 512 KB) than what the southbridge can decode (e.g. 256 KB as on the AMD CS5530A for example) flashrom should at the very least warn the user, probably even bail out with an error. I've stumbled upon exactly this problem, trying to make a backup of a 512KB chip in an CS5530A system. I ended up with only one half of the contents (but duplicated) and it _did_ verify OK. That's because I did 'flashrom -r bak.bin' on the box (which effectively got me two equal, broken 256KB halves instead of one correct 512KB image). Then I did 'flashrom -wv bak.bin' onto the other 512KB chip, which also got the incorrect contents, _but_ flashrom said it verified fine (which is actually true) because both the bak.bin _and_ the written contents are crap. I only noticed what was going on after lots of debugging. I finally did a 'dd if=/dev/urandom of=rnd.dd bs=1024c count=512', then 'flashrom -wv rnd.dd' which then FAILED, because here the two 256KB-halves of the image were _not_ the same as in the above case. Then I compared 'hexdump -Cv rnd.dd' and 'flashrom -r readback.dd; hexdump -Cv readback.dd' outputs and noticed that bytes 0x0..0x40000 (256 KB) were _not_ the same, but the other 256 KB _were_ the same. Anyway, this is a nice way for data loss, so we should fix it by throwing an error in such cases. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/141> coreboot <http://www.coreboot.org/>

1 2

#123: layout file
by coreboot 15 Jan '10

15 Jan '10

#123: layout file -------------------------------------+-------------------------------------- Reporter: vivanov@… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: flashrom v1.0 Component: flashrom | Version: v2 Keywords: layout address offset | Dependencies: Patchstatus: there is no patch | -------------------------------------+-------------------------------------- Hello, I am trying to update the BIOS "ST M50FW080" and get the following incomprehensibility - layout file works in a strange way 1) saved the current BIOS {{{ $ flashrom --read flash18_saved.rom }}} 2) then I filled first 512K of this file with zeros (it is needed because new BIOS will have 512K size) 3) then I created rom.layout file to use the normal image only: {{{ 00000000:0007ffff stuff 00080000:000fffff normal }}} 4) and started to upgrade BIOS {{{ $ flashrom --write --layout rom.layout --image flash18_saved.rom }}} And get the following: {{{ Looking for "normal"... found. Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. Found chip "ST M50FW080" (1024 KB) at physical address 0xfff00000. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flashrom(a)coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0000 at address: 0x00000000SKIPPED 0001 at address: 0x00010000SKIPPED 0002 at address: 0x00020000SKIPPED 0003 at address: 0x00030000SKIPPED 0004 at address: 0x00040000SKIPPED 0005 at address: 0x00050000SKIPPED 0006 at address: 0x00060000SKIPPED '''0007 at address: 0x00070000DONE BLOCK 0x70000''' 0008 at address: 0x00080000SKIPPED 0009 at address: 0x00090000SKIPPED 0010 at address: 0x000a0000SKIPPED 0011 at address: 0x000b0000SKIPPED 0012 at address: 0x000c0000SKIPPED 0013 at address: 0x000d0000SKIPPED 0014 at address: 0x000e0000SKIPPED 0015 at address: 0x000f0000SKIPPED }}} '''Next''' I changed the rom.layout file like follows: {{{ # cat rom.layout 00000000:00080000 stuff 00080000:000fffff normal }}} and get the '''right''' behaviour: {{{ # flashrom --write --layout rom.layout --image normal --verify flash18_saved.rom Looking for "normal"... found. Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. Found chip "ST M50FW080" (1024 KB) at physical address 0xfff00000. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE Please email a report to flashrom(a)coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! === Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0000 at address: 0x00000000SKIPPED 0001 at address: 0x00010000SKIPPED 0002 at address: 0x00020000SKIPPED 0003 at address: 0x00030000SKIPPED 0004 at address: 0x00040000SKIPPED 0005 at address: 0x00050000SKIPPED 0006 at address: 0x00060000SKIPPED 0007 at address: 0x00070000SKIPPED 0008 at address: 0x00080000SKIPPED 0009 at address: 0x00090000SKIPPED 0010 at address: 0x000a0000SKIPPED 0011 at address: 0x000b0000SKIPPED 0012 at address: 0x000c0000SKIPPED 0013 at address: 0x000d0000SKIPPED 0014 at address: 0x000e0000SKIPPED 0015 at address: 0x000f0000SKIPPED Verifying flash... VERIFIED. }}} Please explain me which rom layout I should use to update the last 512K of 1M BIOS? -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/123> coreboot <http://www.coreboot.org/>

2 3

#133: Create a typical failures FAQ
by coreboot 15 Jan '10

15 Jan '10

#133: Create a typical failures FAQ ---------------------------------------+------------------------------------ Reporter: stuge | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: flashrom | Version: Keywords: faq documentation debug | Dependencies: Patchstatus: there is no patch | ---------------------------------------+------------------------------------ Briefly describe what flashrom needs to do to successfully identify, read and write/erase the different type of chips to optimize the remote debugging process with new users. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/133> coreboot <http://www.coreboot.org/>

1 2

#130: flashrom segfault (with backtrace)
by coreboot 15 Jan '10

15 Jan '10

#130: flashrom segfault (with backtrace) ---------------------------------+------------------------------------------ Reporter: fragabr@… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ I want to test flashrom with a supported motherboard (Asus M2N-E with Linux 2.6.30-rc4) and it segfaults when I run it. I'm using the latest libpci (3.1.2): {{{ Calibrating delay loop... OK. No coreboot table found. Segmentation fault }}} Backtrace: {{{ #0 0x00007f1395141d49 in pci_fill_info_v31 () from /usr/local/lib/libpci.so.3 #1 0x00007f1395143c59 in pci_filter_match () from /usr/local/lib/libpci.so.3 #2 0x000000000040732f in ?? () #3 0x00000000004016f8 in ?? () #4 0x0000000000406d46 in ?? () #5 0x00007f1394df24f6 in __libc_start_main () from /lib64/libc.so.6 #6 0x0000000000401619 in ?? () #7 0x00007fff9d579e98 in ?? () #8 0x000000000000001c in ?? () #9 0x0000000000000001 in ?? () #10 0x00007fff9d57ab55 in ?? () #11 0x0000000000000000 in ?? () }}} -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/130> coreboot <http://www.coreboot.org/>

1 3

#140: flashrom: Consistently use stderr for error printing
by coreboot 15 Jan '10

15 Jan '10

#140: flashrom: Consistently use stderr for error printing ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: flashrom v1.0 Component: flashrom | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ We're not very consistent with error printing in flashrom. Many errors go to stdout instead of stderr. We should fix that by using fprintf(stderr, "Foo") where needed. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/140> coreboot <http://www.coreboot.org/>

1 2

[PATCH] Fix AMD 690 HIGH_TABLES
by Carl-Daniel Hailfinger 15 Oct '09

15 Oct '09

Zheng, can you please test this with HIGH_TABLES enabled (and a new FILO)? A full log would be appreciated. Thanks. This hopefully will fix AMD 690 HIGH_TABLES or at least give me an insight into why HIGH_TABLES fails. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/northbridge.c =================================================================== --- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/northbridge.c (Revision 4339) +++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/northbridge.c (Arbeitskopie) @@ -896,6 +896,7 @@ #if HAVE_HIGH_TABLES==1 #define HIGH_TABLES_SIZE 64 // maximum size of high tables in KB extern uint64_t high_tables_base, high_tables_size; +extern uint64_t uma_memory_base, uma_memory_size; #endif static void pci_domain_set_resources(device_t dev) @@ -1066,7 +1067,9 @@ } -// printk_debug("node %d : mmio_basek=%08x, basek=%08x, limitk=%08x\n", i, mmio_basek, basek, limitk); //yhlu + printk_debug("node %d : uma_memory_base/1024=0x%08x, mmio_basek=0x%08x, basek=0x%08x, limitk=0x%08x\n", i, uma_memory_base >> 10, mmio_basek, basek, limitk); + if ((uma_memory_base >> 10) < mmio_basek) + printk_alert("node %d: UMA memory starts below mmio_basek\n", i); /* See if I need to split the region to accomodate pci memory space */ if ( (basek < 4*1024*1024 ) && (limitk > mmio_basek) ) { @@ -1080,7 +1083,7 @@ #if HAVE_HIGH_TABLES==1 if (i==0 && high_tables_base==0) { /* Leave some space for ACPI, PIRQ and MP tables */ - high_tables_base = (mmio_basek - HIGH_TABLES_SIZE) * 1024; + high_tables_base = ((uma_memory_base >> 10) - HIGH_TABLES_SIZE) * 1024; high_tables_size = HIGH_TABLES_SIZE * 1024; printk_debug("(split)%xK table at =%08llx\n", HIGH_TABLES_SIZE, high_tables_base); @@ -1105,6 +1108,9 @@ sizek -= (4*1024*1024 - mmio_basek); } } + + printk_debug("node %d : uma_memory_base/1024=0x%08x, mmio_basek=0x%08x, basek=0x%08x, limitk=0x%08x\n", i, uma_memory_base >> 10, mmio_basek, basek, limitk); + /* If sizek == 0, it was split at mmio_basek without a hole. * Don't create an empty ram_resource. */ @@ -1116,7 +1122,7 @@ i, mmio_basek, basek, limitk); if (i==0 && high_tables_base==0) { /* Leave some space for ACPI, PIRQ and MP tables */ - high_tables_base = (limitk - HIGH_TABLES_SIZE) * 1024; + high_tables_base = ((uma_memory_base >> 10) - HIGH_TABLES_SIZE) * 1024; high_tables_size = HIGH_TABLES_SIZE * 1024; } #endif -- http://www.hailfinger.org/ Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/northbridge.c =================================================================== --- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/northbridge.c (Revision 4339) +++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/northbridge.c (Arbeitskopie) @@ -896,6 +896,7 @@ #if HAVE_HIGH_TABLES==1 #define HIGH_TABLES_SIZE 64 // maximum size of high tables in KB extern uint64_t high_tables_base, high_tables_size; +extern uint64_t uma_memory_base, uma_memory_size; #endif static void pci_domain_set_resources(device_t dev) @@ -1066,7 +1067,9 @@ } -// printk_debug("node %d : mmio_basek=%08x, basek=%08x, limitk=%08x\n", i, mmio_basek, basek, limitk); //yhlu + printk_debug("node %d : uma_memory_base/1024=0x%08x, mmio_basek=0x%08x, basek=0x%08x, limitk=0x%08x\n", i, uma_memory_base >> 10, mmio_basek, basek, limitk); + if ((uma_memory_base >> 10) < mmio_basek) + printk_alert("node %d: UMA memory starts below mmio_basek\n", i); /* See if I need to split the region to accomodate pci memory space */ if ( (basek < 4*1024*1024 ) && (limitk > mmio_basek) ) { @@ -1080,7 +1083,7 @@ #if HAVE_HIGH_TABLES==1 if (i==0 && high_tables_base==0) { /* Leave some space for ACPI, PIRQ and MP tables */ - high_tables_base = (mmio_basek - HIGH_TABLES_SIZE) * 1024; + high_tables_base = ((uma_memory_base >> 10) - HIGH_TABLES_SIZE) * 1024; high_tables_size = HIGH_TABLES_SIZE * 1024; printk_debug("(split)%xK table at =%08llx\n", HIGH_TABLES_SIZE, high_tables_base); @@ -1105,6 +1108,9 @@ sizek -= (4*1024*1024 - mmio_basek); } } + + printk_debug("node %d : uma_memory_base/1024=0x%08x, mmio_basek=0x%08x, basek=0x%08x, limitk=0x%08x\n", i, uma_memory_base >> 10, mmio_basek, basek, limitk); + /* If sizek == 0, it was split at mmio_basek without a hole. * Don't create an empty ram_resource. */ @@ -1116,7 +1122,7 @@ i, mmio_basek, basek, limitk); if (i==0 && high_tables_base==0) { /* Leave some space for ACPI, PIRQ and MP tables */ - high_tables_base = (limitk - HIGH_TABLES_SIZE) * 1024; + high_tables_base = ((uma_memory_base >> 10) - HIGH_TABLES_SIZE) * 1024; high_tables_size = HIGH_TABLES_SIZE * 1024; } #endif

3 6

flashrom on MCP73
by Fabrício Ceolin 08 Oct '09

08 Oct '09

Hi guys, We are trying to make flashrom work on http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=858&… Chipset MCP73 / SIP chipset Macronix MX25L8005. We made modifications using a enable_flash_mcp55 function, but does't work. ./flashrom -V -c MX25L8005 -r -f rom Calibrating delay loop... 627M loops per second, 100 myus = 199 us. OK. No coreboot table found. Found chipset "NVIDIA MCP73", enabling flash write... OK. Probing for Macronix MX25L8005, 1024 KB: spi_command called, but no SPI chipset/strapping detected No EEPROM/flash device found. Force read (-f -r -c) requested, forcing chip probe success: Probing for Macronix MX25L8005, 1024 KB: Found chip "Macronix MX25L8005" (1024 KB) at physical address 0xfff00000. Force reading flash... spi_chip_read called, but no SPI chipset/strapping detected 0 done. How can I do works? Are there any hints? Thanks! -- Fabrício Ceolin

3 4

#121: flashrom runtime error
by coreboot 29 Aug '09

29 Aug '09

#121: flashrom runtime error ---------------------------------+------------------------------------------ Reporter: lymanrb@… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: flashrom | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ I got such errors when running flashrom. {{{ Calibrating delay loop... OK. Can't mmap memory using /dev/mem: Invalid argument }}} My env {{{ Linux xxx 2.6.28-ARCH #1 SMP PREEMPT Sun Jan 18 19:41:52 UTC 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel GNU/Linux core/pciutils 3.0.3-1 [installed] (base) PCI bus configuration space access library and tools core/zlib 1.2.3.3-3 [installed] (base) A compression/decompression Library $ ./flashrom -R flashrom r3869 }}} -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/121> coreboot <http://www.coreboot.org/>

5 10

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