#109: flash base autodetection on AMD SC520
Reporter: stepan | Owner: stepan
Type: defect | Status: new
Priority: major | Milestone:
Component: adlo | Version: v2
Keywords: | Dependencies:
Patchstatus: patch needs review |
this code has been sitting on my hard disk for a while. It drops the nasty
ifdefs and implements auto detection for AMD SC520 systems, such as the
Technologic Systems TS5300.
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/109>
12 SST25VF032B, (tiny little chips)
Anybody want them, just send a snail mail address?
Now I need help, my machine has Pm49FL004 chips as standard, I have some
I want a 32 M Bit flash chip, if there is such a thing for this type of
chip, please let me know the part number. (I would much appreciate the
exact detail, as the supplier asks incomprehensible questions)
Attachment are the patches for Chipset AMD RS690, AMD SB600 and mainboard DBM690T. The following ACPI features are supported.
1. S1, S5 sleep and wake up (by power button or PS/2 keyboard/mouse).
2. AMD powernow-k8 driver.
3. Thermal configuration based on ADT7461.
4. IDE timing settings.
5. HPET timer.
6. Interrupt routing based on ACPI table.
Signed-off-by: Joe Bao <zheng.bao(a)amd.com>
Reviewed-by: Maggie Li <maggie.li(a)amd.com>
My Athlon64 / K8 socket 939 setup needed the following adjustments to fix
memory read/write errors. Thanks to Rudolf for hinting on which bits I
should check for. Details:
- bit 9, mandated by spec to always be set on sodimm or socket 939 dual
- bit 28, enable 2T timing. no idea why, but I get memory errors without
- bit 29, upper chip select. mandated by spec on socket 939.
My patch also adds missing descriptions, based on the ones from the spec
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
flashrom hasn't seen any major design changes in the last few months and
most chips still perform whole-chip erase instead of sector-based erase.
I'd like to introduce a function which takes a range and rounds the
start and the end of the range to the nearest block boundary.
void roundup(struct flashchip *flash, int *startpos, int *endpos);
Take an example 256 kByte flash chip with the following sector layout:
0x00000-0x0ffff 64kB block
0x10000-0x1ffff 64kB block
0x20000-0x2ffff 64kB block
0x30000-0x37fff 32kB block
0x38000-0x3bfff 16kB block
0x3c000-0x3dfff 8kB block
0x3e000-0x3efff 4kB block
0x3f000-0x3ffff 4kB block
roundup(flash, &startpos, &endpos);
That way, it is easily possible to check whether a given range can be
handled by sector-based erase and write.
You can use that result to tell the user that a range outside the
intended range will get flashed. It is also possible to refuse flashing
in that case.
Since the function will be generic and take a struct flashchip, there's
no need to store a pointer to it with each chip and you can call the
generic one from anywhere.
What do you think?
On 30.11.2008 15:52, svn(a)coreboot.org wrote:
> Author: stepan
> Date: 2008-11-30 15:52:46 +0100 (Sun, 30 Nov 2008)
> New Revision: 3783
> ok, another attempt to the build_opt_tbl problem:
> - create temp files and move them afterwards
> - remove dummy option -b
> - fix usage
> - drop implicit creation of .c file if no --option is specified.
> Now let's see if this fixes the issue. :-) We don't want to take 24s
> instead of 6s to build an image reliably (Yes, yes, I know Tiano takes
> over 20 minutes)
> Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de>
> Acked-by: Stefan Reinauer <stepan(a)coresystems.de>
Although this is already committed, I want to ack it retroactively.
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>