[flashrom] W836xx: HP Mini 110-3700: flashrom -V

Olivier Langlois olivier at olivierlanglois.net
Mon Jan 28 07:59:50 CET 2013


> > That being said, I am a little bit surprised by your diagnostic because
> > I have gathered information as suggested on
> > 
> > http://www.coreboot.org/Laptop
> > 
> > and superiotool has reported:
> > 
> > Found ITE IT8502E/TE/G (id=0x8502, rev=0x1) at 0x4e
> > 
> > Since the first entry in the Laptop survey table on the same page is
> > reporting a successful installation with the same superio, I was hoping
> > that my quest would be trivial. Apparently things aren't that simple
> 
> But in that case the flash IS LPC not SPI so no translation is needed.
> I am not sure if the flash chip is attached to the SB directly or
> shared with the EC, but the bus difference alone would explain the
> difference. 

I have induced you in error. The person that has been able to
successfully flash his laptop had a ITE8510. Similar names, probably
totally different beasts.
> 
> > So the same superio chip can be configured to work with LPC or SPI
> > flash?
> 
> I am not sure about that, but I think so. The main question in general
> is though if the firmware for the host (usually a BIOS) shares the same
> flash chip with the firmware for the EC. Since most(?) ECs execute the
> code directly from flash it is of course not a good idea to erase the
> flash while the EC fetches instructions from it... :) The host needs to
> tell the EC to stop executing that code before flashing and reenable it
> afterwards, see also:
> http://flashrom.org/Laptops
> http://flashrom.org/Laptop_enable
> 
I have read these links and I have now a much better understanding of
the size of the task waiting me than I did when I sent my first e-mail
to the list!

Among other things, now that I realized that the bios contains EC code
for which no public doc exists, it seems improbable that coreboot ever
'officially' support my hardware as the only way to support it would be
to extract the EC code from a vendor BIOS and copy it.

There is no way you can come up with original code without doc or maybe
I am not creative enough to see ways.

I have a copy of my vendor BIOS. The file is exactly 2MB so this boosts
my confidence level that the flash chip that I saw is the good one.

I'll study it a little bit to see if I can extract some insights. How
about analyzing the vendor flash utility? Can that be useful?

I was considering getting myself an external programmer. paraflash
sounds really cool but unfortunately not very useful with SPI.

>From my research for now, my best option seems to be a Bus pirate. It
seems like the most versatile choice. On top of being a programmer, you
can apparently use it for sniffing and program flash without unsoldering
the chip.

Should that be enough or should I consider to mod my board by installing
a SOIC-8 socket on my board?

One last question. Where could I get some info about usual BIOS file
format and disassembly tools?

The tool that I have used to decrypt the bios file creates a dump of the
BIOS consisting of 20-25 small bin files having a UUID as name. Is this
a pure invention of the tool that I have used or UUIDs are really
commonly used to delimitate the different BIOS sections?

I am using objdump as dissembler. I saw a reference to IDAPRo on
flashrom.org. Is there other alternative? For having done some
disassembly reading 10-15 years ago, one feature that I really liked
from the tool that I did use is that it was replacing/annotating
instructions with an address with the string value if the address was
pointing on a string.

It was also replacing function address with a symbol name when possible.
Those 2 small features made a huge difference in the readability of the
output for inexperienced eyes....






More information about the flashrom mailing list