coreboot January 2010

coreboot@coreboot.org

58 participants
340 discussions

[PATCH] Add clobber regs to AMD CAR
by Rudolf Marek 16 Jan '10

16 Jan '10

Hello, Following patch adds proper inline assembly register clobbers to the AMD CAR code. The reason is that the GCC expects some values to be still valid, but those are overwritten by the inline code (ecx). The memcopy implementation is taken from linux kernel 2.6.32. The EBP relocation is to needed because the code does not use frame pointer. As an extra safety I added a clobber of all available registers. To make GCC extra sure that no value is valid, which should catch pointers to variables on the stack too. Can someone test this change on something else than model 0fh please? Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz> Thanks, Rudolf

1 0

[PATCH] Add clobber regs to AMD CAR
by Rudolf Marek 16 Jan '10

16 Jan '10

1 0

#104: flashrom: Change flash drivers to never erase data before writing
by coreboot 16 Jan '10

16 Jan '10

#104: flashrom: Change flash drivers to never erase data before writing ---------------------------------+------------------------------------------ Reporter: stuge | Owner: somebody Type: defect | Status: new Priority: major | Milestone: flashrom v1.0 Component: flashrom | Version: Keywords: erase write | Dependencies: #103 Patchstatus: there is no patch | ---------------------------------+------------------------------------------ The user should be responsible for ensuring that the flash chip has been erased where new data should be written. At the moment, flashrom will erase at least one full page and then rewrite it, when the user asks to only write a few bytes using -l/-i/-s/-e. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/104> coreboot <http://www.coreboot.org/>

2 18

#101: flashrom: Remove pciutils check from Makefile
by coreboot 16 Jan '10

16 Jan '10

#101: flashrom: Remove pciutils check from Makefile ---------------------------------------------+------------------------------ Reporter: stuge | Owner: somebody Type: defect | Status: new Priority: major | Milestone: flashrom v1.0 Component: flashrom | Version: Keywords: pciutils libpci build ldflags | Dependencies: Patchstatus: patch needs review | ---------------------------------------------+------------------------------ The check belongs in a configure script or similar, the check also claims that packages can not be found for any build error, which is not good enough. Has confused more than one user already. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/101> coreboot <http://www.coreboot.org/>

3 6

#120: flashrom failure to read
by coreboot 16 Jan '10

16 Jan '10

#120: flashrom failure to read ---------------------------------+------------------------------------------ Reporter: toc@… | Owner: somebody Type: defect | Status: new Priority: major | Milestone: Component: flashrom | Version: v2 Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ Running flashrom -r rom.file results in an output file of all null bytes. Standard output: {{{ Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH9R", enabling flash write... tried to set 0xdc to 0x3 on Intel ICH9R failed (WARNING ONLY) FAILED! Found chip "Macronix MX25L8005" (1024 KB) at physical address 0xfff00000. Reading flash... done. }}} Verbose output indicates failure of opcode 0x03. {{{ Reading flash... ich_spi_read_page: offset=0, number=256, buf=0xb7cf0008 Opcode 3 not found. run OPCODE 0x03 failed Error readingdone. }}} Full verbose output attached -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/120> coreboot <http://www.coreboot.org/>

1 25

AMD CAR questions
by Rudolf Marek 15 Jan '10

15 Jan '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, While thinking how to implement the resume without memory hole I came cross following piece of code in AMD CAR: set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP) */ print_debug("Copying data from cache to RAM -- switching to use RAM as stack... "); memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void *)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE); But! the memory is WB too. Therefore the memcopy _must_ evict some L1 to where? Please note that this code is executed still with CAR enabled. I answered this question using the Perf counters: Dumping perf counters 00000000 <- Eviction of L2 to system memory (writebacks to system) 00001172 <- Eviction of data L1 to L2 of all previous states (MOESI) 00000b5f <- L1 Data Cache Refills from System 00000000 Copying data from cache to RAM -- switching to use RAM as stack... Dumping perf counters II 00000000 0000120b 00000b6b 00000000 With bit of different counters: Dumping perf counters 00000039 <- L2 fills from L1 000007e2 <- Eviction of data L1 to L2 of all previous states (MOES) - excluding invalid 00000d0f <- L1 Data Cache Refills from System (excluding invalid) 00000000 Copying data from cache to RAM -- switching to use RAM as stack... Dumping perf counters II 00000143 0000080e 00000d1c 00000000 It clearly shows that L2 is used for this kind of things. Was this intended? The L2 I think contains also the cached ROM code... so situation is bit more complicated than one can expect. The patch for this kind of analysis is attached if anyone is interested. Oh btw I had to add some clobbers to the inline assembly or GCC will not thing the content of ECX has been changed by inline assembly... Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktQ4V0ACgkQ3J9wPJqZRNWiCACgy6jnD7m0yaj/oEjIUrdbYVkR B3wAoOEE0t34Nkar21c+Am2PQq9DXcqm =/D4r -----END PGP SIGNATURE-----

2 3

#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

← Newer
1
...
22
23
24
25
26
27
28
...
34
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 January 2010