#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/>
#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/>
#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/>
#144: TYAN S7012 support
--------------------------------------------------------+-------------------
Reporter: john@… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: flashrom | Version: v2
Keywords: TYAN S7012 Intel ICH10R SST SST25VF032B | Dependencies:
Patchstatus: there is no patch |
--------------------------------------------------------+-------------------
I'm unable to flash a system that runs on a TYAN S7012 motherboard.
# flashrom -w bios.bin
flashrom v0.9.0-r659
No coreboot table found.
Found chipset "Intel ICH10R", enabling flash write... OK.
This chipset supports the following protocols: LPC,FWH,SPI.
Calibrating delay loop... OK.
Found chip "SST SST25VF032B" (4096 KB, SPI) at physical address
0xffc00000.
Flash image seems to be a legacy BIOS. Disabling checks.
Writing flash chip... COMPLETE.
Verifying flash... VERIFY FAILED at 0x00002000! Expected=0x00, Read=0xff
Running it with verbose the following error messages are printed out
(repeating).
Writing flash chip... Invalid OPCODE 0x06
due to SPI master limitation, ignoring and hoping it will be run as PREOP
Transaction error!
run OPCODE 0x02 failed
spi_byte_program failed during command execution
Invalid OPCODE 0x06
due to SPI master limitation, ignoring and hoping it will be run as PREOP
Transaction error!
run OPCODE 0x02 failed
spi_byte_program failed during command execution
Invalid OPCODE 0x06
CONFIG_STRICT_DEVMEM is not set in my kernel.
Anything I should try out?
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/144>
coreboot <http://www.coreboot.org/>
Hi I am trying to sort out a RAM issue with coreboot on a motherboard we
have designed at my work.
The board uses the AMD LX800 and CS5536 companion chipset.
I have been using coreboot-v3 and based my board port on the Alix 1.C
code. We have a SODIMM socket, so I used the initram.c from the
amd/db800 code because it does SPD.
The symptoms are that sometimes a boot will die during disable_car() in
arch/x86/geodelx/stage1.c:
/* OK, here is the theory: we should be able to copy
* the data back over itself, and the wbinvd should then
* flush to memory. Let's see.
*/
__asm__ __volatile__("cld; rep movsl" ::"D" (DCACHE_RAM_BASE),
"S" (DCACHE_RAM_BASE), "c" (DCACHE_RAM_SIZE/4): "memory");
__asm__ __volatile__ ("wbinvd\n");
Sometimes it boots fine and appears to be quite stable. If I run
software like mprime95 to "Torture Test" the system, it doesn't fail.
However, there is one strange phenomenon that I've noticed. If I remove
the RTC battery backup and Linux forces a fsck because the last boot
time was in the future. If Linux fixes a couple of errors and reboots
automatically in 5 seconds, during the reboot it's almost guaranteed
that coreboot will get stuck in disable_car(). I don't know if this is
useful, or just a coincidence. In my build I have also disabled the
CMOS Option Table (CONFIG_OPTION_TABLE) in case something there might be
causing the problem.
Initially I thought it was a hardware problem with our PCBs, but have
tested with a bios chip from an AMD reference design board (EmbeddedBIOS
v5.3) which booted Linux fine without any problems, so I have concluded
that my problem must be something I'm doing (or not doing) in coreboot.
I have checked all the SPD values against the datasheet for the Hynix
RAM chips (256MiB 333MHz). I tried using the non-SPD method as in the
Alix 1.C code and specified all the RAM parameters. I have also tried
to follow sdram_enable() and other functions in
northbridge/amd/geodelx/raminit.c to check against the AMD LX databook's
section 6.1.3 BIOS Initialization Sequence, though I admit I could have
easily missed something here.
I would be most grateful of any suggestions for helping me work out
what's going wrong.
Regards,
Nathan
