Using a PCI Bios Postcard here and seeing some random Bios Postcodes.
clipping from LinuxBIOSv2/documentation/POSTCODES:
0x10 Entry into protected mode
0x01 Entry into 'crt0.s' reset code jumps to here
0x11 Start copying LinuxBIOS to RAM with decompression if compressed
0x12 Copy/decompression finished jumping to RAM
0x80 Entry into LinuxBIOS in RAM
0x13 Entry into c_start
0xfe Pre call to hardwaremain()
0x39 Console is initialized
0x40 Console boot message succeeded
0x66 Devices have been enumerated
0x88 Devices have been configured
0x89 Devices have been enabled
I don't know if the above are listed in an order that states these
postcodes should be reported on the device or any order, but I do get
the following reported on my postcard in order:
0x80, 0x88, E7
0x80, 0x88, 27
0x80, 0x88, A1, AC
(Notice the 3rd and 4th post_code reported appear random.)
Back Ground Info:
I'm using the s1826 target with a 440BX board that has a Winbond
w83977tf SuperIO chip.
So I made the following changes for supporting the SuperIO W83977EF-AW
/*#define SERIAL_DEV PNP_DEV(0x2e, PC87309_SP1)*/
#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1)
(w83977tf is an earlier model of the w83977ef-aw chip but appears very
similar layout, if not, the same with minor fixes or updates.)
>From what I'm guessing, superio devices are configured by the 0x88
post_code, but enabling the devices fails???
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Wed Apr 25 19:26:00 PDT 2007
If it can't open the layout file, it just goes ahead and flashes the
Perhaps what the user (not naming names here) would prefer is for it to
print an error message and stop.
Just writing an email so I don't forget.
jerj(a)coplanar.net Email/Jabber/Google Talk/MSN
I'm currently working on a windows port of the flashrom utility. I have
been thinking about how it should be done. There are two paradigm that I'm
thinking about as of now. I need your suggestions/critics, etc. ;-). Both of
them based on the fact that this utility should be divided into user mode
code and kernel mode code.
1. The kernel mode code a.k.a kernel mode device driver is as simple as
possible and only provides "raw" functionality, i.e. capability to map the
physical address space in which the BIOS chip is mapped into the requesting
user mode code. This approach provides the user mode code similar to mmap()
function in *NIX. The pros in this approach is there won't be much changes
to the *NIX version of flashrom to adapt it to windows and it will be a
little easier to develop because no need to load/unload the driver. The cons
is if the user mode code went wrong, it can bring the whole system down.
I've been experimenting with a minor tested version for this approach
2. The kernel mode driver implements the majority of the flashrom code and
the usermode code is merely a "front-end" to the kernel mode device driver
which provides all of the chip related logic. The pros in this approach is
the code would probably much stable because the user mode code won't bring
the system down as easily as the previous approach. The cons is it will very
probably requires more work to port the *NIX version of flashrom to Windows
with this approach and more over, I haven't been able to figure out how to
do integrity-testing to the driver to ensure its stability :-(.
Anyway, I'm also thinking about a quite "universal" interface between the
user mode code and the kernel mode code. Perhaps a well defined interface
that will work both in *NIX and Windows in the future will be needed or
maybe I will try to provide an "evolution path" to such an interface. I
really need suggestion in this area.
I got an error message from linuxbios as below:
The CPU on my platform is Sempron. Why do I get “set fid failed for apicid
=00” and how to solve this issue??
On the other hand, I got error message as follow:
No memory for this cpu
I have no idea how to solve this issue. Can somebody give me a suggestion
how to find the bug out??
Thanks for your help
LinuxBIOS-1.1.8_m57sli_Fallback 一 16:26:52 CST 2007 starting...
*sysinfo range: [000cf000,000cf730)
started ap apicid: 01
begin msr fid, vid 31061212060e0202
set fid failed for apicid =00
end msr fid, vid 31061206060e0202
ht reset -
SMBus controller enabled
No memory for this cpu
I just managed to get my hands on a top hat flash.
it is an empty plcc32 socket to flip over an soldered in flash chip.
attached to the socket is a secondary flash mem and some circuitry to
handle the "chip enable" signal, i.e. pull down the primary one and
daisy chain the data/addr bus.
now I wonder, whether it is risky to use it on a non Elitegroup
mainboard and it might brick a mobo with no matching circuitry.
Ideally, I hope it works on a Gigabyte M57. should I give it a go
I bought a TC7020, Windows CE.NET based thin client terminal
for $10 about a week ago, and wanted to make it a car-puter.
The box uses NS Geode GX1 CPU, PC97317 Super I/O,
CS5530A south bridge, DP83815 NIC, and SST 29EE020 BIOS chip.
I noticed the system configuration is very similiar to eaglelion/5bcm,
and wanted to see how far it goes with unmodified configuration.
I chosed Etherboot as payload, it just booted as if the 5bcm and
TC7020 was identical box.
Thank you for the great software!
patch to fix the IDE configuration on EPIA boards. At some point this
broke and stopped FILO
from being able to boot.
The fix is a simple one line change plus a comment to
src/mainboard/via/epia/auto.c to write to the IDE
configuration register 0x42 . This has always been done here, however
at some point
something broke it.
The same register was also being set correctly in ide_init(), however
for some reason
this does not work. Possibly the register needs to be set before the IDE
peripheral is enabled
or maybe it is a timing issue.
The section of code in ide_init() (
src/southbridge/via/vt8231/vt8231_ide.c ) that does
write to register 0x42 has been commented out as it is superfluous
and I have added a comment to indicate the reason, should someone at a
future date wonder
I have also changed the default COM speed from 19200 to 115200 in
There has been mention before about the EPIA board not being able to use
115200 but I have seen
no such problems with my board.
Signed-off-by: Ben Hewson <ben(a)hewson-venieri.com>
--- src/mainboard/via/epia/auto.c (revision 2621)
+++ src/mainboard/via/epia/auto.c (working copy)
@@ -66,8 +66,16 @@
/* we do this here as in V2, we can not yet do raw operations
* to pci!
- dev += 0x100; /* ICKY */
+ /* changed this to work correctly on later revisions of LB.
+ * The original dev += 0x100; stopped working. It also appears
+ * that if this is not set here, but in ide_init() only, the IDE
+ * does not work at all. I assume it needs to be set before something else,
+ * possibly before enabling the IDE peripheral, or it is a timing issue.
+ * Ben Hewson 29 Apr 2007.
+ dev = pci_locate_device(PCI_ID(0x1106,0x0571), 0);
pci_write_config8(dev, 0x42, 0);
--- src/southbridge/via/vt8231/vt8231_ide.c (revision 2621)
+++ src/southbridge/via/vt8231/vt8231_ide.c (working copy)
@@ -15,6 +15,12 @@
// Run the IDE controller in 'compatiblity mode - i.e. don't use PCI
// interrupts. Using PCI ints confuses linux for some reason.
+ /* Setting reg 0x42 here does not work. It is set in mainboard/auto.c
+ * It probably can only be changed while the IDE is disabled
+ * or it is possibly a timing issue. Ben Hewson 29 Apr 2007.
printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__);
enables = pci_read_config8(dev, 0x42);
printk_debug("enables in reg 0x42 0x%x\n", enables);
@@ -22,6 +28,8 @@
pci_write_config8(dev, 0x42, enables);
enables = pci_read_config8(dev, 0x42);
printk_debug("enables in reg 0x42 read back as 0x%x\n", enables);
enables = pci_read_config8(dev, 0x40);
--- src/mainboard/via/epia/Options.lb (revision 2621)
+++ src/mainboard/via/epia/Options.lb (working copy)
@@ -51,7 +51,7 @@
## Select the serial console baud rate
# Select the serial console base port
The attached patch enables flashing on the Iwill DK8-HTX board.
Basically, it configures the SuperIO to set the right GPIO pins, so
write protection is disabled.
Signed-off-by: Mondrian Nuessle <nuessle(a)uni-mannheim.de>
So, this is the second try :-)
Only pci vendor id/device id is given, no subsystem id. Therefor,
flashing when booted from factory BIOS will only work, if -m
iwill:dk8_htx switch is given. I guess this could go in the wiki doc to
Mondrian Nuessle University of Mannheim
Phone: +49 621 181 2717 Computer Architecture Group
Fax: +49 621 181 2713 http://ra.ti.uni-mannheim.de