Skip to content

GitLab

Switch branch/tag
  1. 03 May, 2009 1 commit
  3. 01 May, 2009 6 commits
  5. 29 Apr, 2009 1 commit
  7. 28 Apr, 2009 1 commit
  9. 26 Apr, 2009 1 commit
  11. 25 Apr, 2009 1 commit
  13. 24 Apr, 2009 1 commit
  15. 23 Apr, 2009 2 commits
  17. 22 Apr, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      All "unknown xy SPI chip" entries claim to have status UNTESTED for probe/read/erase/write · 42882fd9
      Carl-Daniel Hailfinger authored 
      
That is incorrect.

A bit of confusion comes from how the #defines are named. We call them
TEST_BAD_*, but the message printed by flashrom says: "This flash part
has status NOT WORKING for operations:"

Something that is unimplemented is definitely not working.

Neither of the chip entries mentioned above has erase or write functions
implemented, so erase and write are not working. Since their size is
unknown, we can't read them in. That means read is not working as well.
Probing is a different matter. If a chip-specific probe function had
matched, we wouldn't have to handle the chip with the "unknown xy SPI
chip" fallback. I'm tempted to call that "not working" as well, but I'm
open to discussion on this point.

Corresponding to flashrom svn r439 and coreboot v2 svn r4177.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      42882fd9
  19. 21 Apr, 2009 3 commits
  21. 20 Apr, 2009 3 commits
  23. 19 Apr, 2009 2 commits
  25. 17 Apr, 2009 1 commit
  27. 15 Apr, 2009 1 commit
  29. 13 Apr, 2009 1 commit
  31. 11 Apr, 2009 1 commit
  33. 10 Apr, 2009 2 commits
  35. 09 Apr, 2009 1 commit
  37. 30 Mar, 2009 1 commit
  39. 19 Mar, 2009 1 commit
  41. 17 Mar, 2009 1 commit
    • Stefan Reinauer's avatar
      This patch adds "high coreboot table support" to coreboot version 2 · 2d853bb5
      Stefan Reinauer authored 
      
Some bootloaders seem to overwrite memory starting at 0x600, thus destroying
the coreboot table integrity, rendering the table useless.

By moving the table to the high tables area (if it's activated), this problem
is fixed.

In order to move the table, a 40 bytes mini coreboot table with a single sub
table is placed at 0x500/0x530 that points to the real coreboot table. This is
comparable to the ACPI RSDT or the MP floating table.

This patch also adds "table forward" support to flashrom and nvramtool.

Corresponding to flashrom svn r421 and coreboot v2 svn r4012.
Signed-off-by: default avatarStefan Reinauer <stepan@coresystems.de>
Acked-by: default avatarPeter Stuge <peter@stuge.se>
      2d853bb5
  43. 06 Mar, 2009 2 commits
    • Carl-Daniel Hailfinger's avatar
      FreeBSD definitions of (read|write)[bwl] collide with our own · 0472f3d8
      Carl-Daniel Hailfinger authored 
      
Before we attempt trickery, we can simply rename the accessor functions.

Patch created with the help of Coccinelle.

Corresponding to flashrom svn r420 and coreboot v2 svn r3984.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarIdwer Vollering <idwer_v@hotmail.com>
Acked-by: default avatarPatrick Georgi <patrick@georgi-clan.de>
      0472f3d8
    • Carl-Daniel Hailfinger's avatar
      Reduce use of volatile variables · b8855697
      Carl-Daniel Hailfinger authored 
      During the conversion of flash chip accesses to helper functions, I spotted
assignments to volatile variables which were neither placed inside the mmapped
ROM area nor were they counters.
Due to the use of accessor functions, volatile usage can be reduced
significantly because the accessor functions take care of actually
performing the reads/writes correctly.

The following semantic patch spotted them (linebreak in python string
for readability reasons, please remove before usage):
@r exists@
expression b;
typedef uint8_t;
volatile uint8_t a;
position p1;
@@
 a@p1 = readb(b);

@script:python@
p1 << r.p1;
a << r.a;
b << r.b;
@@
print "* file: %s line %s has assignment to unnecessarily volatile
variable: %s = readb(%s);" % (p1[0].file, p1[0].line, a, b)

Result was:
HANDLING: sst28sf040.c
* file: sst28sf040.c line 44 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 43 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 42 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 41 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 40 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 39 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 38 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 58 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 57 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 56 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 55 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 54 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 53 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);
* file: sst28sf040.c line 52 has assignment to unnecessarily volatile
variable: tmp = readb(TODO: Binary);

