Testing Dell Dimension 4100 : Pentium III and Intel 815 (82815 + 82801BA, ICH2) based desktop machine from ca yr 2000.
This chipset should be supported IIUC, but flash chip is not detected :(
Flashrom was run under MS-DOS (log appended) - notice how I had to specify the "not-a-laptop" override because of insufficient DMI tables. Please notice also the "warning" about being unable to set Bios Control at 0x4e : thus the question arises, is that Intel chipset variant supported or is it not ?
Additionally I ran 'Linux/sensors-detct' FWIW : "probing for Super-I/O at 0x2e/2f", "SMSC LPC47M10x/112/13x" fan sensors were found.
Any further software probe I can try before opening up the box in the hope of finding what BIOS chip was used by visual inspection ?
Regards... __________________________________________________________________ flashrom v0.9.6.1-r1624 on MS-DOS 7 (i686) flashrom was built with libpci 3.1.5, GCC 4.4.4, little endian Command line (7 args): c:/flashrom/flashrom.exe -p internal:laptop=this_is_not_a_laptop -V -r DELL.BIN -o READ.LOG Calibrating delay loop... OS timer resolution is 50000 usecs, 486M loops per second, 10 myus = 0 us, 100 myus = 0 us, 1000 myus = 0 us, 10000 myus = 0 us, 200000 myus = 270000 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Dell Computer Corporation " DMI string system-product-name: "XPS-Z " DMI string system-version: " " DMI string baseboard-manufacturer: "Intel Corporation " DMI string baseboard-product-name: "D815EEA " DMI string baseboard-version: "AAA10383-402 " DMI string chassis-type: "Unknown" DMI chassis-type is not specific enough. ======================================================================== WARNING! You may be running flashrom on an unsupported laptop.(....) You have been warned. ======================================================================== Proceeding anyway because user forced us to. Found chipset "Intel ICH2" with PCI ID 8086:2440. Enabling flash write... BIOS_CNTL = 0x02: BIOS Lock Enable: enabled, BIOS Write Enable: disabled WARNING: Setting Bios Control at 0x4e from 0x02 to 0x03 on ICH2 failed. New value is 0x02. FAILED! The following protocols are supported: FWH. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0x93, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0x93, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0x93, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xb2, id2 0xf1, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0x93, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0x93, id2 0x26, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. Restoring PCI config space for 00:1f:0 reg 0x4e _________________________________________________________________
On Sat, 29 Dec 2012 16:18:15 +0000 (GMT) Bertho Grandpied y31415926536@yahoo.fr wrote:
Testing Dell Dimension 4100 : Pentium III and Intel 815 (82815 + 82801BA, ICH2) based desktop machine from ca yr 2000.
This chipset should be supported IIUC, but flash chip is not detected :(
Flashrom was run under MS-DOS (log appended) - notice how I had to specify the "not-a-laptop" override because of insufficient DMI tables. Please notice also the "warning" about being unable to set Bios Control at 0x4e : thus the question arises, is that Intel chipset variant supported or is it not ?
hi,
(intel) chipsets can be configured by the bios in a lot of ways and since some configuration options are directly targeted at restricting flash chip access, chipset support as defined by flashrom/us does not necessarily mean that flashrom can actually access the flash chip freely. most of the time this does only affect writing.
WARNING: Setting Bios Control at 0x4e from 0x02 to 0x03 on ICH2 failed. New value is 0x02. FAILED!
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. and 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. Dell has been known for doing this for a long time.
Since this system is so old, I wont add it to our list of (un)supported hardware...
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. Support for reads should be easy to add, but writes won't happen at least on that board...
--- Stefan Tauner <stefan.tauner@....at> wrote :
Czerno wrote !
Testing Dell Dimension 4100 : Pentium III and Intel 815 (82815 + 82801BA, ICH2) This chipset should be supported IIUC, but flash chip is not detected :(
question arises, is that Intel chipset variant supported or is it not ?
(intel) chipsets can be configured by the bios in a lot of ways and since some configuration options are directly targeted at restricting flash chip access, chipset support as defined by flashrom/us does not necessarily mean that flashrom can actually access the flash chip freely. most of the time this does only affect writing.
WARNING: Setting Bios Control at 0x4e from 0x02 to 0x03
on ICH2 failed.
New value is 0x02. FAILED!
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 ?
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 ?
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. 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 ?
Regards...
On Sat, 29 Dec 2012 19:37:18 +0000 (GMT) Bertho Grandpied y31415926536@yahoo.fr wrote:
--- Stefan Tauner <stefan.tauner@....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...
Stefan Tauner <stefan.tauner@....at> wrote :
Thanks for the hints and details (snipped for brevity).
Obviously, hacking such an old machine is not a priority of mine and since it is not a must for the advancement of flashrom either, further research will have to wait for better times; if I find something eventually, I'll surely let you and the list know...
Happy new year !
--- On Sunday, Dec. 30, Stefan Tauner wrote :
if you find out something useful and/or generic i am happy to integrate it...
Still not a priority, but with the help of system scanning utilities (viz. Everest, Aida) I have uncovered tasty motherboard details which, I think, might be useful : this DELL has in fact an Intel "Easton" D815EEA mobo; quick web searches reveal pertinent chipset details,
+ Intel 82815 GMCH (i.e. the North bridge) + Intel 82801BA (the Southbridge and more), + I82802AB Firmware hub.
If I am not mistaken, the latter - FWH - would be the responsible component for the flashing process. Can this knowledge help make Flashrom access the BIOS ? At least in read mode, since we know it won't write without further enabling sauce - do we have the recipe for this 'Intel inside' rig ?
Regards
On Sun, 30 Dec 2012 19:23:07 +0000 (GMT) Bertho Grandpied y31415926536@yahoo.fr wrote:
--- On Sunday, Dec. 30, Stefan Tauner wrote :
if you find out something useful and/or generic i am happy to integrate it...
Still not a priority, but with the help of system scanning utilities (viz. Everest, Aida) I have uncovered tasty motherboard details which, I think, might be useful : this DELL has in fact an Intel "Easton" D815EEA mobo; quick web searches reveal pertinent chipset details,
- Intel 82815 GMCH (i.e. the North bridge)
- Intel 82801BA (the Southbridge and more),
- I82802AB Firmware hub.
If I am not mistaken, the latter - FWH - would be the responsible component for the flashing process.
It is not responsible... it IS the flash chip ;) But according to this change notification it might not be true: http://smartdata.usbid.com/datasheets/usbid/2000/2000-q3/d1014230.pdf
No idea which SST chip they used... but i guess both should be supported by flashrom. No idea why it is not detected.
Can this knowledge help make Flashrom access the BIOS ? At least in read mode, since we know it won't write without further enabling sauce - do we have the recipe for this 'Intel inside' rig ?
Someone with more knowledge about FWH than me has to look at it. It would certainly help if we would know which flash chip is really inside it...
On 31/12/12 18:21, Stefan Tauner wrote:
Someone with more knowledge about FWH than me has to look at it. It would certainly help if we would know which flash chip is really inside it...
I'm pretty sure that the detection of FWH devices requires writing to the address space used and you cannot do that as you cannot set the BIOS WE bit in the chipset. So unless you can get around the SMI protection of that bit then there is no way to detect the chip in use. Even if you did detect it, you still could not program it.
Andrew
"Stefan Tauner" wrote :
Someone with more knowledge about FWH than me has to look at it. It would certainly help if we would know which flash chip is really inside it...
I'll strip-search that machine as soon as possible ;=)
@ "Andrew Goodbody" :
I'm pretty sure that the detection of FWH devices requires writing to the address space used and you cannot do that as you cannot set the BIOS WE bit in the chipset. So unless you can get around the SMI protection of that bit then there is no way to detect the chip in use. Even if you did detect it, you still could not program it.
I'll check whether the BIOS also has locked access to SMRAM - usually it wasn't done at the time. If the SMRAM is accessible from outside SMM, it would be straightforward to bypass the protection (just replace an RSM instruction as the SMI "handler" ;-) Even otherwise, it might be possible to shunt BIOS initialisation by capturing execution after a hot CPU reset (not just init) to the CPU - although processor and chipset dependent, I don't know if it will be possible with this rig.
Happy new year to all !
Some time ago, "Andrew Goodbody" noted :
I'm pretty sure that the detection of FWH devices requires writing to the address space used and you cannot do that as you cannot set the BIOS WE bit in the chipset. So unless you can get around the SMI protection of that bit then there is no way to detect the chip in use. Even if you did detect it, you still could not program it.
And I responded :
I'll check whether the BIOS also has locked access to SMRAM
- usually it wasn't done at the time. If the SMRAM is
accessible from outside SMM, it would be straightforward to bypass the protection (just replace an RSM instruction as the SMI "handler" ;-)
Which was done successfully a mompent ago... BIOS was not locking the SMM settings on this Intel board fortunately, so replacing a plain RSM instruction at the SMI origin (A000:8000) took just a couple minutes' hacking, then for sure Flashrom was able to detect the FWH, to dump and also to update the flash image successfully :=)
This complete circumvention of the (idiotic) BIOS 'protection' has achieved my original purpose - be able to modify the BIOS ad libitum. I did not have to search for the specific GPIO or similar method which the official BIOS patchers use.
Regards
On 12/03/13 16:59, Bertho Grandpied wrote:
Some time ago, "Andrew Goodbody" noted :
I'm pretty sure that the detection of FWH devices requires writing to the address space used and you cannot do that as you cannot set the BIOS WE bit in the chipset. So unless you can get around the SMI protection of that bit then there is no way to detect the chip in use. Even if you did detect it, you still could not program it.
And I responded :
I'll check whether the BIOS also has locked access to SMRAM
- usually it wasn't done at the time. If the SMRAM is
accessible from outside SMM, it would be straightforward to bypass the protection (just replace an RSM instruction as the SMI "handler" ;-)
Which was done successfully a mompent ago... BIOS was not locking the SMM settings on this Intel board fortunately, so replacing a plain RSM instruction at the SMI origin (A000:8000) took just a couple minutes' hacking, then for sure Flashrom was able to detect the FWH, to dump and also to update the flash image successfully :=)
Good work. Well done.
Andrew
On Tue, 12 Mar 2013 16:59:26 +0000 (GMT) Bertho Grandpied y31415926536@yahoo.fr wrote:
Some time ago, "Andrew Goodbody" noted :
I'm pretty sure that the detection of FWH devices requires writing to the address space used and you cannot do that as you cannot set the BIOS WE bit in the chipset. So unless you can get around the SMI protection of that bit then there is no way to detect the chip in use. Even if you did detect it, you still could not program it.
And I responded :
I'll check whether the BIOS also has locked access to SMRAM
- usually it wasn't done at the time. If the SMRAM is
accessible from outside SMM, it would be straightforward to bypass the protection (just replace an RSM instruction as the SMI "handler" ;-)
Which was done successfully a mompent ago... BIOS was not locking the SMM settings on this Intel board fortunately, so replacing a plain RSM instruction at the SMI origin (A000:8000) took just a couple minutes' hacking, then for sure Flashrom was able to detect the FWH, to dump and also to update the flash image successfully :=)
Nice one, congratulations :) Maybe this could be transformed to a patch for flashrom... I would like to see your code (if any) in any case, can you publish it please?
This complete circumvention of the (idiotic) BIOS 'protection' has achieved my original purpose - be able to modify the BIOS ad libitum. I did not have to search for the specific GPIO or similar method which the official BIOS patchers use.
Because there is none... just the SMM protection (I guess).
-
Andrew Goodbody -
Bertho Grandpied -
Stefan Tauner