On Tue, 19 Mar 2013 16:12:43 +1100
James Cameron <quozl(a)laptop.org> wrote:
> G'day,
>
> I'm an Open Firmware developer working for One Laptop per Child.
>
> We have used the MX25U3235E chip in revision B1 of our XO-4 design,
> and I am trying to use flashrom (r1657) with a Bus Pirate to read from
> a chip.
>
> I see you pushed a patch for this chip in the past few days. A happy
> coincidence perhaps.
>
> Is there anything I can do to help you change TEST_UNTESTED to
> something else?
>
> (Sorry if this is an obvious question, but I have very little
> knowledge of flashrom, having used for the first time yesterday with a
> different chip. Mostly we program the chip from within Open
> Firmware.)
>
> I changed TEST_UNTESTED to TEST_OK_PR on my system, and captured the
> attached logs.
>
> While the identify worked, the read gave errors, and the output file
> contained 0xff only. We have never intentionally enabled any block
> protection on this chip.
>
Hello James,
the .tested field is only used for QA and telling the user about it.
Changing it does not influence functionality.
If you are in a hurry skip this paragraph. :)
I am a bit puzzled at the moment regarding the (read) log. If you look
at the detailed output of the contents of the status register at line
132 ff. you see that flashrom (mistakenly) reads 0xFF, which leads to
the assumption that a block protection is enabled (see bottom of page
26 in the datasheet of the chip; that's quite a standard layout of a
SPI flash status register...). It then tries to disable the
"protection" and fails because another bit in the status register - the
WIP bit - remains at 1.
I have no idea why it (always) reads 0xFF from the status register... I
have checked the opcode and it is correct, and there is nothing fancy
about... apart from one thing I just noticed which you could test:
in spi_read_status_register() in spi25_statusreg.c replace 2 with 1 in
the array declaration readarr[2] so that this line becomes
unsigned char readarr[1]; /* JEDEC_RDSR_INSIZE=1 but wbsio needs 2 */
wbsio is our driver for a very annoying winbond SPI master and as the
fixme in the function says, this hack should not be in the generic code.
If the macronix chip does not repeat the status register contents when
one reads more than one byte after sending the RDSR (read status
register) opcode (which chips usually do) but 0xFF then we have found
the culprit.
PS: please send further mails to flashrom(a)flashrom.org - our mailing
list, thanks.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi Vadim,
thanks for your mail. I have added the flashrom mailing list in CC:
because we should develop a generic way to handle DualBIOS and similar
techniques.
On 09.04.2010 08:12, Vadim Girlin wrote:
> I'm going to try coreboot on Gigabyte GA-MA770-UD3.
> It's AMD 770 (RX780 / SB700).
>
> My motherboard supports hardware dual bios - with two chips on it.
> I'm going to try flashing backup chip and boot from it. It seems to be
> possible - I've tested it (flashing at least). Chips on this board could
> be switched by changing bit 0 at undocumented register EF on LDN 7 of
> IT8720. I can use slightly patched flashrom for accessing any chip I
> want without any problems. And this is tested many times.
>
> My idea is to use backup chip for debugging - that always keeps my
> chance to reboot from main bios chip. And removes the need for
> desoldering etc.
>
> And second problem is that original bios is checking second chip - and
> trying to recover it by flashing the bios from main chip on reboot?
> rewriting coreboot. AFAICS this could be solved by including some
> signatures etc. It seems to be easy to find out. May be someone is
> working on this?
>
> BTW I can send the patch for flashrom - but I think that with
> information I mentioned above somebody could make it much better than my
> ugly hack. I hope the regs should be the same for all latest Gigabyte
> MBs using IT8720/18
>
It would be great if you could send that patch. It will help us make a
flashrom design decision that works for all boards with multiple flash
chips.
By the way, some of us have good contacts at ITE, so we can ask ITE for
details about the undocumented registers.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
The restricted opcode is not so unusual. We have encountered the same
with some thinkpads. Vendors don't need proper RDID because they
usually know which chip is installed so they don't have to support 300+
chips like flashrom does.
On Mon, 29 Apr 2013 14:47:35 +0400
Vasiliy Vylegzhanin <6vasia(a)gmail.com> wrote:
> 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
> 0x58: 0x07ff0580 FREG1: BIOS region (0x00580000-0x007fffff) is read-write.
> 0x5C: 0x057f0003 FREG2: Management Engine region (0x00003000-0x0057ffff) is read-write.
> 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write.
> 0x64: 0x00000fff FREG4: Platform Data region is unused.
> 0x74: 0x00000000 (PR0 is unused)
> 0x78: 0x00000000 (PR1 is unused)
> 0x7C: 0x00000000 (PR2 is unused)
> 0x80: 0x87ff0770 PR3: WARNING: 0x00770000-0x007fffff is read-only.
> 0x84: 0x875f0580 PR4: WARNING: 0x00580000-0x0075ffff is read-only.
The protected regions are a bigger problem. This configuration protects
almost the complete BIOS region and this can not be disabled at
runtime. Does the vendor offer updates for the BIOS? Did you look into
the BIOS configuration menu if there is a switch to allow BIOS
modifications?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi,
before we change flashrom to work with current layout requirements, we
should summarize the features we need/want, and then decide how to
handle the individual layout regions internally.
Terms:
"write strategy" describes a combination of erase+write commands with a
given block size, touching some blocks.
"read protected" describes a region which can not be read.
"write protected" describes a region which can not be written.
"write once" describes a region which can be written exactly once in the
chip lifetime.
If you add a feature to the list, please give it a nickname so we know
which feature people are referring to. Some of the features below might
not be desirable, but I want to list them anyway so we can explicitly
declare them as unsupported if needed.
fullwrite-unrestricted: Write a chip-sized image, no special read/write
restrictions of the chip, no layout file needs to be specified. Default
write case right now.
fullwrite-noread: Write a chip-sized image, reading anything from the
chip is not possible. Many DVD writers fall in that category. No
verification, violates our reliability guarantees.
fullwrite-postread: Write a chip-sized image, reading anything from the
chip is only possible after write. Chips which are read-locked until a
full erase/write fall in that category. Do those exist as standalone
flash chips or only integrated into processors?
fullwrite-partialread: Write a chip-sized image, reading is only
possible in some chip regions. Only partial verification, violates our
reliability guarantees.
fullwrite-partialwrite: Write a chip-sized image, but writing is only
possible in some regions. This is obviously a conflict unless the image
has the same contents as the chip in the write-protected regions and
there is a possible write strategy for the whole image which does not
touch the write-protected regions. Should flashrom always refuse this
scenario, or only refuse it in case of conflicts?
partialwrite-unrestricted: Write only parts of an image, the rest of the
chip contents is kept, no special read/write restrictions.
partialwrite-partialread: Write only parts of an image, the rest of the
chip contents is kept, reading is only possible in some chip regions. If
no read-protected regions are written and a suitable write strategy
exists, should flashrom warn? If a read-protected region is written,
should flashrom warn/refuse due to reliability requirements?
partialwrite-partialwrite: Write only parts of an image, the rest of the
chip contents is kept, writing is only possible in some chip regions. If
no write-protected regions are written and a suitable write strategy
exists, should flashrom warn? flashrom will refuse to write a
write-protected region.
fullread-unrestricted: Read the full chip, no special read restrictions
of the chip.
partialread-unrestricted: Read only parts of a chip, no special read
restrictions of the chip.
partialread-partialread: Read only parts of a chip, some regions are
read-protected. flashrom should refuse to read any read-protected regions.
partialread-imagefiller: If only parts of a chip are read and the read
image has full chip size, what should be used as filler for unread
regions? 0x00 or 0xff?
partialread-layout-imagesize: If only parts of a chip are read, should
the read image still have full chip size with all read regions filled in
at the respective locations?
partialread-layout-split: If only parts of a chip are read, should it be
possible to write each region (or a combination thereof) to a separate
image file, and would that mapping be specified in the layout file?
partialwrite-layout-split: If only parts of a chip are written, should
it be possible to collect each part of the new image from a separate
image file, and would that mapping be specified in the layout file?
readwrite-protection-time: Which read protection and write protection
times exist? Temporary lock until unlock, temporary lock until chip soft
reset, temporary lock until chip/programmer hard reset (powerdown or
reset line), permanent eternal lock.
readwrite-protection-type: Which read protection and write protection
types exist? Programmer lock (e.g. Intel SPI), hardware chip lock (WP
pin), software chip lock (chip command).
readwrite-protection-interaction: How should we express this situation:
A region is write-locked with a software chip lock, but to remove that
software chip lock, a hardware chip lock has to be disabled first, then
the software chip lock can be disabled.
partialaccess-crash: Some regions in the chip are really off-limits and
will cause an unrecoverable error (system crash) when accessed (read or
write). That seems to be the case for some EC/flash interactions.
Comments? Any forks of flashrom (e.g. chromium) which need
infrastructure features not mentioned above?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Hi All
> Using flashrom (with IMC patch), flash coreboot base build for AMD Persimmon
> board.
> Passes verifying flash; but IMC resume failed.
> Poweroff - doesn't fully power off. Stops with "Power down."; manual poweroff
I guess because coreboot does not provide any IMC firmware here.
>
> ---
>
> Reboot system, and able to ssh into system; no VGA from the board itself.
> No VGA is expected because I did not add a vBios to the coreboot image.
>
> ---
>
> Trying to flash back the AMI original bios; fails with:
>
> root@debian:~# ./flashrom_imcpatch -p internal -w AMI.rom
> flashrom v0.9.6.1-r1564 on Linux 2.6.32-5-686 (i686)
> flashrom is free software, get the source code at http://www.flashrom.org
>
> Calibrating delay loop... OK.
> coreboot table found at 0xc717d000.
> Found chipset "AMD SB7x0/SB8x0/SB9x0". Enabling flash write... (Shutting down IMC failed!)
> FAILED!
> FATAL ERROR!
> Error: Programmer initialization failed.
Here I guess the bit which is telling that IMC is active survived reboot.
> ---
>
> Power off, unplug board power supply, moving both jumpers (JP12, JP13 on pin 2-3) for 30 seconds to clear CMOS settings.
> Reboot; Retry flashrom AMI; outputs:
>
> root@debian:~# ./flashrom_imcpatch -p internal -w AMI.rom
> flashrom v0.9.6.1-r1564 on Linux 2.6.32-5-686 (i686)
> flashrom is free software, get the source code at http://www.flashrom.org
>
> Calibrating delay loop... OK.
> coreboot table found at 0xc717d000.
> Found chipset "AMD SB7x0/SB8x0/SB9x0". Enabling flash write... OK.
This confirms that IMC is "dead" here, there is no MBOX interface no bit which
tells if IMC is active.
> Found SST flash chip "SST25VF032B" (4096 kB, SPI) at physical address 0xffc00000 .
> Flash image seems to be a legacy BIOS. Disabling coreboot-related checks.
> Reading old flash chip contents... done.
> Erasing and writing flash chip... ERASE FAILED at 0x00000000! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x00000fff: 0x200
> ERASE FAILED!
> Reading current flash chip contents... done. ERASE FAILED at 0x00000008! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x00007fff: 0xfff
> ERASE FAILED!
> Reading current flash chip contents... done. ERASE FAILED at 0x00000008! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x0000ffff: 0x1fff
> ERASE FAILED!
> Reading current flash chip contents... done. ERASE FAILED at 0x00000008! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x003fffff: 0x7ffff
> ERASE FAILED!
> Reading current flash chip contents... done. ERASE FAILED at 0x00000000! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x003fffff: 0x80000
> ERASE FAILED!
I admit this is strange. The only explanation is that the IMC tries to run
non-existing stuff. So it in fact tries to execute something and there is no way
it could tell us that it is active. Not sure what to do here. I know there is
some soft strap override but I dont know if current strap can be read to detect
if IMC is enabled but actually not doing anything.
Maybe this is getChipSysMode() in CIMX.
> Power on
> Nothing
>
Yes because it erased most of the flash ;)
So... This is going to be complicated. Can you please send me in private both
images? Or paste URL where i can get ami bios image.
I will check if IMC firmware is there or not (I guess none in coreboot). What we
could possibly do is to re-add a firmware to coreboot image. But we would have
to override the straps and activate the imc. There is also
BuildParameters.ImcEnableOverWrite in SB800 CIMX.
What is your goal here anyway? To have smooth transition to coreboot? Or you
just reported this issue?
I guess we need to implement some safety checks that if IMC strap is always
enabled then IMC firmware must exist and ideally be same as in flash.
But first we need to know what CIMX is doing.
if
1) EC is disabled and it is re-enabled by soft strap
This seems not to be the case, because
if (validateImcFirmware (pConfig)) {
softwareToggleImcStrapping (pConfig);
It will enable the IMC only if valid firmware is found. And for CIMX800 we are
not doing this, only hudson has AMD firmware.
2) if it is enabled by some hardware strap
This could be detected most likely by getChipSysMode() in this case we need to
disallow write of firmware which has no IMC code. Here are couple of problems,
what to do if firmware is there, but different for example... Or with coreboot
may happen it is on different location. Franly I don't know how to deal with
that because for this I would need detailed knowledge of the firmware itself. I
only disassembled that and I can see it just spins in memory when 0xb4 is
invoked and waits for 0xb5 (and I have seen sometimes for 0xb6)
And this gets worse because Hudson has USB firmware and Gigabit ethernet
firmware. Which are are same PITA.
Thanks
Rudolf
> ---
>
> Cheers,
> Michel.
>
>
> -----Original Message-----
> From: Rudolf Marek [mailto:r.marek@assembler.cz]
> Sent: Saturday, March 30, 2013 3:54 AM
> To: Racine, Michel
> Cc: Stefan Tauner; roxfan; frederic.temporelli(a)bull.net; wmkamp(a)datakamp.de; flashrom(a)flashrom.org
> Subject: Re: [flashrom] AMD - SP5100 - take SPI ownership (1/2)
>
> Hi,
>
> Found chipset "AMD SB7x0/SB8x0/SB9x0" with PCI ID 1002:439d. Enabling flash write...
> EC SIO is at 0x16e
> EC MBOX is at 0x3e
> (Shutting down IMC)
> SPI base address is at 0xfec10000
>
> This means that firmware correctly responded to the command and most likely moved itself to internal RAM.
>
> Verifying flash... VERIFIED.
>
> EC SIO is at 0x16e
> EC MBOX is at 0x3e
> (IMC resume failed!)
>
> This means that firmware was not able to continue at the end?
>
> I have a couple of questions:
>
> 1) did you perform full power cycle (even unplugging the PSU)?
>
> I suspect that the IMC may run even if main cpu is off. I also suspect it fully initializes only if performing this "cold boot".
>
> 2) what was the update? It was from original BIOS to coreboot? Does coreboot have a embedded IMC image? Does the IMC image start at the same location?
>
> What we could additionally check is if the IMC firmware location does not match in source and dest image, bail out. Or if the base addr has been changed.
>
> Thanks
> Rudolf
>
On Thu, 18 Apr 2013 18:02:37 +0200
Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote:
> andor had some problems with how coreboot configured the SPI controller.
> let's see if this hack fixes that.
while the patches are wrong... (fastReadEnable is a single bit), they
apparently improve the situation on boards where the spi controller is
not configured correctly.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
I have added some flashrom and linux logs which might be helpfull:
The USB 3 PCI card has the following system properties:
DRIVER=xhci_hcd
PCI_CLASS=C0330
PCI_ID=1033:0194
PCI_SUBSYS_ID=1033:0194
PCI_SLOT_NAME=0000:03:00.0
MODALIAS=pci:v00001033d00000194sv00001033sd00000194bc0Csc03i30
There is also a PCI NIC Intel 82541PI Gigabit Ethernet Controller
(8086:107c, BDF 02:0a.0) and a PCI soundcard installed.
Tried to read the flash rom out of the 82541PI Intel NIC without problems.
/sys/bus/pci/devices/0000:02:0a.0 of the Intel NIC also gives access to
"rom" which the USB 3 and the soundcard do not. I am not sure if that means
that the rom is not accessible at all or if Ubuntu just does not know how.
Thanks in advance, brgds
Philipp
-----Ursprüngliche Nachricht-----
Von: Philipp Post [mailto:Post.Philipp@googlemail.com]
Gesendet: Donnerstag, 24. Januar 2013 19:23
An: 'flashrom(a)flashrom.org'
Betreff: USB 3 PCI Card support (request to add device)
Good day,
following configuration:
- USB 3 PCI (not PCI-Express) card with RENESAS uPD720200A(Revision 4) USB
chip
and ATMEL AT25F512B (ATMEL 1138, 25F512B, SSH) rom chip in
- IBM NetVista 8305 Desktop PC - built year 2003
The issue with the card is that it needs a flash rom update to work with
Windows Vista and up, otherwise the device does not work at all in these OS
("device cannot start"). Windows XP with Renesas drivers and Linux Ubuntu
11.3 out of the box works fine.
RENESAS has a rom update for the chip and a flash update tool which however
does not work with PCI cards, but just chips soldered to mainboards. At
least this seems to me the reason why it does not work. Chip is recognized
but the RENESAS tool says "Can not load / access firmware". The tool has the
option to change the device / vendor id as well via .ini file.
The card used is the only PCI USB 3 card on the market and basically works
very well when it works - with max PCI speed of course, which means approx.
double speed of USB 2. The card exists in hardware version 1 (RENESAS chip
uPD720200A) and 2 (RENESAS chip uPD720202). I do just have access to
hardware version 1. The name of the manufacturer behind the card is unknown
to me, but it could be an ADDONICS product. I do not have a technical
drawing of the card and I fear I can not obtain one but I do have the card
itself.
My question: would it be possible to incorporate this card into flashrom?
Would be great if someone could do it as I do not have the necessary skills
to do it myself.
In case you need further information, please let me know.
Thanks in advance, brgds
Philipp
Links and further reading:
--------------------------
Card Information from different sellers (same card):
http://www.addonics.com/products/ad2u3pci.phphttp://eu.startech.com/Cards-Adapters/USB-3.0/Cards/2-Port-PCI-SuperSpeed-US
B-3-Card-Adapter~PCIUSB3S2
http://www.lindy.de/premium-usb-3-karte-2-port-pci/51082.html
ATMEL rom specification (contains info how to write rom images):
www.atmel.com/Images/doc3689.pdf
Renesas USB chip information:
http://www.renesas.eu/products/soc/usb_assp/product/upd720200a/index.jsp
RENESAS rom update 4.0.2.0 with Windows updater (32 + 64 Bit) and drivers:
http://www.station-drivers.com/page/renesas.htm
We need: "Firmware Version 4.0.2.0 pour uPD720200a"
RENESAS MS DOS flash update tool (which did not do the job):
http://www.computerbase.de/forum/attachment.php?attachmentid=283282&d=133832
3319
IBM NetVista 8305 Hardware Maintenance Manual:
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/netvista_pdf/24p2969.pdf
Hardware Ids:
Renesas Electronics USB 3.0 Host Controller:
PCI\VEN_1033&DEV_0194&SUBSYS_01941033&REV_04\5&25043F3&0&0048F0
Renesas Electronics USB 3.0 Root Hub
NUSB3\ROOT_HUB30\6&2D374EF3&2