The following semantic patch uses the spatch builtin match printing
functionality by prepending a "*" to the line with the pattern:
@@
expression b;
typedef uint8_t;
volatile uint8_t a;
@@
* a = readb(b);

Result is:
HANDLING: sst28sf040.c
diff =
-       tmp = readb(bios + 0x1823);
-       tmp = readb(bios + 0x1820);
-       tmp = readb(bios + 0x1822);
-       tmp = readb(bios + 0x0418);
-       tmp = readb(bios + 0x041B);
-       tmp = readb(bios + 0x0419);
-       tmp = readb(bios + 0x040A);
 }
 
 static __inline__ void unprotect_28sf040(volatile uint8_t *bios)
@@ -49,13 +42,6 @@ static __inline__ void unprotect_28sf040
        /* ask compiler not to optimize this */
        volatile uint8_t tmp;
 
-       tmp = readb(bios + 0x1823);
-       tmp = readb(bios + 0x1820);
-       tmp = readb(bios + 0x1822);
-       tmp = readb(bios + 0x0418);
-       tmp = readb(bios + 0x041B);
-       tmp = readb(bios + 0x0419);
-       tmp = readb(bios + 0x041A);
 }
 
 static __inline__ int erase_sector_28sf040(volatile uint8_t *bios,

It's arguably a bit easier to read if you get used to the leading "-"
for matching lines.

This patch was enabled by Coccinelle:
http://www.emn.fr/x-info/coccinelle/



Corresponding to flashrom svn r419 and coreboot v2 svn r3973.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarJoseph Smith <joe@settoplinux.org>
      b8855697
  45. 05 Mar, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use helper functions to access flash chips · 61a8bd27
      Carl-Daniel Hailfinger authored 
      
Right now we perform direct pointer manipulation without any abstraction
to read from and write to memory mapped flash chips. That makes it
impossible to drive any flasher which does not mmap the whole chip.

Using helper functions readb() and writeb() allows a driver for external
flash programmers like Paraflasher to replace readb and writeb with
calls to its own chip access routines.

This patch has the additional advantage of removing lots of unnecessary
casts to volatile uint8_t * and now-superfluous parentheses which caused
poor readability.

I used the semantic patcher Coccinelle to create this patch. The
semantic patch follows:
@@
expression a;
typedef uint8_t;
volatile uint8_t *b;
@@
- *(b) = (a);
+ writeb(a, b);
@@
volatile uint8_t *b;
@@
- *(b)
+ readb(b)
@@
type T;
T b;
@@
(
 readb
|
 writeb
)
 (...,
- (T)
- (b)
+ b
 )

In contrast to a sed script, the semantic patch performs type checking
before converting anything.

Tested-by: Joe Julian

Corresponding to flashrom svn r418 and coreboot v2 svn r3971.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarFENG Yu Ning <fengyuning1984@gmail.com>
      61a8bd27
  47. 25 Feb, 2009 1 commit
  49. 22 Feb, 2009 1 commit
  51. 09 Feb, 2009 1 commit
    • Peter Stuge's avatar
      Fix broken flash chip base address logic · 816139e0
      Peter Stuge authored 
      
Elan SC520 requries us to deal with flash chip base addresses at locations
other than top of 4GB. The logic for that was incorrectly triggered also when
a board had more than one flash chip. This patch will honor flashbase only when
probing for the first flash chip on the board, and look at top of 4GB for later
chips.

Corresponding to flashrom svn r415 and coreboot v2 svn r3932.
Signed-off-by: default avatarPeter Stuge <peter@stuge.se>
Acked-by: default avatarMyles Watson <mylesgw@gmail.com>
      816139e0
  53. 02 Feb, 2009 1 commit

Powered by Integricloud