[flashrom] testing DELL Dimension 4100

[Stefan Tauner]

On Sat, 29 Dec 2012 19:37:18 +0000 (GMT)
Bertho Grandpied <y31415926536 at yahoo.fr> wrote:

> 
> 
> --- Stefan Tauner <stefan.tauner at ....at> wrote :
> 
> > Czerno wrote ! 
> > this is telling us that we failed to set bit 0 of BIOS_CNTL.
> > this bit is named "BIOS Write Enable"...
> > the reason why we failed to set it, is that bit 1 is also set, which
> > indicates that the BIOS will be called whenever one sets bit 0.
> 
> That register, I gather, would be configuration register 4e in the ISA (South) bridge, right? Thru which mechanism would an attempt to change that bit "call the BIOS", as you put it ? SMI ? I'm not familiar with Intel chipsets - do you have an URL for the datasheet thereof please ?

yes, changing the bit triggers an SMI request.

http://www.intel.com/assets/pdf/specupdate/298242.pdf
it does not contain a lot of details though - everything else is not
public.

> > obviously in this machine (and usually always) the BIOS then just
> > unsets the bit again... no flash writes possible without
> > telling the
> > BIOS to stop this behavior... which is not documented.
> 
> Well, I could try to find out by inspection of Dell's BIOS updater. 
> However as you remarked, the locking bit is for writes only and wouldn't prevent flashrom from reading Flash's contents, even less prevent Flashrom from detecting the flash chip. 
> 
> > This does however not explain why we do not find a flash
> > chip. Most
> > probably it is not supported yet. The EC (SMSC) might be
> > involved too.
> > If you care please tell us the markings on the flash chip.
> 
> It might take some time before I find an opportunity to inspect that board. Meanwhile, there's no software way to probing harder ?

other flash utilities (uniflash, maybe vendor tools?), but they are for
dos usually.

> > Support for
> > reads should be easy to add, but writes won't happen at
> > least on that  board...
> 
> Except, perhaps, by finding the secret handshake through the 'reversing' of Intel/Dell BIOS updaters. 
> I suspect Dell used/customised a solution provided to them by Intel.

i dont know about older stuff but in the meanwhile they have been using
a method where user space apps supplied the image in a ram buffer via
an API and the BIOS updated itself on the next reboot. i have never
seen something like that elsewhere (OTOH i have not seen too much of
such things), so this is probably dell-only.
the SMI approach like it is used here is more often used, e.g. by
intel's own boards.

reversing the scheme is of course possible, but no one bothered in the
past and i dont assume anyone will now (ancient hardware).

> What's more, the unlocking procedure could apply to a wide range of boards (natural lazyness...) - don't you have keys already to comparable bioses and mobos ?  

using this kind of protection is not too common. it was even less in the
time of ich2 AFAIK. usually the write protection is done mainly by
pulling the #WP pin(s) low via a GPIO (of the sb or sio). flashrom
supports a huge number of such methods which are board specific. see
board_enable.c (large table at the end).

if you find out something useful and/or generic i am happy to integrate
it...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner