With the attached patch it is no longer necessary to have an extra
dependency step.
--
coresystems GmbH . Brahmsstr. 16 . D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 . Fax: +49 761 7664613
Email: info(a)coresystems.de . http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg . HRB 7656
Geschäftsführer: Stefan Reinauer . Ust-IdNr.: DE245674866
Hello,
I tried out flashrom on an ASUS A8N-VM CSM board: read seemed to go fine, but
write failed. Information about the board:
http://www.asus.com/product.aspx?P_ID=JBqqlpj4cspbSa3s
flashrom -V, lspci -nnvvxxx, superiotool -deV, flashrom -rV and flashrom -wV
output is attached. The BIOS I was trying to write was the rev 1001 one
available from the above ASUS page.
Per agaran's and roysjosh's friendly help on IRC I checked the BIOS I read
with -r with -v and it says VERIFIED so I suppose I'll go ahead and reboot
later today.
One note about the board testing Wiki page you may want to clarify:
"To check if you can read the existing BIOS image from the chip, run flashrom
-r backup.bin. Make sure that backup.bin contains a useful BIOS image. (Some
chipsets will return 0xff for large areas of flash without any error
messages.)"
For a BIOS newbie like me, the remark in parenthesis doesn't tell much - is it
a good or a bad sign if a chipset returns 0xff for large areas of flash
without any error messages? (Bad, I guess ;))
The internal programmer needs correct information about flash_base and
chip window top/bottom alignment on non-x86 before it can be used. Abort
any internal programmer action for now until the code is fixed.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-disable_internal_nonx86/internal.c
===================================================================
--- flashrom-disable_internal_nonx86/internal.c (Revision 1013)
+++ flashrom-disable_internal_nonx86/internal.c (Arbeitskopie)
@@ -165,16 +165,22 @@
pci_init(pacc); /* Initialize the PCI library */
pci_scan_bus(pacc); /* We want to get the list of devices */
- /* We look at the lbtable first to see if we need a
+#if defined(__i386__) || defined(__x86_64__)
+ /* We look at the cbtable first to see if we need a
* mainboard specific flash enable sequence.
*/
coreboot_init();
-#if defined(__i386__) || defined(__x86_64__)
dmi_init();
/* Probe for the Super I/O chip and fill global struct superio. */
probe_superio();
+#else
+ /* FIXME: Enable cbtable searching on all non-x86 platforms supported
+ * by coreboot.
+ * FIXME: Find a replacement for DMI on non-x86.
+ * FIXME: Enable SuperI/O probing once port I/O is possible.
+ */
#endif
/* Warn if a laptop is detected. */
@@ -200,6 +206,7 @@
}
}
+#if __FLASHROM_LITTLE_ENDIAN__
/* try to enable it. Failure IS an option, since not all motherboards
* really need this to be done, etc., etc.
*/
@@ -220,7 +227,25 @@
* The error code might have been a warning only.
* Besides that, we don't check the board enable return code either.
*/
+#if defined(__i386__) || defined(__x86_64__)
return 0;
+#else
+ msg_perr("Your platform is not supported yet for the internal "
+ "programmer due to missing flash_base and top/bottom "
+ "alignment information.\n"
+ "Aborting.\n");
+ return 1;
+#endif
+#else
+ /* FIXME: Remove this unconditional abort once all PCI drivers are
+ * converted to use little-endian accesses for memory BARs.
+ */
+ msg_perr("Your platform is not supported yet for the internal "
+ "programmer because it has not been converted from native "
+ "endian to little endian access yet.\n"
+ "Aborting.\n");
+ return 1;
+#endif
}
int internal_shutdown(void)
--
http://www.hailfinger.org/
Hi,
I separated the direct io access code from the flashrom changes, to make
this code easily available for the other coreboot utilities, too.
The remaining windows patch is rather small.
I'll clean up the directio code some more and make a release asap.
Best regards,
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Handle insufficient DOS timer precision by measuring a 100 ms delay
instead of a 100 us delay. This should reduce the likelihood of flashrom
timer complaints from 100% to 50%. If you want less complaints, use 1000
ms instead. This is mostly a proof of concept and I'd appreciate tests.
Once I know which #defines to look for on MinGW and Cygwin, I can modify
the #if to cover them as well.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-measure_delay_precision_dos/udelay.c
===================================================================
--- flashrom-measure_delay_precision_dos/udelay.c (Revision 1008)
+++ flashrom-measure_delay_precision_dos/udelay.c (Arbeitskopie)
@@ -93,7 +93,19 @@
* a scheduler delay or something similar.
*/
for (i = 0; i < 4; i++) {
- if (measure_delay(100) < 90) {
+#if !defined(__DJGPP__)
+ timeusec = measure_delay(100);
+#else
+ /* This zero delay workaround should be active for
+ * DOS and Windows and maybe libpayload. The criterion
+ * here is insufficient (worse than 100 us) OS timer
+ * resolution which will result in measure_delay(100)=0
+ * whereas a longer delay (100 ms) will be sufficient
+ * to get a nonzero time measurement.
+ */
+ timeusec = measure_delay(100000) / 1000;
+#endif
+ if (timeusec < 90) {
msg_pdbg("delay more than 10%% too short, "
"recalculating... ");
goto recalibrate;
--
http://www.hailfinger.org/