Dangerous Prototypes Open Source Hardware

Re: Flashrom extension development

Reply #30 – August 06, 2010, 12:33:16 pm

[quote author="ian"]
I'm hesitant to change the version string because other apps (AVRdude) would have to be updated even though their commands were not effected. If mode is SPI1, 0x00 will always exit SPI and end up in BBIO.
[/quote]

I can see your point I think it is the only safe way to tell if the improved commandset is there. Alternatively before entering the binmode see what the output is of command 'i' (not as neat as a new version number.

Re: Flashrom extension development

Reply #31 – August 06, 2010, 01:54:43 pm

It's a bit hackey, but the easiest thing that will probably take the least time and program space is to add command 0x06 to SPI that returns the flashrom protocol version number. On old firmware it will return 0x00, in this version we can return 0x01, if it changes we can return higher numbers.

Re: Flashrom extension development

Reply #32 – August 07, 2010, 04:25:40 am

Implementing a reliable(!) cross-platform receive-with-timeout that actually works would be an interesting challenge.

I know that the Nack reply was also meant as a way to check for the presence of a command. May I suggest an alternative which would be generic and take care of this, yet stay backwards compatible?
Add a new check-if-command-available (CHECK) command. The command could be 0xff to make it obvious that it is special...

To use it, you send
CHECK CHECK.
Old Bus Pirates will respond with Nack Nack
New Bus Pirates will respond with Ack

To check for the availability of a command once you know CHECK is available, send
CHECK WHATEVERCOMMAND
If WHATEVERCOMMAND is supported, new Bus Pirates will send Ack
If WHATEVERCOMMAND is not supported, new Bus Pirates will send Nack
Old Bus Pirates should never be called with CHECK+WHATEVERCOMMAND except CHECK+CHECK

The scheme will break down if we ever get multibyte commands where the first byte alone is not enough to check if the command is supported. OTOH, I didn't hear of anyone planning such commands.

Thoughts?

Re: Flashrom extension development

Reply #33 – August 07, 2010, 10:06:41 am

I would say ditch the backwards compatibility! The programs that use it should check if _minimal_ SPI1 is returned, and also accept SPI2 and higher.

The version string is ment IMHO to tell the current commandset, i.e. SPI1 is the old one and SPI2 is the newer one.

If we don't want to go this route, flashrom should issue the command 'i' and determine the firmware and check if this a minimal release. Alternatively an binary version of the command 'i' could be implemented. Spacewise I would then opt for the 'i' command.

the 'i' command: http://dangerousprototypes.com/docs/Bus ... nformation

Re: Flashrom extension development

Reply #34 – August 07, 2010, 03:34:59 pm

Checking for SPI1/SPI2 is a good idea, but this means every flashrom user would have to upgrade flashrom to use a newer firmware at all, even if the newer firmware still supports the old commands.

How future-proof is it to enter bitbang mode, exit it, run "i", parse the result, and enter bitbang mode again? Will modular Bus Pirate firmware (only a selected number of features) break such detection?

Or do we simply take the easy route and hack around the issue for now?

Another option (which may or may not be feasible anymore) is to use feature bits. One bitfield for backwards incompatible changes, and one bitfield for new features which don't break backwards compat... something similar has been used for the ext2/ext3/ext4 filesystems and it worked pretty well in that case, even though there were countless extensions.

Re: Flashrom extension development

Reply #35 – August 07, 2010, 04:30:14 pm

I have committed to keeping the info screen the same for scripts, though a version command would probably be best. I'll try to add one on Monday.

Re: Flashrom extension development

Reply #36 – August 07, 2010, 05:23:19 pm

[quote author="biosflasher"]
Checking for SPI1/SPI2 is a good idea, but this means every flashrom user would have to upgrade flashrom to use a newer firmware at all, even if the newer firmware still supports the old commands.
[/quote]
Basicly yes. But you could say when we change it now the features are now mature and working. version 5.6+ is the way to go for fast programming and the older versions only slow programming is reliable. Changing firmwares is btw easier then it sounds. With the v4 bootloader you could go back to firmware 4.0. If you (or the adience) really needs it, we could either recompile the old sources or  write a bootloader v2 installer. (don't think it make sense, since most of the feature from the past are still in). Everyone should upgrade in my opinion.

[quote author="biosflasher"]
How future-proof is it to enter bitbang mode, exit it, run "i", parse the result, and enter bitbang mode again? Will modular Bus Pirate firmware (only a selected number of features) break such detection?
[/quote]

I would suggest to keep a minimum of sump, binmode, 2wire, 3wire with the scripting/usermacros in (the base). Then spread the protocols and make the build. The info presented by 'i' would off course tell which things are compiled in (or an other command 'I' perhaps).

[quote author="biosflasher"]
Or do we simply take the easy route and hack around the issue for now?
[/quote]

IMO no. Then it will be a hack forever.. (it will never addressed again)

Re: Flashrom extension development

Reply #37 – August 08, 2010, 03:13:52 am

In order to distinguish versions, can you program the Internal EEPROM in the FT232R so that it has a different Device Version Number?  The VID/PID would have to stay the same, but maybe the version could change.