Hi all,
I'm in the process of setting up a retro PC (a 286) and because the machine's BIOS doesn't support IDE drives, I am hoping to put the open source XTIDE BIOS in this machine as an option ROM. I have a network card that can make EEPROMs visible at the right memory locations, so all I need to do is flash the XTIDE code onto an EEPROM and install it in the old PC.
I have an EEPROM I am planning to use for this (an SST29EE020) and I'm using a 3Com NIC to attempt to flash the XTIDE code into it. However when I try this, I get an error:
Error: Image size (8192 B) doesn't match the flash chip's size (262144 B)!
While I understand this would normally be a problem, for me it's fine - I'm only interested in the first 8kB and the rest of the chip is not important to me. But I couldn't find any options to tell flashrom to continue and flash anyway, and --force didn't help.
My first thought was that perhaps I just need to pad the ROM image out so that it matches the chip size, but then I run into a problem. The chip is 256kB, but the 3Com NIC is apparently (according to flashrom) only capable of addressing up to 128kB.
This means if I force it, the second 128kB (the padding) will probably just get written over the first 128kB, overwriting the data I want to keep. I guess I could pad out the 8kB XTIDE image to only 128kB, then double that to get a 256kB image, but it's all very kludgy!
Since flashrom has options to erase the chip, would it be possible to add another option to allow partial flashing? This would allow me to flash my 8kB image without worrying about address wraparound or having to flash 248kB of blanks when I don't have to!
BTW flashrom (latest stable) tells me the SST29EE020 is untested, so I would be happy to report back with my results, assuming you accept flashing a 256kB chip in a 128kB programmer as a valid test ;-)
Many thanks, Adam.
On Sun, 22 Nov 2015 18:57:16 +1000 Adam Nielsen a.nielsen@shikadi.net wrote:
Error: Image size (8192 B) doesn't match the flash chip's size (262144 B)!
While I understand this would normally be a problem, for me it's fine - I'm only interested in the first 8kB and the rest of the chip is not important to me. But I couldn't find any options to tell flashrom to continue and flash anyway, and --force didn't help.
Don't use the force switch. It's the dark force :P
I guess I could pad out the 8kB XTIDE image to only 128kB, then double that to get a 256kB image, but it's all very kludgy!
But the right way, currently.
would it be possible to add another option to allow partial flashing?
Yes, and we are working on that. The current state of affairs can be found here: https://github.com/XVilka/flashrom/tree/libflashrom_layout One needs to write a layout file to use the additional functionality but the base for it is already integrated, see below.
You are facing two problems actually:
1. flashrom expects a 256 kB file for a 256 kB flash chip. This does not completely change even with the patches above in their current form. So you still would need to prepare a file with 256 kB, although with the patches integrated it would no longer matter what is in there because you could specify additional files for any specific address ranges which need to be just as big as that range. 2. You want to write only a part of the chip. Either 128 kB because that's what the programmer is capable of, or even less because that's what your payload size is. flashrom supports this out of the box with layout files already. So you could prepare a 256 kB file with only the first 8 kB of valid data and use a layout file to tell flashrom to only write those 8 kB and stop then.
BTW flashrom (latest stable) tells me the SST29EE020 is untested, so I would be happy to report back with my results, assuming you accept flashing a 256kB chip in a 128kB programmer as a valid test ;-)
I think our policy regarding this is not to mark them as tested because that access pattern could hide some real bugs even if that's unlikely. After all, "untested" does not mean unsupported... all chips in the code base should just work.
Many thanks for the quick reply!
Don't use the force switch. It's the dark force :P
Well on that note, I also wanted to dump some AT27C010 chips, which are one-time programmable, but electrically compatible for read operations with "standard" chips like the AT29C010A.
I couldn't dump anything because flashrom told me no EEPROM was detected. By using --force and specifying AT29C010A I was warned I would probably get garbage, but the chip content was successfully written to a file.
Are there plans to add read-only support to flashrom for these cases? I am guessing this would be (relatively) easy because to my knowledge, you don't need special commands to read data out of the chips. They are all just read in the same way (at least with the nic3com and nicrealtek programmers). I imagine you'd just need a handful of generic devices that specify the size of the chip and only support read operations?
The reason for wanting read support for a non-flash chip is for hardware experimentation. If you want to modify a device with a non-flashable ROM chip, you can replace it with an electrically compatible EEPROM. But first you have to copy the data from the ROM chip over to the EEPROM (perhaps modifying it on the way), so for that you need the ability to dump non-flash chips.
I guess I could pad out the 8kB XTIDE image to only 128kB, then double that to get a 256kB image, but it's all very kludgy!
But the right way, currently.
Sure. I found an actual AT29C010A which is only 128kB and tried to flash this with the XTIDE data, padded out to 128kB. It seemed to work, although flashrom told me it took two goes to do it. Dumping it again afterwards produced the original data. I think the error was probably because I hadn't put the chip securely enough into the socket, because I wanted to remove it again without powering down the PC and removing the 3Com NIC!
I've attached the log because it said the AT29C010A was untested.
One needs to write a layout file to use the additional functionality but the base for it is already integrated, see below.
Thanks for that! I'll have a look at it and see if I can figure out what needs to be done.
I think our policy regarding this is not to mark them as tested because that access pattern could hide some real bugs even if that's unlikely. After all, "untested" does not mean unsupported... all chips in the code base should just work.
Sure no worries, completely understandable!
Cheers, Adam.
On Sun, 22 Nov 2015 20:46:21 +1000 Adam Nielsen a.nielsen@shikadi.net wrote:
Don't use the force switch. It's the dark force :P
Well on that note, I also wanted to dump some AT27C010 chips, which are one-time programmable, but electrically compatible for read operations with "standard" chips like the AT29C010A.
I couldn't dump anything because flashrom told me no EEPROM was detected. By using --force and specifying AT29C010A I was warned I would probably get garbage, but the chip content was successfully written to a file.
That's about the only situation where the force switch does the right thing :)
Are there plans to add read-only support to flashrom for these cases? I am guessing this would be (relatively) easy because to my knowledge, you don't need special commands to read data out of the chips. They are all just read in the same way (at least with the nic3com and nicrealtek programmers). I imagine you'd just need a handful of generic devices that specify the size of the chip and only support read operations?
flashrom works by probing for the chip ID and looking for that in its database for the details like capacity and block sizes. EEPROMs do not support any ID commands so that scheme cannot work. Specifying all the details via the command line is not really a good idea. However, specifying generic devices could indeed be an option - in the long term.
I've attached the log because it said the AT29C010A was untested.
I would need to dig into that a bit, because the write error you saw could actually come from a not perfectly matching write function... the code has a fixme comment I don't know about. Unfortunately, I won't have time for that today, but I'll put it on my todo list.
-
Adam Nielsen -
Stefan Tauner