Hi,
I've finally received my replacement BIOS - the good news is that my motherboard still works (as does the replacement BIOS).
However, I seem to have some problems with LinuxBIOS (or I haven't read enough docs, yet).
Here's what I did:
1. Checkout LinuxBIOSv2 as of today 2. cd util/flashrom 3. make 4. cd ../../targets 5. ./buildtarget bitworks/ims 6. cd bitworks/ims/ims 7. make 8. Replace (while system is running) the BIOS with a Winbond W49F002U-12B chip. 9. sudo ../../../util/flashrom/flashrom -w linuxbios.rom
Calibrating delay loop... ok No LinuxBIOS table found. No EEPROM/flash device found.
I also tried with an AM29F040B-90PC, with the same result... Did I miss anything? Anyways, I'm off reading more docs.
Uwe.
- ./buildtarget bitworks/ims
- cd bitworks/ims/ims
- make
IMS uses a NSC pc87351 for the super IO.
Make sure you change the SuperIO to match your board. Or you won't get any output.
Remember that if it "works" all you are going to get is a dump of the SPD, some messages on copying and jumping to RAM and then it will crash. Everthing else is on the ToDo list. :)
- sudo ../../../util/flashrom/flashrom -w linuxbios.rom
Calibrating delay loop... ok No LinuxBIOS table found. No EEPROM/flash device found.
I also tried with an AM29F040B-90PC, with the same result... Did I miss anything? Anyways, I'm off reading more docs.
I'm spoiled. We have EEPROM/flash programmers. So I've actually never used flashrom. But 29f04b have been suported for a while.
Try it with the -v option so we can see what the return values are from the device check.
- ./buildtarget bitworks/ims
- cd bitworks/ims/ims
- make
IMS uses a NSC pc87351 for the super IO.
Make sure you change the SuperIO to match your board. Or you won't get any output.
Remember that if it "works" all you are going to get is a dump of the SPD, some messages on copying and jumping to RAM and then it will crash. Everthing else is on the ToDo list. :)
- sudo ../../../util/flashrom/flashrom -w linuxbios.rom
Calibrating delay loop... ok No LinuxBIOS table found. No EEPROM/flash device found.
I'm guessing the write enable did not happen.
you can'd ID flash without write cycles working.
ron
* Richard Smith smithbone@gmail.com [060731 20:46]:
I'm spoiled. We have EEPROM/flash programmers. So I've actually never used flashrom. But 29f04b have been suported for a while.
Try it with the -v option so we can see what the return values are from the device check.
It's -V ... -v is verify.
Hi,
On Mon, Jul 31, 2006 at 04:39:46PM -0600, Ronald G. Minnich wrote:
I'm guessing the write enable did not happen.
you can'd ID flash without write cycles working.
How do I find out whether it happened and how can I fix it if it didn't?
Attached is the output of ./flashrom -V. It's the same for both the AM2* and W49* chips. I had no luck with flash_rom from V1, either. The output of that is attached, too.
Cheers, Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060801 01:36]:
you can'd ID flash without write cycles working.
How do I find out whether it happened and how can I fix it if it didn't?
They don't work. You read back ff all the time.
Attached is the output of ./flashrom -V. It's the same for both the AM2* and W49* chips. I had no luck with flash_rom from V1, either. The output of that is attached, too.
I assume it doesnt even try to enable write cycles. This should be warned in flashrom with an appropriate message to fix it.
ie on Epia it would say: Enabling flash write on VT8235...OK
Can you send around an lspci -n ?
Hi,
On Tue, Aug 01, 2006 at 01:41:51AM +0200, Stefan Reinauer wrote:
They don't work. You read back ff all the time.
Yes, that's what I was guessing. It should return the vendor and device ID (0xDA, 0x0B), correct?
Do the access times matter here? I have a W49F002U-12B, i.e. 120ns, according to the datasheet.
Attached is the output of ./flashrom -V. It's the same for both the AM2* and W49* chips. I had no luck with flash_rom from V1, either. The output of that is attached, too.
I assume it doesnt even try to enable write cycles. This should be warned in flashrom with an appropriate message to fix it.
ie on Epia it would say: Enabling flash write on VT8235...OK
I haven't seen such a message here.
Can you send around an lspci -n ?
Sure.
00:00.0 0600: 8086:7190 (rev 03) 00:01.0 0604: 8086:7191 (rev 03) 00:07.0 0601: 8086:7110 (rev 02) 00:07.1 0101: 8086:7111 (rev 01) 00:07.2 0c03: 8086:7112 (rev 01) 00:07.3 0680: 8086:7113 (rev 02) 01:00.0 0300: 1039:6326 (rev 0b)
Uwe.
Uwe Hermann wrote:
How do I find out whether it happened and how can I fix it if it didn't?
you know it did not, but the fact that every single id1 and id2 is 0xff is a sign that something is really wrong.
You're going to have to do some more digging :-(
ron
* Uwe Hermann uwe@hermann-uwe.de [060801 01:57]:
Yes, that's what I was guessing. It should return the vendor and device ID (0xDA, 0x0B), correct?
Yes, exactly.
Do the access times matter here? I have a W49F002U-12B, i.e. 120ns, according to the datasheet.
If you replace a part, it should not be slower than the original one, but I never saw problems due to access times, realy.
ie on Epia it would say: Enabling flash write on VT8235...OK
I haven't seen such a message here.
Can you send around an lspci -n ?
Sure.
00:00.0 0600: 8086:7190 (rev 03) 00:01.0 0604: 8086:7191 (rev 03) 00:07.0 0601: 8086:7110 (rev 02) 00:07.1 0101: 8086:7111 (rev 01) 00:07.2 0c03: 8086:7112 (rev 01) 00:07.3 0680: 8086:7113 (rev 02) 01:00.0 0300: 1039:6326 (rev 0b)
Hi,
On Tue, Aug 01, 2006 at 02:02:21PM +0200, Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [060801 01:57]:
Yes, that's what I was guessing. It should return the vendor and device ID (0xDA, 0x0B), correct?
Yes, exactly.
I still had no luck with flashrom. I tried both chips on another computer now, same results. I also tried a PLCC chip (AM29F040B-120JC) on a third computer, same result too (0xFF for all queries).
This seems really strange - could it be that the chips are not only "empty" but also do not have an ID hardcoded in them? I.e. is it possible that the 0xFF is actually correct? If so, I could skip the vendor ID check and just try/force writing, maybe...
Cheers, Uwe.
Uwe Hermann wrote:
This seems really strange - could it be that the chips are not only "empty" but also do not have an ID hardcoded in them?
no, that is definitely not in the cards.
There is something really bad going on .
ron
* Uwe Hermann uwe@hermann-uwe.de [060804 00:05]:
This seems really strange - could it be that the chips are not only "empty" but also do not have an ID hardcoded in them? I.e. is it possible that the 0xFF is actually correct? If so, I could skip the vendor ID check and just try/force writing, maybe...
I don't believe so. ("But I would not bet my leg for it either")
Basically if you can't ID a chip, you can't write to it either.
Some board vendors, Asus is known to be one of them, secure their boards from "flash viruses" (did they mean linuxbios?) with additional GPIO linux This kind of stuff requires reverse engineering (which was legal in Germany last time I had to do this) or a loooot of patience talking to sales reps.
Stefan
On 8/3/06, Stefan Reinauer stepan@coresystems.de wrote:
- Uwe Hermann uwe@hermann-uwe.de [060804 00:05]:
This seems really strange - could it be that the chips are not only
Uwe. What kind of hardware tools to you have available? Do you have access to an Oscope?
Hi,
On Fri, Aug 04, 2006 at 12:43:45AM +0200, Stefan Reinauer wrote:
Basically if you can't ID a chip, you can't write to it either.
I'll try some more computers I have access to. If I find one which _does_ get the ID correctly I know it's a problem with the board and not with the chips themselves.
Some board vendors, Asus is known to be one of them, secure their boards from "flash viruses" (did they mean linuxbios?) with additional GPIO linux This kind of stuff requires reverse engineering (which was legal in Germany last time I had to do this) or a loooot of patience talking to sales reps.
Can some of the programs in util/ be used to find out whether or not such GPIOs could be in place?
Cheers, Uwe.
Hi,
On Thu, Aug 03, 2006 at 06:11:47PM -0500, Richard Smith wrote:
Uwe. What kind of hardware tools to you have available? Do you have access to an Oscope?
Not usually, but I might be able to get access to one from time to time. What can I do/check if I have one?
I do not currently have a POST card, but intend to get one. I should be able to setup a serial connection.
Say I manage to flash targets/bitworks/ims/ims/fallback/linuxbios.rom (that's the only ims image <= 256K, so I'll have to use it as my chips are 256K, is that correct?), connect a serial cable on ttyS0 (ttyS1?), 115200 Baud, 8N1. Should I be able to get some debug output with the current code in svn?
P.S. no need to CC me, I'm subscribed.
Cheers, Uwe.
Uwe. What kind of hardware tools to you have available? Do you have access to an Oscope?
Not usually, but I might be able to get access to one from time to time. What can I do/check if I have one?
You can watch the write line on the chip and see if its getting asserted. Then you know for sure if its flash chip or chipset.
Say I manage to flash targets/bitworks/ims/ims/fallback/linuxbios.rom (that's the only ims image <= 256K, so I'll have to use it as my chips are 256K, is that correct?), connect a serial cable on ttyS0 (ttyS1?),
The IMS config is setup for a 29f040b which is a 512k part. Did you change the rom size in the config file? But yes your rom size needs to match your chips.
115200 Baud, 8N1. Should I be able to get some debug output with the current code in svn?
Yes you will get some boot messages and it will try to dump the spd contents.
Hi,
more tests, still no luck. I had access to a hardware flash/EEPROM programmer today and flashed bitworks/ims/linuxbios.rom (256K this time, last time it was 512K which obviously cannot work). The Windows-Software for the programmer supported the chip (W49F002U) and reported that flashing worked fine (verify succeeded, too).
Now, I tried to boot from that chip but cannot get serial output, it seems (115200 Baud, 8N1, ttyS0).
I also tried to set the "reset BIOS" jumper on the board before running "./flashrom -V", but it seems that doesn't help either. I'm slowly running out of ideas.
Hm, say I accidentally killed the chips (ESD) somehow - would the result be 0xFF's returned as vendor/device ID?
Uwe.
today and flashed bitworks/ims/linuxbios.rom (256K this time, last time it was 512K which obviously cannot work). The Windows-Software for the programmer supported the chip (W49F002U) and reported that flashing worked fine (verify succeeded, too).
Your problem I think is the superIO. The GA-6BXC uses an ITE it8671f as the SuperIO and its not supported in V2. IMS uses a nsc pc87351.
You have to fix up the superIO first or you won't ever get any output.
Did you port the superIO?
Hi,
On Fri, Aug 04, 2006 at 04:43:00PM -0500, Richard Smith wrote:
Your problem I think is the superIO. The GA-6BXC uses an ITE it8671f as the SuperIO and its not supported in V2. IMS uses a nsc pc87351.
Indeed, that was the only remaining problem. I created a patch to add support for the ITE it8671f in LinuxBIOSv2.
The setup_serial.inc is copied from v1, for the rest of the stuff I tried to guess what's needed from other superios in v2. I haven't grasped LinuxBIOS well enough to _really_ know what I'm doing ;)
Anyways, I managed to build an image (based on bitworks/ims) which outputs something on the serial line:
LinuxBIOS-1.1.0-* starting... BIST failed: 00000002
Please look over the preliminary patch (attached) and tell me about obvious stupid errors I made.
Btw, is the following snippet needed in chip.h?
#ifndef SIO_COM1 #define SIO_COM1_BASE 0x3F8 #endif #ifndef SIO_COM2 #define SIO_COM2_BASE 0x2F8 #endif
It's in many chip.h files in src/superio, but an 'rgrep SIO_COM *' shows that it's only defined in these chip.h files but never used. Is this some remainder from v1?
Also, who was the original author of the other files from which I cut'n'pasted (superio.c, chip.h, it8671f_early_serial.c, ...)? He/she needs to be added to the copyright header of the files.
My next steps are to prepare a patch for the motherboard, and to find out if I can add support for more hardware devices (other than serial port)...
Cheers, Uwe.
Uwe Hermann wrote:
Hi,
more tests, still no luck. I had access to a hardware flash/EEPROM programmer today and flashed bitworks/ims/linuxbios.rom (256K this time, last time it was 512K which obviously cannot work). The Windows-Software for the programmer supported the chip (W49F002U) and reported that flashing worked fine (verify succeeded, too).
Now, I tried to boot from that chip but cannot get serial output, it seems (115200 Baud, 8N1, ttyS0).
I also tried to set the "reset BIOS" jumper on the board before running "./flashrom -V", but it seems that doesn't help either. I'm slowly running out of ideas.
Hm, say I accidentally killed the chips (ESD) somehow - would the result be 0xFF's returned as vendor/device ID?
yes but I don't think that is it. There's something "special" on this board.
ron
stefan, what do you think? committable?
Uwe, nice job.
ron
On 8/6/06, Uwe Hermann uwe@hermann-uwe.de wrote:
The setup_serial.inc is copied from v1, for the rest of the stuff I tried to guess what's needed from other superios in v2. I haven't grasped LinuxBIOS well enough to _really_ know what I'm doing ;)
setup_serial.inc is a holdover from V1 and not used in V2. Just say not to assembly.
Are you #includeing this in your auto.c? If so then remove it an only use the .c stuff to init the device.
Anyways, I managed to build an image (based on bitworks/ims) which outputs something on the serial line:
LinuxBIOS-1.1.0-* starting...
1.1.0? What rev are you working with?
Hmmm... Perhpas we need to add some .svn build info in here.
Please look over the preliminary patch (attached) and tell me about obvious stupid errors I made.
I've only had time to briefly look at it. I'll study it more later.
Hi,
On Mon, Aug 07, 2006 at 08:36:50AM -0600, Ronald G Minnich wrote:
yes but I don't think that is it. There's something "special" on this board.
Yes, definately. I don't yet know _what_ it is, but I managed to use Uniflash (see my other post) to flash a chip on that board, so it's a software issue which can be fixed.
Cheers, Uwe.
Hi,
On Mon, Aug 07, 2006 at 10:09:10AM -0500, Richard Smith wrote:
Are you #includeing this in your auto.c? If so then remove it an only use the .c stuff to init the device.
Yes, I included it from auto.c. I'll try if the init works without the asm stuff, but I fear it won't. Where should a C replacement of that code be added? Should it be made part of it8671f_enable_serial()?
Anyways, I managed to build an image (based on bitworks/ims) which outputs something on the serial line:
LinuxBIOS-1.1.0-* starting...
1.1.0? What rev are you working with?
Latest svn, v2. There was more info in that line (I replaced it with "*"), but I was too lazy to type all of it.
Cheers, Uwe.
* Ronald G Minnich rminnich@lanl.gov [060807 16:38]:
stefan, what do you think? committable?
i checked it in.
- dropped the assembler part - renamed the directory from "foo" to "ite" ;-)
no mainboard in the tree uses it though.. Anything to check in here?
updates and patches against 2365 or later please.
Stefan
* Uwe Hermann uwe@hermann-uwe.de [060807 17:26]:
Hi,
On Mon, Aug 07, 2006 at 10:09:10AM -0500, Richard Smith wrote:
Are you #includeing this in your auto.c? If so then remove it an only use the .c stuff to init the device.
Yes, I included it from auto.c. I'll try if the init works without the asm stuff, but I fear it won't. Where should a C replacement of that code be added? Should it be made part of it8671f_enable_serial()?
That's what src/superio/ite/it8671f/it8671f_early_serial.c is good for. It should be included in your auto.c file and it8671f_enable_serial() from there should be called.
Stefan
* Uwe Hermann uwe@hermann-uwe.de [060807 17:20]:
Hi,
On Mon, Aug 07, 2006 at 08:36:50AM -0600, Ronald G Minnich wrote:
yes but I don't think that is it. There's something "special" on this board.
Yes, definately. I don't yet know _what_ it is, but I managed to use Uniflash (see my other post) to flash a chip on that board, so it's a software issue which can be fixed.
You might want to have a look at the patch described here:
http://www.mail-archive.com/linuxbios%40linuxbios.org/msg00372.html
Stefan
Hi,
On Mon, Aug 07, 2006 at 07:35:34PM +0200, Stefan Reinauer wrote:
That's what src/superio/ite/it8671f/it8671f_early_serial.c is good for. It should be included in your auto.c file and it8671f_enable_serial() from there should be called.
Done, patch attached.
I wasn't able to find a datasheet for the it8671f on the net, so I used the one from the it8673f, which seems to be reasonably similar. The patch works for me (I tested serial port 1), but may need some more polishing and support for floppy and parallel port...
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060810 02:43]:
Hi,
On Mon, Aug 07, 2006 at 07:35:34PM +0200, Stefan Reinauer wrote:
That's what src/superio/ite/it8671f/it8671f_early_serial.c is good for. It should be included in your auto.c file and it8671f_enable_serial() from there should be called.
Done, patch attached.
Thank you!
Patch committed.
Hi,
On Thu, Aug 10, 2006 at 11:38:47AM +0200, Stefan Reinauer wrote:
Patch committed.
Thanks! For consistency reasons, shouldn't the ite/ directory be named ITE/? Either that, or NSC/ should be called nsc/?
Also, what about the variable names? Should they be called *_ITE_* or *_ite_*?
Uwe.
Hi,
On Sun, Aug 06, 2006 at 09:52:15PM +0200, Uwe Hermann wrote:
Btw, is the following snippet needed in chip.h?
#ifndef SIO_COM1 #define SIO_COM1_BASE 0x3F8 #endif #ifndef SIO_COM2 #define SIO_COM2_BASE 0x2F8 #endif
Responding to myself, here's a bold patch to remove all of them. I don't see them used anywhere, but I might be wrong.
Uwe.
did you test your patch with abuild?
ron
Hi,
On Fri, Aug 11, 2006 at 11:37:42AM -0600, Ronald G Minnich wrote:
did you test your patch with abuild?
Yes, it works (mostly). And it really should, grep reports that the defines are only #defined, but never used.
I get a few
Processing mainboard/embeddedplanet/ep405pc (ppc: skipped, we're i386)
and similar lines, but that's normal, I guess.
Also, artecgroup/dbe61 fails (see below), but that's always the case, judging from the recent svn commit messages ("Compilation of artecgroup:dbe61 is still broken.").
----------------- Processing mainboard/artecgroup/dbe61 (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED after 0s! Log excerpt: macro MSR_CPU already defined
make[1]: *** [auto.inc] Error 1 make[1]: Leaving directory `/home/uh1763/data/code/linuxbios/linuxbios-0.0+svn20060724/util/abuild/linuxbios-builds/artecgroup_dbe61/normal' make: *** [normal/linuxbios.rom] Error 1 ----------------- Processing mainboard/tyan/s2885 (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED after 0s! Log excerpt: make: *** No targets specified and no makefile found. Stop. -----------------
The second (tyan/s2885) I'm not sure about. Manually building it does not work, but only because of payload path issues:
make[1]: *** No rule to make target `../../../../payloads/tg3--filo_hda2_vga.zelf', needed by `payload'. Stop.
Other than that it works fine.
I had to 'ln -s /usr/bin/iasl /usr/sbin/iasl', as that's in /usr/bin on Debian. Maybe there should be a small wrapper script which checks where iasl resides and then calls it?
Uwe.
-
Richard Smith -
Ronald G Minnich -
Ronald G. Minnich
-
Stefan Reinauer -
Uwe Hermann