#102: flashrom: coreboot ROM image file identification heuristic is broken
-----------------------------------+----------------------------------------
Reporter: stuge | Owner: somebody
Type: defect | Status: new
Priority: blocker | Milestone: flashrom v1.0
Component: flashrom | Version:
Keywords: rom image heuristic | Dependencies:
Patchstatus: patch needs work |
-----------------------------------+----------------------------------------
Non-coreboot ROM images are incorrectly identified as coreboot images, and
arbitrary data is used in flashrom code.
The heuristic is far too simplistic, we need a proper signature in all
coreboot images. The suggested fix is to add a LAR header to the ROM
image, I like that too.
When an image is incorrectly identified, junk data used by flashrom
typically causes flashrom to segfault.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/102>
coreboot <http://www.coreboot.org/>
#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>
coreboot <http://www.coreboot.org/>
Hi,
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
startpos=0x38123;
endpos=0x3e005;
roundup(flash, &startpos, &endpos);
//results follow:
//startpos=0x38000;
//endpos=0x3efff;
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?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
This patch includes config files for the asus/a8n5x port. It is the same as
asus/a8n_e with a different pnp layout, so I used #include's whenever possible.
System boots and is usable with usb keyboard.
works:
- serial port
- vga (old pci card)
- memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms
in K8. Otherwise you get spurious memory corruption.
- ide disk
- usb
doesn't:
- ps/2 keyboard
- onboard ethernet
- vga pci-e card (??)
- any other pci card I tried
wasn't tested:
- sata
- game port
- onboard audio (not supported by alsa anyway)
- ps/2 mouse
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
Hi,
The unrv2b uncompression algorithm appears to behave very badly in the
absence of a proper cache. Instrumentation indicates somehting like ~180
i-stream cacheline requests for _every_ d-stream cacheline request
during decompression. The following patch copies the unrv2b function to
DRAM before performing the actual decompression, reducing the run-time
from 12.5s to 50ms in my environment. The patch is somewhat rough, and
assumes that (1) the unrv2b function is less than 1k in size, and (2)
that placing a copy of the function just after the decompress
destination is unproblematic. It works well for me, though.
Signed-off-by: Arne Georg Gleditsch <arne.gleditsch(a)numascale.com>
--
Arne.
Hello!
Atttached is a patch that will restore blue background and bright yellow
menu title in Bayou v0.3, after (if) the tinycurses VGA color correction
patch is applied (see an earlier thread started today).
Build and run tested under QEMU with bayou-0.3+coreboot-v3.
/ulf
Hello!
Attached is a patch to update Bayou v0.3 to use ACS_ macros for the line
drawing characters in the menu window border.
Build and run tested under QEMU with bayou-0.3+coreboot-v3.
/ulf
Hi,
I am glad to announce the release of the work we did in the last couple
of months writing support for a somewhat modern Intel Desktop/Mobile
chipset running with the Core Duo/Core 2 Duo: The i945 + ICH7.
The support package has been split in 6 different smaller patches:
1_superio_winbond_w83627thg.diff: Implement support for the Winbond
W83627THG.
2_southbridge_intel_i82801gx.diff: Support for the Intel ICH7 southbridge.
3_cpu_core_duo.diff: Support for Intel Core Duo and Core 2 Duo (tm) CPUs.
4_northbridge_intel_i945.diff: Support for the Intel 945 northbridge.
5_device_allocator.diff: Changes required to the device allocator
6_mainboard_kontron_986lcd_m.diff: Support for the Kontron 986LCD-M
mainboard series.
At this point I would like to say thank you to Intel Corporation for
doing all they could to make this possible.
I also want to cordially thank everyone else helping in the one way or
the other to make this happen.
Best regards,
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
