On Wed, 27 Jul 2011 18:20:19 +0200
Mattias Mattsson <vitplister(a)gmail.com> wrote:
> Hi all,
>
> I was able to run flashrom under Linux on PPC (big endian) hardware
> with two small modifications in internal.c and processor_enable.c (see
> attached patch). Not sure if this is the right way to do it but it
> seems to work for me.
>
i am resending this patch (unchanged) because patchwork did not pick it
up correctly. please do send one patch per mail only in the future
until we have something really working. :)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Some chips such as the ENE KB9012 internal flash require a write granularity of
128 bytes.
Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr>
---
flash.h | 1 +
flashrom.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/flash.h b/flash.h
index 2c2839f..24861ba 100644
--- a/flash.h
+++ b/flash.h
@@ -85,6 +85,7 @@ enum write_granularity {
write_gran_1bit, /* Each bit can be cleared individually. */
write_gran_1byte, /* A byte can be written once. Further writes to an already written byte cause
* its contents to be either undefined or to stay unchanged. */
+ write_gran_128bytes, /* If less than 128 bytes are written, the unwritten bytes are undefined. */
write_gran_264bytes, /* If less than 264 bytes are written, the unwritten bytes are undefined. */
write_gran_512bytes, /* If less than 512 bytes are written, the unwritten bytes are undefined. */
write_gran_528bytes, /* If less than 528 bytes are written, the unwritten bytes are undefined. */
diff --git a/flashrom.c b/flashrom.c
index d51a44c..c9c7e31 100644
--- a/flashrom.c
+++ b/flashrom.c
@@ -781,6 +781,9 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum
break;
}
break;
+ case write_gran_128bytes:
+ result = need_erase_gran_bytes(have, want, len, 128);
+ break;
case write_gran_256bytes:
result = need_erase_gran_bytes(have, want, len, 256);
break;
@@ -847,6 +850,9 @@ static unsigned int get_next_write(const uint8_t *have, const uint8_t *want, uns
case write_gran_1byte_implicit_erase:
stride = 1;
break;
+ case write_gran_128bytes:
+ stride = 128;
+ break;
case write_gran_256bytes:
stride = 256;
break;
--
1.9.1
Hi Mark,
would it be possible for you to generate a log file using the additional
parameter
--output logfile.txt
when doing a read of the flash chip, then send that log file to us?
That would help us to finally merge support for the VT8251 chipset in
your point-of-sale IBM/Toshiba AnyPlace Kiosk Model 48xx series. We have
a strict rule that flashrom must be 100% reliable and thus we keep log
files for any newly supported/tested chipset around for reference. Your
log file would be used as reference for VT8251.
That said, it would be very interesting to know where the settings are
actually stored. Have you looked into the top 128 bytes of NVRAM? Maybe
there is another flash chip? Is there any way to trace what the
save/restore tool does (i.e. does it run on Linux)?
Regards,
Carl-Daniel
On 28.10.2015 23:25, Rowlinson Mark wrote:
> Hi Carl-Daniel,
>
> That change does allow the chipset to be recognised and it will write out the ROM. It seems to be the BIOS code only (no settings) as it doesn't change if I change any settings within the BIOS.
>
> I've been directed to a save/restore utility that comes on the BIOS update image and it seems the last version actually accesses the data I'm interested in so I'm investigating this route at the moment.
>
> Best Regards,
> Mark Rowlinson
>
> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net]
> Sent: 24 October 2015 09:22
> To: Rowlinson Mark <Mark.Rowlinson(a)uk.fujitsu.com>; flashrom(a)flashrom.org
> Subject: Re: [flashrom] Flash chip/chipset not found
>
> Hi Mark,
>
> this is a VIA VT8251 PCI to ISA Bridge you're using.
>
> I think Stefan Tauner (in CC) already was discussing something similar here:
> http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html
> That email even has a patch attached.
>
>
> On 22.10.2015 22:24, Rowlinson Mark wrote:
>> Thanks for the swift response, I have attached output from the command requested.
>>
>> The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx.
> Heh, would be fun to add this to our tests.
>
> Regards,
> Carl-Daniel
>
Unfortunately I don't have any soldering tools or experience, so if you
could give an advice
about ISP programming (In-System-Programming/In-Situ-Programming) , it
will be super helpful!
I teardown a bricked laptop, removed AC power, laptop's power battery,
and even a small CMOS battery,
and now I am trying to write a working BIOS image to laptop's SPI flash
chip using a SOIC8 test clip.
But here is a problem: I could read a dump from this BIOS chip without
problems, however
it fails when I am trying to write - so the contents of BIOS flash chip
are remaining unchanged.
Luckily I found out this helpful wiki page - http://flashrom.org/ISP ,
which describes common problems
with this ISP method of flashing, as well as gives 3 hints for solution!
Sadly this page is currently down,
so here is a screenshot: http://i.imgur.com/SJEYHR2.png
1. - tried to make shorter wires, less than 10cm as they recommend - it
did not help
2. - soldering is out of possibility, cant do it, and also: wires are
already short and they are good quality (pure copper)
3. - This hint looks more promising, but I need help in understanding
this piece of information:
"disconnect Vcc from the programmer and power it with its normal PSU"
If I understand correctly, by Vcc they mean Vcc pin of the BIOS flash
chip.
But if I disconnect Vcc from the programmer, what is "normal PSU" which
should power this Vcc pin?
Should I connect to motherboard a laptop's power battery, or small CMOS
battery, or AC adapter of laptop,
so that this Vcc pin would be powered by them, or it is forbidden to do
it while using SPI programmer in the same time?
Or its better to try to power Vcc of flash chip from "USB to TTL"
adapter - which has this 3V3 (3.3V) voltage pin?
Yours faithfully,
Robert Brown
<span id=m2wTl><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Get the Free email that has everyone talking at <a href=http://www.mail2world.com target=new>http://www.mail2world.com</a><br> <font color=#999999>Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More!</font></font></span>
This is mostly achieved by fixing or refining the inclusion of header
files and replacing glibc-specific ifdefs with more generic ones.
- <sys/io.h>: Contains iopl(2) and x86 I/O port access functions (inb, outb etc).
Generally Linux-specific but also availble on debian/kFreeBSD.
Provided by glibc as well as musl and uclibc.
Include it if we are running Linux or if glibc is detected.
- <sys/fcntl.h>: should be (and is) replaced by <fcntl.h> (without the
"sys" prefix).
- <linux/spi/spidev.h>: Does not include all necessary headers, namely
_IOC_SIZEBITS that is used in the definition of
SPI_MSGSIZE is not brought in via <linux/ioctl.h>
but instead we relied so far on glibc's including
it via <sys/ioctl.h>. Change that to explicitly
including <linux/ioctl.h>.
- <endian.h>: Would also be available in musl but there is no easy way
to detect it so we do not try yet.
The bug report and initial patches were
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou(a)trabucayre.com>
Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
---
New version because the sys/io.h change was actually breaking Debian/kFreeBSD!
Moved it down where all the IN[BWL]/OUT[BWL] definitions are.
hwaccess.h | 14 ++++++++------
linux_spi.c | 5 +++--
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/hwaccess.h b/hwaccess.h
index 3e46192..390f0e4 100644
--- a/hwaccess.h
+++ b/hwaccess.h
@@ -26,12 +26,6 @@
#include "platform.h"
-#if IS_X86
-#if defined(__GLIBC__)
-#include <sys/io.h>
-#endif
-#endif
-
#if NEED_PCI == 1
/*
* libpci headers use the variable name "index" which triggers shadowing
@@ -115,6 +109,7 @@
#if !defined (__FLASHROM_BIG_ENDIAN__) && !defined (__FLASHROM_LITTLE_ENDIAN__)
/* Nonstandard libc-specific macros for determining endianness. */
+/* musl provides an endian.h as well... but it can not be detected from within C. */
#if defined(__GLIBC__)
#include <endian.h>
#if BYTE_ORDER == LITTLE_ENDIAN
@@ -204,6 +199,13 @@ cpu_to_be(64)
#if NEED_PCI == 1
#if IS_X86
+/* sys/io.h provides iopl(2) and x86 I/O port access functions (inb, outb etc).
+ * It is included in glibc (thus available also on debian/kFreeBSD) but also in other libcs that mimic glibc,
+ * e.g. musl and uclibc. */
+#if defined(__linux__) || defined(__GLIBC__)
+#include <sys/io.h>
+#endif
+
#define __FLASHROM_HAVE_OUTB__ 1
/* for iopl and outb under Solaris */
diff --git a/linux_spi.c b/linux_spi.c
index 26725e1..19b4965 100644
--- a/linux_spi.c
+++ b/linux_spi.c
@@ -22,13 +22,14 @@
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
-#include <sys/fcntl.h>
+#include <fcntl.h>
#include <errno.h>
#include <ctype.h>
#include <unistd.h>
+#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>
-#include <sys/ioctl.h>
+#include <linux/ioctl.h>
#include "flash.h"
#include "chipdrivers.h"
#include "programmer.h"
--
Kind regards, Stefan Tauner
Hi Mark,
this is a VIA VT8251 PCI to ISA Bridge you're using.
I think Stefan Tauner (in CC) already was discussing something similar here:
http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html
That email even has a patch attached.
On 22.10.2015 22:24, Rowlinson Mark wrote:
> Thanks for the swift response, I have attached output from the command requested.
>
> The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx.
Heh, would be fun to add this to our tests.
Regards,
Carl-Daniel
Hi Mark,
On 21.10.2015 16:18, Rowlinson Mark wrote:
> I have a 32bit touch screen device running CentOS 5.2 which has some of its BIOS settings accessible in /dev/nvram and others elsewhere else (that's why I've been loooking at flashrom).
> I have tried later distributions (CentOS 6.7 and the System Rescue CD) and they both report the following:
> [root@server ~]# /var/tmp/flashrom-0.9.8/flashrom -p internal
> flashrom v0.9.8-r1888 on Linux 2.6.32-573.el6.i686 (i686)
> [...]
> WARNING: No chipset found. Flash detection will most likely fail.
> No EEPROM/flash device found.
It seems we have to add some PCI IDs to our southbridge table.
Do you have an exact name of the machine in question?
> What information is needed to identify the chipset in use so support can be added for these devices?
(as root)
lspci -nnvvvxxx
That should be sufficient for us to find out the southbridge and some of
its settings.
Regards,
Carl-Daniel