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.