On 26.02.2010 11:34, Michael Karcher wrote:
Am Freitag, den 26.02.2010, 08:47 +0100 schrieb Carl-Daniel Hailfinger:
Here's my personal merge list: High priority:
- Laptop warning.
- DMI restructure (needed for laptop warning).
- Chip driver fixes in patchwork.
No comment - I don't have any chip driver fixes pending.
- All unacked board support patches (do we want to mark those boards as
My board enables:
Abit IP35 Pro: http://patchwork.coreboot.org/patch/843/
- Board enable works, but we have one report that the BIOS backflashes
itself. No idea what happens.
Maybe two BIOS chips, selectable with GPIO?
- Board enable works: http://coreboot.pastebin.com/f6fd7daa3
IMHO ready for commit. Review of the 948 appreciated.
I don't have VIA datasheets, sorry.
HP Vectra VL420SFF: http://patchwork.coreboot.org/patch/919/
- Board enable works, but DMI identifier was not tested. Confirmation
for non-DMI is at http://patchwork.coreboot.org/patch/696/
Intel SE440BX-2: http://patchwork.coreboot.org/patch/842/
- Board enable does not work. GPO register on PIIX4 is for strange
reasons read-only, see http://www.flashrom.org/pipermail/flashrom/2010-February/002272.html
Uh hm. No idea.
HP Vectra VL400: http://patchwork.coreboot.org/patch/721/
- Board enable works, I was unsure about match quality. But
http://pastebin.com/f6c509179 claims that both IDs I used for matching are really VL400 specific.
Asus M2NBP-VM CSM: http://patchwork.coreboot.org/patch/717/
- Board enable works, only confirmation was on IRC. No response on
MSI MS7207: http://patchwork.coreboot.org/patch/659/
- Untested. User got impatient and used another way of flashing - no
response on ping.
I'd say we commit those which don't have an ack, but add a marker that will enable board detection and output a message "please specify -p internal:board=ok and notify firstname.lastname@example.org" instead of running the board enable. That should be safe and still get us the reports we want.
- Always read the chip before writing, and only issue the scary error
message if flash contents changed.
Improved suggestion: If flash contents changed, blindly write the old image (without verifying during write), and if correct afterwards, also don't bail out. This should help on partly write protected chips.
Doesn't work with the current code because the current code has unconditional erase at the start of write. David Hendricks wanted to look into stripping the erase out of all write functions and do it from generic code instead. With a few other patches, that would give us partial write (and that's what we need to recover).
For 0.9.2 I'd be happy with "don't warn if not broken". IMHO autorecovery is too tricky for 0.9.2.