[flashrom] Releasing 0.9.2?

[Carl-Daniel Hailfinger]

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).
>>     
> Is in.
>   

Great, thanks.


>> - Chip driver fixes in patchwork.
>>     
> No comment - I don't have any chip driver fixes pending.
>
>   
>> Medium priority:
>> - All unacked board support patches (do we want to mark those boards as
>> untested?)
>>     
> 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?


> Abit VT6X4: http://patchwork.coreboot.org/patch/955/ depending on
> http://patchwork.coreboot.org/patch/948/
>  - 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
> ping.
>
> 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 flashrom at flashrom.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.
>>     
> [x] seconded!
>
> 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.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth