Hello, I am having issues with flashrom. It can read the bios ok and even verify it but when I try to write it I get this:
[root@localhost util]# flashrom -w test Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
After this I tried the -E option (worked good) to erase it and than tried again with no luck, same message, any ideas??
Thanks - Joe
Quoting joe@smittys.pointclark.net:
Hello, I am having issues with flashrom. It can read the bios ok and even verify it but when I try to write it I get this:
[root@localhost util]# flashrom -w test Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
After this I tried the -E option (worked good) to erase it and than tried again with no luck, same message, any ideas??
Has anyone ever seen this error before??? ERASE FAILED @0, val 92!
Thanks - Joe
* joe@smittys.pointclark.net joe@smittys.pointclark.net [080219 17:29]:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
After this I tried the -E option (worked good) to erase it and than tried again with no luck, same message, any ideas??
Has anyone ever seen this error before??? ERASE FAILED @0, val 92!
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
Stefan
Quoting Stefan Reinauer stepan@coresystems.de:
- joe@smittys.pointclark.net joe@smittys.pointclark.net [080219 17:29]:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
After this I tried the -E option (worked good) to erase it and than tried again with no luck, same message, any ideas??
Has anyone ever seen this error before??? ERASE FAILED @0, val 92!
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
Stefan
Ahhhh, all the more reason for the "intel-debugtools" :-)
Thanks - Joe
SO, this might be a good chance for a tutorial on how to figure out what's up. We should start with the GPIO dump and work from there.
Do you have a gpio dump yet?
ron
Quoting ron minnich rminnich@gmail.com:
SO, this might be a good chance for a tutorial on how to figure out what's up. We should start with the GPIO dump and work from there.
Do you have a gpio dump yet?
ron
Not yet, I am at work. I will work on it tonight when I get home.
Thanks - Joe
Quoting Stefan Reinauer stepan@coresystems.de:
- joe@smittys.pointclark.net joe@smittys.pointclark.net [080219 17:29]:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
After this I tried the -E option (worked good) to erase it and than tried again with no luck, same message, any ideas??
Has anyone ever seen this error before??? ERASE FAILED @0, val 92!
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
Stefan
Do you remember what you did to fix this on the ICH4-M?
Thanks - Joe
* joe@smittys.pointclark.net joe@smittys.pointclark.net [080229 18:36]:
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
Do you remember what you did to fix this on the ICH4-M?
The issue remained unfixed, I used a Galep5 to burn the flash chips.
Stefan
On 29.02.2008 20:07, Stefan Reinauer wrote:
- joe@smittys.pointclark.net joe@smittys.pointclark.net [080229 18:36]:
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
Do you remember what you did to fix this on the ICH4-M?
The issue remained unfixed, I used a Galep5 to burn the flash chips.
In theory, this should be debuggable with DOS ports of the ICH GPIO dumper and superiotool.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080229 20:13]:
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
Do you remember what you did to fix this on the ICH4-M?
The issue remained unfixed, I used a Galep5 to burn the flash chips.
In theory, this should be debuggable with DOS ports of the ICH GPIO dumper and superiotool.
SMM based bios lock down? How so? It does not seem to be a GPIO issue in case.
On 29.02.2008 20:21, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080229 20:13]:
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
"Might be SMM...", so this is not certain.
Do you remember what you did to fix this on the ICH4-M?
The issue remained unfixed, I used a Galep5 to burn the flash chips.
In theory, this should be debuggable with DOS ports of the ICH GPIO dumper and superiotool.
SMM based bios lock down? How so? It does not seem to be a GPIO issue in case.
If the lockdown is indeed SMM based, we can find out with superiotool and the GPIO dumper (they will show no changes in GPIO configuration). Then again, if you can ID the chip, it means you can write to it and the only thing missing is setting the TBL# and WP# pins of the flash chip high. Both pins are probably connected to some GPIOs, so unless SMM protects access to the GPIO settings, flashing should be possible. If the problem appears under coreboot as well, we can rule out SMM protection, but not SMM flash enabling.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 29.02.2008 20:21, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080229 20:13]:
Yes, it means the actual flash write mechanism is protected, though the ID command gets through. I had the same thing on another ICH4M board. Might be SMM protection, some GPIO or some other mapping/locking mechanism.
"Might be SMM...", so this is not certain.
Do you remember what you did to fix this on the ICH4-M?
The issue remained unfixed, I used a Galep5 to burn the flash chips.
In theory, this should be debuggable with DOS ports of the ICH GPIO dumper and superiotool.
SMM based bios lock down? How so? It does not seem to be a GPIO issue in case.
If the lockdown is indeed SMM based, we can find out with superiotool and the GPIO dumper (they will show no changes in GPIO configuration). Then again, if you can ID the chip, it means you can write to it and the only thing missing is setting the TBL# and WP# pins of the flash chip high. Both pins are probably connected to some GPIOs, so unless SMM protects access to the GPIO settings, flashing should be possible. If the problem appears under coreboot as well, we can rule out SMM protection, but not SMM flash enabling.
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
Little confused about SMM? In the nothbridge datasheet it talks about SMM (System Management Space), I do not have any of these registers set, just defaults. In the southbridge datasheet it talks about SMM (special mask mode), I do not have any of these registers set eithor, just defaults. Are these related, or two different things? Do I need to set these registers up?
Thanks - Joe
On 01.03.2008 14:04, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 29.02.2008 20:21, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [080229
20:13]:
> Yes, it means the actual flash write mechanism is protected, > though the > ID command gets through. I had the same thing on another ICH4M > board. > Might be SMM protection, some GPIO or some other mapping/locking > mechanism.
"Might be SMM...", so this is not certain.
Do you remember what you did to fix this on the ICH4-M?
The issue remained unfixed, I used a Galep5 to burn the flash chips.
In theory, this should be debuggable with DOS ports of the ICH GPIO dumper and superiotool.
SMM based bios lock down? How so? It does not seem to be a GPIO issue in case.
If the lockdown is indeed SMM based, we can find out with superiotool and the GPIO dumper (they will show no changes in GPIO configuration). Then again, if you can ID the chip, it means you can write to it and the only thing missing is setting the TBL# and WP# pins of the flash chip high. Both pins are probably connected to some GPIOs, so unless SMM protects access to the GPIO settings, flashing should be possible. If the problem appears under coreboot as well, we can rule out SMM protection, but not SMM flash enabling.
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
I was relying on the new extended superiotool dumping functionality. That doesn't exist yet for your superio, so I should have written "...can find out with superiotool (once that has GPIO dumping support for your superio) and...". Thanks for correcting me.
Little confused about SMM? In the nothbridge datasheet it talks about SMM (System Management Space), I do not have any of these registers set, just defaults.
I only know SMM as "System Management Mode" and I hope very much we do not have to mess with SMM code arbitrating access to any superio/chipset GPIOs.
In the southbridge datasheet it talks about SMM (special mask mode), I do not have any of these registers set eithor, just defaults. Are these related, or two different things? Do I need to set these registers up?
I had no idea about this meaning of SMM, so I can't answer here.
Regards, Carl-Daniel
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
I was relying on the new extended superiotool dumping functionality. That doesn't exist yet for your superio, so I should have written "...can find out with superiotool (once that has GPIO dumping support for your superio) and...". Thanks for correcting me.
I am working on this right now.....
Thanks - Joe
Quoting joe@smittys.pointclark.net:
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
I was relying on the new extended superiotool dumping functionality. That doesn't exist yet for your superio, so I should have written "...can find out with superiotool (once that has GPIO dumping support for your superio) and...". Thanks for correcting me.
I am working on this right now.....
hmm, I think I did everthing right but my dumps are coming back with all zero's, not the default values. Would someone mind taking a look to see what I am doing wrong in the attached smsc.c
I need to fix the format, but here is the output:
[root@localhost superiotool]# superiotool -de superiotool r3121 Found SMSC LPC47M15x/192/997 (id=0x60, rev=0x01) at 0x2e Register dump: idx 03 07 20 21 22 23 24 26 27 28 2a 2b 2c 2d 2e 2f val 00 0a 60 01 10 00 44 2e 00 00 00 00 00 00 00 00 def RR 00 60 NA 00 00 44 MM MM RR NA NA NA NA NA NA LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 00 03 f0 06 02 0e 00 ff 00 00 def 00 03 f0 06 02 0e 00 ff 00 00 LDN 0x03 (Parallel port) idx 30 60 61 70 74 f0 f1 val 00 03 78 07 04 3c 00 def 00 00 00 00 04 3c 00 LDN 0x04 (COM1) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 00 00 00 00 00 LDN 0x05 (COM2 / IR) idx 30 60 61 70 f0 f1 f2 val 00 00 00 00 00 02 03 def NA 00 00 00 00 02 03 LDN 0x07 (Keyboard) idx 30 70 72 f0 val 01 01 0c 00 def 00 00 00 00 LDN 0x09 (Game port) idx 30 60 61 val 00 00 00 def 00 00 00 LDN 0x0a (Power Management Events (PME)) idx 30 60 61 f0 val 01 0a 00 00 def 00 00 00 NA LDN 0x0b (MPU-401) idx 30 60 61 70 val 00 03 30 05 def 00 03 30 05 PME I/O Base Address (0x0a00) Register dump: idx 00 02 04 05 06 07 08 0a 0b 0c 0d 0e 10 11 12 13 14 16 17 18 19 1a 1c 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2f val 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 def 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 03 NA NA NA 00 01 01 01 01 01 01 01 01 01 01 01 01 Register dump: idx 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 4b 4c 4d 4e 4f 50 56 57 58 59 5a 5b 5c 5d 5e 5f val 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 def 01 01 01 01 01 01 01 05 04 01 01 01 01 01 01 01 01 01 00 01 01 01 01 01 01 00 00 00 00 00 00 00 00 50 00 00 00 00 00 00 00
Thanks - Joe
Quoting joe@smittys.pointclark.net:
Quoting joe@smittys.pointclark.net:
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
I was relying on the new extended superiotool dumping functionality. That doesn't exist yet for your superio, so I should have written "...can find out with superiotool (once that has GPIO dumping support for your superio) and...". Thanks for correcting me.
Well, I wasn't able to get a dump of the "Runtime Registers" with superiotool working, but I was able to get a dump of it with the old dd method, there are alot of differences........maybe one of these GPIO settings is causing my flashrom issue??? It is hard to say without schmatics, but I could always try one register at a time until it works???
Thanks - Joe
rm4100 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00 02 00 14 0f ce 00 00 00 00 00 00 00 00 00 03 02 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 01 01 01 01 05 05 00 00 00 04 01 01 01 01 86 01 05 05 05 04 05 04 05 04 01 01 00 00 00 04 d0 00 07 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
coreboot 00 00 00 00 d8 00 14 0f 67 00 00 00 00 00 00 00 02 00 14 0f c6 00 00 00 00 00 00 00 00 00 03 02 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 02 01 01 01 01 01 00 00 05 04 01 01 01 01 01 01 01 01 01 00 01 01 01 01 01 01 00 00 00 04 d0 04 23 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
On 04.03.2008 14:36, joe@smittys.pointclark.net wrote:
Quoting joe@smittys.pointclark.net:
Quoting joe@smittys.pointclark.net:
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
I was relying on the new extended superiotool dumping functionality. That doesn't exist yet for your superio, so I should have written "...can find out with superiotool (once that has GPIO dumping support for your superio) and...". Thanks for correcting me.
Well, I wasn't able to get a dump of the "Runtime Registers" with superiotool working, but I was able to get a dump of it with the old dd method,
dd method? Can you please tell me the exact command for that? I think the extra register dumping for ITE is totally incompatible with the one for SMSC which would explain your problems.
there are alot of differences........maybe one of these GPIO settings is causing my flashrom issue??? It is hard to say without schmatics, but I could always try one register at a time until it works???
Yes. Or set all of them to the factory BIOS values at once and try again. Sometimes dependencies between various registers make it dangerous to change only a part of the values.
Thanks - Joe
rm4100 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00 02 00 14 0f ce 00 00 00 00 00 00 00 00 00 03 02 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 01 01 01 01 05 05 00 00 00 04 01 01 01 01 86 01 05 05 05 04 05 04 05 04 01 01 00 00 00 04 d0 00 07 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
coreboot 00 00 00 00 d8 00 14 0f 67 00 00 00 00 00 00 00 02 00 14 0f c6 00 00 00 00 00 00 00 00 00 03 02 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 02 01 01 01 01 01 00 00 05 04 01 01 01 01 01 01 01 01 01 00 01 01 01 01 01 01 00 00 00 04 d0 04 23 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
Nice output.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 04.03.2008 14:36, joe@smittys.pointclark.net wrote:
Quoting joe@smittys.pointclark.net:
Quoting joe@smittys.pointclark.net:
To check this with superiotool I have to be able to dump the "Runtime Registers", this is where the GPIO's are (See the SMSC lpc47m192 datasheet for more info). Currently superiotool does not dump these registers so modifications will be required.
I was relying on the new extended superiotool dumping functionality. That doesn't exist yet for your superio, so I should have written "...can find out with superiotool (once that has GPIO dumping support for your superio) and...". Thanks for correcting me.
Well, I wasn't able to get a dump of the "Runtime Registers" with superiotool working, but I was able to get a dump of it with the old dd method,
dd method? Can you please tell me the exact command for that? I think the extra register dumping for ITE is totally incompatible with the one for SMSC which would explain your problems.
rm4100 [root@localhost proc]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | xxd 256+0 records in 256+0 records out 256 bytes (256 B) copied, 0.00171602 s, 149 kB/s 0000000: 0000 0000 dc00 140f e700 0000 0000 0000 ................ 0000010: 0200 140f ce00 0000 0000 0000 0000 0302 ................ 0000020: 8100 0001 0101 0101 0101 0101 0101 0001 ................ 0000030: 0101 0105 0500 0000 0401 0101 0186 0105 ................ 0000040: 0505 0405 0405 0401 0100 0000 04d0 0007 ................ 0000050: 0000 0000 0000 0000 50ff ff00 0000 0000 ........P....... 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
coreboot [root@localhost ~]# dd if=/dev/port bs=1 skip=$[0x0a00] count=128 | xxd 256+0 records in 256+0 records out 256 bytes (256 B) copied, 0.00217287 s, 118 kB/s 0000000: 0000 0000 d800 140f 6700 0000 0000 0000 ........g....... 0000010: 0200 140f c600 0000 0000 0000 0000 0302 ................ 0000020: 8100 0001 0101 0101 0101 0101 0101 0002 ................ 0000030: 0101 0101 0100 0005 0401 0101 0101 0101 ................ 0000040: 0101 0001 0101 0101 0100 0000 04d0 0423 ...............# 0000050: 0000 0000 0000 0000 50ff ff00 0000 0000 ........P....... 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
there are alot of differences........maybe one of these GPIO settings is causing my flashrom issue??? It is hard to say without schmatics, but I could always try one register at a time until it works???
Yes. Or set all of them to the factory BIOS values at once and try again. Sometimes dependencies between various registers make it dangerous to change only a part of the values.
Which is a little weird, because in coreboot all the values aren't at their defaults, maybe hardwired?
rm4100 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00 02 00 14 0f ce 00 00 00 00 00 00 00 00 00 03 02 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 01 01 01 01 05 05 00 00 00 04 01 01 01 01 86 01 05 05 05 04 05 04 05 04 01 01 00 00 00 04 d0 00 07 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
coreboot 00 00 00 00 d8 00 14 0f 67 00 00 00 00 00 00 00 02 00 14 0f c6 00 00 00 00 00 00 00 00 00 03 02 81 00 00 01 01 01 01 01 01 01 01 01 01 01 00 02 01 01 01 01 01 00 00 05 04 01 01 01 01 01 01 01 01 01 00 01 01 01 01 01 01 00 00 00 04 d0 04 23 00 00 00 00 00 00 00 00 50 ff ff 00 00 00 00 00
Nice output.
The output is not that nice I had to doctor it up a little bit.
Thanks - Joe
On Tue, Mar 4, 2008 at 1:00 PM, joe@smittys.pointclark.net wrote:
rm4100 [root@localhost proc]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | xxd 256+0 records in 256+0 records out 256 bytes (256 B) copied, 0.00171602 s, 149 kB/s 0000000: 0000 0000 dc00 140f e700 0000 0000 0000 ................
<SNIP>
rm4100 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00
<SNIP>
The output is not that nice I had to doctor it up a little bit.
I use hexdump instead, no doctoring required:
[xxx@xxx xxx]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | hexdump -C 00000000 00 00 00 00 18 00 00 c0 00 00 00 00 00 00 00 00 |................| 00000010 02 00 80 80 00 00 00 80 00 00 20 00 00 00 02 00 |.......... .....| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 04 00 01 00 00 06 00 00 84 84 84 84 84 01 00 |................| 00000040 01 84 05 05 05 04 05 04 05 04 00 91 40 01 28 57 |............@.(W| 00000050 47 60 00 00 00 00 00 9f 5c 6c 00 06 00 00 a4 00 |G`......\l......| 00000060 01 00 61 01 60 00 00 00 60 7f 04 00 00 00 00 00 |..a.`...`.......| 00000070 0e 01 00 04 00 01 18 00 00 00 00 00 20 52 6c 6b |............ Rlk| 00000080
You can get quite fancy with hexdump's '-e' option, displaying in dwords, tab formatting, etc. The '-C' option gets the output formatted easily.
Quoting Tom Sylla tsylla@gmail.com:
On Tue, Mar 4, 2008 at 1:00 PM, joe@smittys.pointclark.net wrote:
rm4100 [root@localhost proc]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | xxd 256+0 records in 256+0 records out 256 bytes (256 B) copied, 0.00171602 s, 149 kB/s 0000000: 0000 0000 dc00 140f e700 0000 0000 0000 ................
<SNIP> > >> rm4100 > >> 00 00 00 00 dc 00 14 0f e7 00 00 00 00 00 00 00 <SNIP> > The output is not that nice I had to doctor it up a little bit.
I use hexdump instead, no doctoring required:
[xxx@xxx xxx]# dd if=/dev/port bs=1 skip=$[0x0800] count=128 | hexdump -C 00000000 00 00 00 00 18 00 00 c0 00 00 00 00 00 00 00 00 |................| 00000010 02 00 80 80 00 00 00 80 00 00 20 00 00 00 02 00 |.......... .....| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 04 00 01 00 00 06 00 00 84 84 84 84 84 01 00 |................| 00000040 01 84 05 05 05 04 05 04 05 04 00 91 40 01 28 57 |............@.(W| 00000050 47 60 00 00 00 00 00 9f 5c 6c 00 06 00 00 a4 00 |G`......\l......| 00000060 01 00 61 01 60 00 00 00 60 7f 04 00 00 00 00 00 |..a.`...`.......| 00000070 0e 01 00 04 00 01 18 00 00 00 00 00 20 52 6c 6b |............ Rlk| 00000080
You can get quite fancy with hexdump's '-e' option, displaying in dwords, tab formatting, etc. The '-C' option gets the output formatted easily.
Cool, thanks for the tip Tom:-)
Thanks - Joe
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) { printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; } }
It seems to work fine now. Is this a bug for Intel ICH series???
Thanks - Joe
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) { printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; } }
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
thanks
ron
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) { printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; } }
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
Thanks - Joe
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) { printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; } }
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) { printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; } }
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is part of the write_jedec function. I can do everything else except write (-w) to the flash chip. I get a:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
If I remove the above function from write_jedec flashrom writes to the chip just fine.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??
Thanks - Joe
On 09.03.2008 20:20, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) {
It reads from the flash and compares the result to 0xff. No write to flash happens.
printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; }}
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is part of the write_jedec function. I can do everything else except write (-w) to the flash chip. I get a:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
If I remove the above function from write_jedec flashrom writes to the chip just fine.
It seems erase_chip_jedec() leaves the chip in a bad state. And according to the chip documentation, the value you read means "program/erase finished, programming failed some time since last reset/status register clearing, failed attempt to write to a protected block some time since last reset/status register clearing". However, both spec and real life are unclear whether my interpretation is correct.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??
Indeed. Have you tried to erase only, then read back the result immediately? That would be very interesting. If the readback is all 0xff, try commenting out erase_chip_jedec(flash) in write_jedec() and leave the "dumb check if erase successful" in place, erase the memory with flashrom -E, wait 30 seconds, write to the memory with the flashrom version which does not call erase_chip_jedec(flash) in write_jedec(). I would be very interested in the result.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 20:20, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) {
It reads from the flash and compares the result to 0xff. No write to flash happens.
To me it looks like if bios[i] does not equal 0xff than error...... I know nothing is writing to flash in this function but, this is right after the erase_chip_jedec() runs which writes to flash, correct?
printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; }}
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is part of the write_jedec function. I can do everything else except write (-w) to the flash chip. I get a:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
If I remove the above function from write_jedec flashrom writes to the chip just fine.
It seems erase_chip_jedec() leaves the chip in a bad state. And according to the chip documentation, the value you read means "program/erase finished, programming failed some time since last reset/status register clearing, failed attempt to write to a protected block some time since last reset/status register clearing". However, both spec and real life are unclear whether my interpretation is correct.
This makes sense:-)
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??
Indeed. Have you tried to erase only, then read back the result immediately? That would be very interesting. If the readback is all 0xff, try commenting out erase_chip_jedec(flash) in write_jedec() and leave the "dumb check if erase successful" in place, erase the memory with flashrom -E, wait 30 seconds, write to the memory with the flashrom version which does not call erase_chip_jedec(flash) in write_jedec(). I would be very interested in the result.
I will try this and post my results.
Thanks - Joe
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 20:20, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) {
It reads from the flash and compares the result to 0xff. No write to flash happens.
printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; }}
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is part of the write_jedec function. I can do everything else except write (-w) to the flash chip. I get a:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
If I remove the above function from write_jedec flashrom writes to the chip just fine.
It seems erase_chip_jedec() leaves the chip in a bad state. And according to the chip documentation, the value you read means "program/erase finished, programming failed some time since last reset/status register clearing, failed attempt to write to a protected block some time since last reset/status register clearing". However, both spec and real life are unclear whether my interpretation is correct.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??
Indeed. Have you tried to erase only, then read back the result immediately? That would be very interesting. If the readback is all 0xff, try commenting out erase_chip_jedec(flash) in write_jedec() and leave the "dumb check if erase successful" in place, erase the memory with flashrom -E, wait 30 seconds, write to the memory with the flashrom version which does not call erase_chip_jedec(flash) in write_jedec(). I would be very interested in the result.
Regards, Carl-Daniel
Thanks - Joe
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 20:20, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
Ok, I think I know what is going on here after looking at the uniflash source code. I found this comment in the Intel programming code "Do not program FF, erase will result in all FF's so it's not necessary. Besides, 2*FF means reset ..."
So, I removed this function from jedec.c and rebuilt flashrom.
// dumb check if erase was successful. for (i = 0; i < total_size; i++) { if (bios[i] != (uint8_t) 0xff) {
It reads from the flash and compares the result to 0xff. No write to flash happens.
printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); return -1; }}
It seems to work fine now. Is this a bug for Intel ICH series???
if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is part of the write_jedec function. I can do everything else except write (-w) to the flash chip. I get a:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
If I remove the above function from write_jedec flashrom writes to the chip just fine.
It seems erase_chip_jedec() leaves the chip in a bad state. And according to the chip documentation, the value you read means "program/erase finished, programming failed some time since last reset/status register clearing, failed attempt to write to a protected block some time since last reset/status register clearing". However, both spec and real life are unclear whether my interpretation is correct.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??
Indeed. Have you tried to erase only, then read back the result immediately? That would be very interesting. If the readback is all 0xff, try commenting out erase_chip_jedec(flash) in write_jedec() and leave the "dumb check if erase successful" in place, erase the memory with flashrom -E, wait 30 seconds, write to the memory with the flashrom version which does not call erase_chip_jedec(flash) in write_jedec(). I would be very interested in the result.
Well, I did just want you said above and the readback is not 0xff it looks like a coreboot image. Then I commented out erase_chip_jedec(flash) in write_jedec() and did this:
[root@localhost flashrom]# flashrom -E Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 Flash part is M50FW080 (1024 KB). Erasing flash chip [root@localhost flashrom]# flashrom -wv test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 55! Verifying flash... VERIFIED. [root@localhost flashrom]#
There is definatly something funky going on with erase_chip_jedec(flash) here. I don't think it is a GPIO or anything, I have them setup just like the original bios and uniflash is able to write to it just fine with the original bios.........please help:-(
One difference I did notice this time compared to last is the error: First write with no flashrom modifications: ERASE FAILED @0, val 92! and now with erase_chip_jedec(flash) commented out: ERASE FAILED @0, val 55!
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
Thanks - Joe
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
strace won't show you memory references. That's the only issue.
ron
On 12.03.2008 04:47, ron minnich wrote:
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
strace won't show you memory references. That's the only issue.
Dumping the ICH GPIO settings and PCI config space (once) before and (repeatedly) during a flash operation with the Intel SDK flash utility may help you solve the mystery. If you can't find any differences, you may have to resort to renouveau and revenge (reverse engineering tools of nouveau and radeon developers, respectively).
Regards, Carl-Daniel
On 12.03.2008 13:46, Carl-Daniel Hailfinger wrote:
On 12.03.2008 04:47, ron minnich wrote:
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
strace won't show you memory references. That's the only issue.
Dumping the ICH GPIO settings and PCI config space (once) before and (repeatedly) during a flash operation with the Intel SDK flash utility may help you solve the mystery. If you can't find any differences, you may have to resort to renouveau and revenge (reverse engineering tools of nouveau and radeon developers, respectively).
A PCI config space dump under factory BIOS and coreboot would be appreciated. As I wrote in another mail, knowing the MTRRs would help as well.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.03.2008 13:46, Carl-Daniel Hailfinger wrote:
On 12.03.2008 04:47, ron minnich wrote:
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
strace won't show you memory references. That's the only issue.
Dumping the ICH GPIO settings and PCI config space (once) before and (repeatedly) during a flash operation with the Intel SDK flash utility may help you solve the mystery. If you can't find any differences, you may have to resort to renouveau and revenge (reverse engineering tools of nouveau and radeon developers, respectively).
A PCI config space dump under factory BIOS and coreboot would be appreciated. As I wrote in another mail, knowing the MTRRs would help as well.
here you go.
Thanks - Joe
On 12.03.2008 16:39, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.03.2008 13:46, Carl-Daniel Hailfinger wrote:
On 12.03.2008 04:47, ron minnich wrote:
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
strace won't show you memory references. That's the only issue.
Dumping the ICH GPIO settings and PCI config space (once) before and (repeatedly) during a flash operation with the Intel SDK flash utility may help you solve the mystery. If you can't find any differences, you may have to resort to renouveau and revenge (reverse engineering tools of nouveau and radeon developers, respectively).
A PCI config space dump under factory BIOS and coreboot would be appreciated. As I wrote in another mail, knowing the MTRRs would help as well.
here you go.
Thanks. The enabled set of legacy devices (superio, keyboard, gameport...) differs quite a bit between factory and coreboot. However, even with the additional information I found, the LPC configuration seems to be OK.
I dislike the MTRR settings, though. I would very much like to explicitly disable caching for the top 128 MB.
Have you already tried to set the ICH+SuperIO GPIO settings to the same values as the factory BIOS? If you do that and the issue still happens, we should investigate caching.
AARGH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is a M50FW080 chip, right? The M50FW080 data sheet explicitly states you can NOT issue the chip erase command in FWH mode. erase_sector_39sf020() is the erase routine you need to use in a loop.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.03.2008 16:39, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.03.2008 13:46, Carl-Daniel Hailfinger wrote:
On 12.03.2008 04:47, ron minnich wrote:
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
strace won't show you memory references. That's the only issue.
Dumping the ICH GPIO settings and PCI config space (once) before and (repeatedly) during a flash operation with the Intel SDK flash utility may help you solve the mystery. If you can't find any differences, you may have to resort to renouveau and revenge (reverse engineering tools of nouveau and radeon developers, respectively).
A PCI config space dump under factory BIOS and coreboot would be appreciated. As I wrote in another mail, knowing the MTRRs would help as well.
here you go.
Thanks. The enabled set of legacy devices (superio, keyboard, gameport...) differs quite a bit between factory and coreboot. However, even with the additional information I found, the LPC configuration seems to be OK.
I dislike the MTRR settings, though. I would very much like to explicitly disable caching for the top 128 MB.
Yeh Corey didn't like it much eithor, I think he was talking about an improvment for v3?
Have you already tried to set the ICH+SuperIO GPIO settings to the same values as the factory BIOS? If you do that and the issue still happens, we should investigate caching.
Yes, this I setup this in gpio.c in the mainboard directory.
AARGH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is a M50FW080 chip, right? The M50FW080 data sheet explicitly states you can NOT issue the chip erase command in FWH mode. erase_sector_39sf020() is the erase routine you need to use in a loop.
A guy on my site suggested this:
i don't believe that m50fw080 supports chip erase in fwh mode . you would have to do a sector erase after looking at the data sheet http://www.st.com/stonline/books/pdf/docs/7764.pdf
after looking at flashrom jdec.c file you would also have to change the commands then just loop thru all the blocks to erase look at sst_fwhub.c erase_sst_fwhub()
int erase_block_jedec(volatile uint8_t *bios, unsigned int block) { /* Issue the Sector Erase command */ *(volatile uint8_t *)(bios + 0x5555) = 0xAA; myusec_delay(10); *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; myusec_delay(10); *(volatile uint8_t *)(bios + 0x5555) = 0x80; <-- change to 0x20 myusec_delay(10);
*(volatile uint8_t *)(bios + 0x5555) = 0xAA; myusec_delay(10); *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; myusec_delay(10); *(volatile uint8_t *)(bios + block) = 0x50; <-- change to 0xd0 myusec_delay(10);
/* wait for Toggle bit ready */ toggle_ready_jedec(bios);
return 0; }
Does that make sense? How can we fix this?
Thanks - Joe
On 12.03.2008 20:19, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.03.2008 16:39, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 12.03.2008 13:46, Carl-Daniel Hailfinger wrote:
On 12.03.2008 04:47, ron minnich wrote:
On Tue, Mar 11, 2008 at 5:03 PM, joe@smittys.pointclark.net wrote:
> What does this mean? Also Intel has a development SDK for a > development i830 board very close to this one that has a linux flash > utility (pre-built binary, no source) with it. I am thinking of > trying > it with an ?strace? to see what it does? Would that help to find out > what is going on here? > > strace won't show you memory references. That's the only issue.
Dumping the ICH GPIO settings and PCI config space (once) before and (repeatedly) during a flash operation with the Intel SDK flash utility may help you solve the mystery. If you can't find any differences, you may have to resort to renouveau and revenge (reverse engineering tools of nouveau and radeon developers, respectively).
A PCI config space dump under factory BIOS and coreboot would be appreciated. As I wrote in another mail, knowing the MTRRs would help as well.
here you go.
Thanks. The enabled set of legacy devices (superio, keyboard, gameport...) differs quite a bit between factory and coreboot. However, even with the additional information I found, the LPC configuration seems to be OK.
I dislike the MTRR settings, though. I would very much like to explicitly disable caching for the top 128 MB.
Yeh Corey didn't like it much eithor, I think he was talking about an improvment for v3?
In theory, it should be possible to fix this in v2 as well.
Have you already tried to set the ICH+SuperIO GPIO settings to the same values as the factory BIOS? If you do that and the issue still happens, we should investigate caching.
Yes, this I setup this in gpio.c in the mainboard directory.
Good to know.
AARGH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is a M50FW080 chip, right? The M50FW080 data sheet explicitly states you can NOT issue the chip erase command in FWH mode. erase_sector_39sf020() is the erase routine you need to use in a loop.
Please reread the line above.
A guy on my site suggested this:
i don't believe that m50fw080 supports chip erase in fwh mode . you would have to do a sector erase after looking at the data sheet http://www.st.com/stonline/books/pdf/docs/7764.pdf
after looking at flashrom jdec.c file you would also have to change the commands then just loop thru all the blocks to erase look at sst_fwhub.c erase_sst_fwhub()
int erase_block_jedec(volatile uint8_t *bios, unsigned int block) { /* Issue the Sector Erase command */ *(volatile uint8_t *)(bios + 0x5555) = 0xAA; myusec_delay(10); *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; myusec_delay(10); *(volatile uint8_t *)(bios + 0x5555) = 0x80; <-- change to 0x20 myusec_delay(10);
*(volatile uint8_t *)(bios + 0x5555) = 0xAA; myusec_delay(10); *(volatile uint8_t *)(bios + 0x2AAA) = 0x55; myusec_delay(10); *(volatile uint8_t *)(bios + block) = 0x50; <-- change to 0xd0 myusec_delay(10);
/* wait for Toggle bit ready */ toggle_ready_jedec(bios);
return 0; }
Does that make sense?
No. The modified erase_block_jedec could perhaps work by accident, but this is rather unlikely.
How can we fix this?
As I wrote in my last mail: "erase_sector_39sf020() is the erase routine you need to use in a loop." It is the (mostly) correct routine to use. Simply call it for every block to be erased. There is an equivalent routine for the 20sf040.
However, if you want instant gratification, replace erase_jedec() with erase_lhf00l04() or erase_82802ab(). Those two functions are even closer to the datasheet recommended values. In fact, with them everything should work out of the box, including sector protection.
Regards, Carl-Daniel
As I wrote in my last mail: "erase_sector_39sf020() is the erase routine you need to use in a loop." It is the (mostly) correct routine to use. Simply call it for every block to be erased. There is an equivalent routine for the 20sf040.
However, if you want instant gratification, replace erase_jedec() with erase_lhf00l04() or erase_82802ab(). Those two functions are even closer to the datasheet recommended values. In fact, with them everything should work out of the box, including sector protection.
Carl-Daniel, I don't just want to fix this for "instant gratification". I needs to be a perminant solution. I have alot of people waiting to beta-test the RCA RM4100 coreboot bios and work on the tv-out, but we need to get flashrom working for a fallback/updates first. I can test it with the "instant gratification" method but how to incorperate this into jedec.c so it doesn't interfear with other chips that use jedec.c???
Thanks - Joe
On 13.03.2008 01:36, joe@smittys.pointclark.net wrote:
As I wrote in my last mail: "erase_sector_39sf020() is the erase routine you need to use in a loop." It is the (mostly) correct routine to use. Simply call it for every block to be erased. There is an equivalent routine for the 20sf040.
However, if you want instant gratification, replace erase_jedec() with erase_lhf00l04() or erase_82802ab(). Those two functions are even closer to the datasheet recommended values. In fact, with them everything should work out of the box, including sector protection.
Carl-Daniel, I don't just want to fix this for "instant gratification". I needs to be a perminant solution. I have alot of people waiting to beta-test the RCA RM4100 coreboot bios and work on the tv-out, but we need to get flashrom working for a fallback/updates first. I can test it with the "instant gratification" method but how to incorperate this into jedec.c so it doesn't interfear with other chips that use jedec.c???
Heh. My wording was a little bit on the flowery side. Please test whether the "instant gratification" variant works, if it does, I'll take care to get it into a mergeable shape.
Please note that this will not fix writing, I'm just trying to get erase working and hope you can write to the (socketed?) chip with another tool. If the chip is not socketed, you may want to delay testing.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 13.03.2008 01:36, joe@smittys.pointclark.net wrote:
As I wrote in my last mail: "erase_sector_39sf020() is the erase routine you need to use in a loop." It is the (mostly) correct routine to use. Simply call it for every block to be erased. There is an equivalent routine for the 20sf040.
However, if you want instant gratification, replace erase_jedec() with erase_lhf00l04() or erase_82802ab(). Those two functions are even closer to the datasheet recommended values. In fact, with them everything should work out of the box, including sector protection.
Carl-Daniel, I don't just want to fix this for "instant gratification". I needs to be a perminant solution. I have alot of people waiting to beta-test the RCA RM4100 coreboot bios and work on the tv-out, but we need to get flashrom working for a fallback/updates first. I can test it with the "instant gratification" method but how to incorperate this into jedec.c so it doesn't interfear with other chips that use jedec.c???
Heh. My wording was a little bit on the flowery side. Please test whether the "instant gratification" variant works, if it does, I'll take care to get it into a mergeable shape.
Please note that this will not fix writing, I'm just trying to get erase working and hope you can write to the (socketed?) chip with another tool. If the chip is not socketed, you may want to delay testing.
Of course it is socketed, I did it myself. http://www.coreboot.org/Image:Rca_rm4100_mods.jpg The board does not come socketed though. I have been using uniflash/hotflash to program the bios so far. But that is not really an option for the beta-testers so we need to get flashrom working. When I removed the // dumb check if erase was successful part from write_jedec and tried it seemed to work ok. Thanks for your help Carl-Daniel.
Thanks - Joe
On 13.03.2008 02:04, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
Please note that this will not fix writing, I'm just trying to get erase working and hope you can write to the (socketed?) chip with another tool. If the chip is not socketed, you may want to delay testing.
Of course it is socketed, I did it myself. http://www.coreboot.org/Image:Rca_rm4100_mods.jpg
Cool.
The board does not come socketed though. I have been using uniflash/hotflash to program the bios so far. But that is not really an option for the beta-testers so we need to get flashrom working. When I removed the // dumb check if erase was successful part from write_jedec and tried it seemed to work ok.
So reading from the chip after erase resulted in 0xff for the whole image? If not, I'd be very interested in the read result (use hexdump to check).
Thanks for your help Carl-Daniel.
You're welcome.
Regards, Carl-Daniel
I han't had a chance to test it yet but I think if I just modify flashchips.c to say this it may work:
{"M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_jedec, erase_lhf00l04, write_lhf00l04},
I will test it and report back, with a patch hopefully?
Thanks - Joe
On 14.03.2008 01:21, joe@smittys.pointclark.net wrote:
I han't had a chance to test it yet but I think if I just modify flashchips.c to say this it may work:
{"M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_jedec, erase_lhf00l04, write_lhf00l04},
I will test it and report back, with a patch hopefully?
That would be cool. However, considering Ron's comments, could you use erase_82802ab, write_82802ab instead? They are available again in latest flashrom and are functionally identical to the *_lhf00l04 functions.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 14.03.2008 01:21, joe@smittys.pointclark.net wrote:
I han't had a chance to test it yet but I think if I just modify flashchips.c to say this it may work:
{"M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_jedec, erase_lhf00l04, write_lhf00l04},
I will test it and report back, with a patch hopefully?
That would be cool. However, considering Ron's comments, could you use erase_82802ab, write_82802ab instead? They are available again in latest flashrom and are functionally identical to the *_lhf00l04 functions.
Ahhhhhh:-( Here is what is happening with the above change:
[root@localhost ~]# flashrom -r test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Reading Flash...done [root@localhost ~]# flashrom -E Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Erasing flash chip total_size is 1048576; flash->page_size is 65536 Erase at 0xb7dcc000 Ready:BE RUN/FINISH:BE OK:PROG OK:VPP OK:PROG RUN/FINISH:UNLOCK:write protect is at 0x2 Segmentation fault [root@localhost ~]# flashrom -w test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). total_size is 1048576; flash->page_size is 65536 Erase at 0xb7d2e000 Ready:BE RUN/FINISH:BE OK:PROG OK:VPP OK:PROG RUN/FINISH:UNLOCK:write protect is at 0x2 Segmentation fault [root@localhost ~]# flashrom -v test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Verifying flash... VERIFIED. [root@localhost ~]#
Help?
Thanks - Joe
Quoting joe@smittys.pointclark.net:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 14.03.2008 01:21, joe@smittys.pointclark.net wrote:
I han't had a chance to test it yet but I think if I just modify flashchips.c to say this it may work:
{"M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_jedec, erase_lhf00l04, write_lhf00l04},
I will test it and report back, with a patch hopefully?
That would be cool. However, considering Ron's comments, could you use erase_82802ab, write_82802ab instead? They are available again in latest flashrom and are functionally identical to the *_lhf00l04 functions.
Ahhhhhh:-( Here is what is happening with the above change:
[root@localhost ~]# flashrom -r test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Reading Flash...done [root@localhost ~]# flashrom -E Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Erasing flash chip total_size is 1048576; flash->page_size is 65536 Erase at 0xb7dcc000 Ready:BE RUN/FINISH:BE OK:PROG OK:VPP OK:PROG RUN/FINISH:UNLOCK:write protect is at 0x2 Segmentation fault [root@localhost ~]# flashrom -w test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). total_size is 1048576; flash->page_size is 65536 Erase at 0xb7d2e000 Ready:BE RUN/FINISH:BE OK:PROG OK:VPP OK:PROG RUN/FINISH:UNLOCK:write protect is at 0x2 Segmentation fault [root@localhost ~]# flashrom -v test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Verifying flash... VERIFIED. [root@localhost ~]#
Help?
can't I just setup a m50fw080.c because it is obvious what we have is not working.......
Thanks - Joe
On 14.03.2008 15:34, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 14.03.2008 01:21, joe@smittys.pointclark.net wrote:
I han't had a chance to test it yet but I think if I just modify flashchips.c to say this it may work:
{"M50FW080", ST_ID, ST_M50FW080, 1024, 64 * 1024, probe_jedec, erase_lhf00l04, write_lhf00l04},
I will test it and report back, with a patch hopefully?
That would be cool. However, considering Ron's comments, could you use erase_82802ab, write_82802ab instead? They are available again in latest flashrom and are functionally identical to the *_lhf00l04 functions.
Ahhhhhh:-( Here is what is happening with the above change:
[root@localhost ~]# flashrom -r test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Reading Flash...done [root@localhost ~]# flashrom -E Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "Intel ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). Erasing flash chip total_size is 1048576; flash->page_size is 65536 Erase at 0xb7dcc000 Ready:BE RUN/FINISH:BE OK:PROG OK:VPP OK:PROG RUN/FINISH:UNLOCK:write protect is at 0x2 Segmentation fault
Two solutions: - Replace probe_jedec with probe_lhf00l04 or probe_82802ab. That will fix the segfault. No idea whether the flash chip will be detected with that mod. - Add map_flash_registers(flash); at the beginning of erase_82802ab or erase_lhf00l04 (the one you were calling).
Regards, Carl-Daniel
On 12.03.2008 01:03, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 20:20, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 09.03.2008 08:50, joe@smittys.pointclark.net wrote:
Quoting ron minnich rminnich@gmail.com:
On Sat, Mar 8, 2008 at 11:24 PM, joe@smittys.pointclark.net wrote:
> Ok, > I think I know what is going on here after looking at the uniflash > source code. I found this comment in the Intel programming code "Do > not program FF, erase will result in all FF's so it's not necessary. > Besides, 2*FF means reset ..." > > So, I removed this function from jedec.c and rebuilt flashrom. > > // dumb check if erase was successful. > for (i = 0; i < total_size; i++) { > if (bios[i] != (uint8_t) 0xff) { >
It reads from the flash and compares the result to 0xff. No write to flash happens.
> printf("ERASE FAILED @%d, val %02x!\n", i, bios[i]); > return -1; > } > } > > It seems to work fine now. Is this a bug for Intel ICH series??? > > if it is we should not modify jedec.c -- that seems to work many places. Rather, we need to make a special function -- ich only -- and use that on ich.
Maybe we can add an ich.c to flashrom then??
What are you trying to do? The code you quoted does not write to the chip at all.
If you look at jedec.c at the bottom you would see what I mean. It is part of the write_jedec function. I can do everything else except write (-w) to the flash chip. I get a:
Vendor ID: rca, part ID: rm4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND rca:rm4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 92!
If I remove the above function from write_jedec flashrom writes to the chip just fine.
It seems erase_chip_jedec() leaves the chip in a bad state. And according to the chip documentation, the value you read means "program/erase finished, programming failed some time since last reset/status register clearing, failed attempt to write to a protected block some time since last reset/status register clearing". However, both spec and real life are unclear whether my interpretation is correct.
Can you find out whether ROM shadowing is enabled? That might explain some of the effects. Please try "flashrom --chip M50FW080" for easing and writing and reading as well. I think the probing for other chips may cause some of the strange readbacks.
By the way, there is a bug in erase_chip_jedec() at the end. We use the simple toggle_ready_jedec() to check for end of erase operation and toggle_ready_jedec() spins in a tight loop without delays. Some chips (e.g. W39V040B) are documented to hang/crash/whatever if you try JEDEC toogle bit requests to check for the end of an erase operation in shorter intervals than 50 ms, right now we run the loop 1000000 times faster than allowed.
write_jedec already makes sure not to write 0xff to the chip by calling write_page_write_jedec() which has the check for 0xff inside.
So can we please find the real problem and fix it?
So maybe there is an issue with erase_chip_jedec than??
Indeed. Have you tried to erase only, then read back the result immediately? That would be very interesting. If the readback is all 0xff, try commenting out erase_chip_jedec(flash) in write_jedec() and leave the "dumb check if erase successful" in place, erase the memory with flashrom -E, wait 30 seconds, write to the memory with the flashrom version which does not call erase_chip_jedec(flash) in write_jedec(). I would be very interested in the result.
Well, I did just want you said above and the readback is not 0xff it looks like a coreboot image. Then I commented out erase_chip_jedec(flash) in write_jedec() and did this:
[root@localhost flashrom]# flashrom -E Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 Flash part is M50FW080 (1024 KB). Erasing flash chip [root@localhost flashrom]# flashrom -wv test.rom Calibrating delay loop... OK. Found coreboot table at 0x00000530. Vendor ID: RCA, part ID: RM4100 Found chipset "ICH4/ICH4-L", enabling flash write... OK. NOT FOUND RCA:RM4100 M50FW080 found at physical address 0xfff00000. Flash part is M50FW080 (1024 KB). ERASE FAILED @0, val 55! Verifying flash... VERIFIED. [root@localhost flashrom]#
There is definatly something funky going on with erase_chip_jedec(flash) here. I don't think it is a GPIO or anything, I have them setup just like the original bios and uniflash is able to write to it just fine with the original bios.........please help:-(
Did you check ICH GPIOs and SuperIO GPIOs? Maybe there is some ROM shadowing/caching involved as well. Comparing the MTRRs between proprietary BIOS and coreboot may shed some light on caching.
One difference I did notice this time compared to last is the error: First write with no flashrom modifications: ERASE FAILED @0, val 92! and now with erase_chip_jedec(flash) commented out: ERASE FAILED @0, val 55!
This is very interesting and supports my suspicion about shadowing/caching. Maybe you will see even more changes if you use the --chip parameter for flashrom.
What does this mean? Also Intel has a development SDK for a development i830 board very close to this one that has a linux flash utility (pre-built binary, no source) with it. I am thinking of trying it with an ?strace? to see what it does? Would that help to find out what is going on here?
See Ron's mail and my other mail.
Regards, Carl-Daniel
On Sat, Mar 01, 2008 at 08:04:54AM -0500, joe@smittys.pointclark.net wrote:
Little confused about SMM? In the nothbridge datasheet it talks about SMM (System Management Space), I do not have any of these registers set, just defaults. In the southbridge datasheet it talks about SMM (special mask mode), I do not have any of these registers set eithor, just defaults. Are these related, or two different things? Do I need to set these registers up?
They are different things.
SMM when talking about flashing refers to System Management Mode which is a special task context supported by mobile-only x86 since mobile 386SL and later also non-mobile x86.
http://en.wikipedia.org/wiki/System_Management_Mode
SMM is entered by triggering an SMI (System Management Interrupt) which can be done either by electrical signal to a dedicated pin on the CPU, or by software traps that are defined when initializing SMM.
Software traps can be set on IO and memory access.
This is the technology used by VSA to emulate legacy hardware on Geodes.
When it comes to flashing, accessing the flash chip as usual causes a software trap and the code in SMM (put in place by the factory BIOS during boot) will determine whether to allow this particular access to continue onto real hardware or just fail and return 0xff.
There have been some stories on the list about what the SMM code does to make it's decision, checksums in reserved memory area and whatnot.
//Peter
On 01.03.2008 16:50, Peter Stuge wrote:
On Sat, Mar 01, 2008 at 08:04:54AM -0500, joe@smittys.pointclark.net wrote:
Little confused about SMM? In the nothbridge datasheet it talks about SMM (System Management Space), I do not have any of these registers set, just defaults. In the southbridge datasheet it talks about SMM (special mask mode), I do not have any of these registers set eithor, just defaults. Are these related, or two different things? Do I need to set these registers up?
They are different things.
SMM when talking about flashing refers to System Management Mode which is a special task context supported by mobile-only x86 since mobile 386SL and later also non-mobile x86.
http://en.wikipedia.org/wiki/System_Management_Mode
SMM is entered by triggering an SMI (System Management Interrupt) which can be done either by electrical signal to a dedicated pin on the CPU, or by software traps that are defined when initializing SMM.
Software traps can be set on IO and memory access.
This is the technology used by VSA to emulate legacy hardware on Geodes.
When it comes to flashing, accessing the flash chip as usual causes a software trap and the code in SMM (put in place by the factory BIOS during boot) will determine whether to allow this particular access to continue onto real hardware or just fail and return 0xff.
There have been some stories on the list about what the SMM code does to make it's decision, checksums in reserved memory area and whatnot.
That's why I want to know if this also happens under coreboot. If so, we can rule out that sort of SMM because coreboot does not use SMM yet.
Regards, Carl-Daniel
On Sat, Mar 01, 2008 at 08:04:54AM -0500, joe@smittys.pointclark.net wrote:
Do I need to set these registers up?
Sorry, I didn't answer this.
No, you don't have to set up SMM when using coreboot.
But coreboot needs to know what tricks the factory BIOS is hiding in it's SMM code, if any.
//Peter
-
Carl-Daniel Hailfinger -
joe＠smittys.pointclark.net -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Tom Sylla