How did P2 Code Protection end up ?
Bean
Posts: 8,129
in Propeller 2
I must admit I haven't been following the P2 closely, and I don't want to start a whole discussion.
But how was the P2 Code Protection left ? I remember something about the fuses not being reliable.
If it was removed, so be it. I am not advocating any change. I just need to make plans for our future products.
Thanks,
Bean
But how was the P2 Code Protection left ? I remember something about the fuses not being reliable.
If it was removed, so be it. I am not advocating any change. I just need to make plans for our future products.
Thanks,
Bean
Comments
Bean
I am uncertain whether you said that in jest, but just imagine how many customers Parallax could have gained with the P2, if there was code protection.
Yes, I noticed the smiley face, but I was still uncertain
Hopefully we will end up with an over abundance of open source code and examples, otherwise P2 sales may suffer.
Yes, fuses are removed.
There is a Serial boot mode, so I'd expect small MCUs to be used for some 'better security' cases.
Those can include dongle-like token exchange that increases the hacking effort needed.
What level of security do you need in your future products ?
Our main concern is duplication of the product, not obfuscation of the code.
Bean
A small MCU could be used as a key/dongle, or you might be able to use Serial Flash with features like these ?
One example could be FM25Q08A at 16c/100
With a 64 bit unique ID, you could recompile code with that burnt in (more secure, but more admin), or have a valid-list it checks.
The OTP 256 byte areas also broaden your security scope, as running code can index into that, increasing the hacking effort some more...
I will just stay with the P1 I guess.
Bean
Note P2 has Smart pins that simply do not exist in P1, as well as a lot more MHz & more RAM, and Interrupts and Hubexec, plus mathops.....
So, if you have zero use for any of those, the P1 looks to be ok.
P1 is always going to be smaller, cheaper and lower power than P2
Yeah, the smart pins can do a lot, but for sure a cog can much more.
Are all 64 pins "smart pins" ? If so, I think that is over kill. I would have rather had a limited number of "smart pins" and had 16 cogs.
But that is just me, I'm sure there was a rational decision made about RAM/COGS/SmartPin sizes. You only have so much real estate to work with.
It is just disappointing that the two features I would have really liked (16 Cogs and code protection) didn't make the cut.
Bean
Yes, Bean, some compromises were made. Sixteen cogs were going to take way too much die space and code protection was going to require some OnSemi IP that would have been difficult to integrate. Our original fuse topology, it was understood later, had a 1-in-400 failure rate, which would have necessitated some redundancy and it would still not be known if a particular chip would have sufficiently-functional fuse bits to meet requirements.
I think you might be enthused, though, about what smart pins can do. They free cogs from bit-banging a lot of things and they can be concurrent, among themselves, if needed.
I'm excited about the smart pins. It looks like they can do some amazing things. And the extra speed of the P2 will sure help.
BTW: It would be nice to have some kind of bullet list of the P2 specs because it is really difficult to find what they are by searching.
Bean
https://docs.google.com/document/d/1UnelI6fpVPHFISQ9vpLzOVa8oUghxpI6UpkXVsYgBEQ/edit?usp=sharing
Thanks Chip.
My impression we had better improve our coding skills (a LOT) to take advantage of all the features of the Prop 2 chip. How could we (myself included) now write some blow-a-way code examples for this new Prop 2 chip, that would "WOW" the competition when the P2 chip is released? I am pretty good at programming code, but would be hard pressed to write a demo that would come close to really showcasing all the new features of the P2 chip.
Yup, sometimes the best documentation includes working examples
Others call this BSP or Board Support Package, and that has loaders/downloaders/debug/and examples/ directories.
Good examples are of
Smallest and simplest pin toggle (SW) and Smallest and simplest pin toggle (HW), then the limit case of Nearly_All_Pins_Toggle_HW
Then examples of each Smart pin mode in use, again, simplest 'make it work' and make-many-work, all to the best resolution....
These also show the usage range so demonstrate the baud Range of a UART for example.
Then, some actually useful apps -
The Reciprocal Frequency Counter Bean has for the P1 would port very well to the smart pins of P2.
As a multiple example I think close to 32 Counters would fit into P2
The smart pins are what sets P2 apart from the other 'me too' MCUs so example support for those should be a early focus.
Testing has been thin on Smart Pins and streamer, so fingers crossed the errata list is minor...
P2 can boot from a modest 25c+ MCU, so some security is possible that way.
Time to get yourself an FPGA board and get cracking with some of those excellent suggestions.
Come on, show us what you can do!
With actual P2's close, a FPGA would be a poor investment, plus FPGAs are not actually the final silicon, so I'm patient enough to wait for real P2 modules.
So there is plenty of time to develop and test code. IIRC the BeMicroCV-A9 was only ~$120. If that is too expensive, then there is the smaller, more limited single cog De-Nano.
Can't seem to find any but it makes you wonder how much dust many of those Parallax 123-A9 boards are gathering since they made them up especially for P2 testing. Testers need boards, and there are none to be had.
If a Prop123-A9 or a BeMicroCV-A9 suddenly becomes available I would like to know about it ;-)
I'm not interested in the smaller boards. If I'm going to jump in I want the closest thing to the chip as I can get.
Also, not having used FPGAs/CPLDs for over 15 years, it would be really awesome to have an outline (instructions even !?!) on how to get a Prop2 image loaded. I'm sure its been posted on the forum several times somewhere :-). (Google doc anyone?)
Jason
If we can get our act together, a flash and SD plugin, too
(The /5 is for COM5. I've got Wine configured to assign COM5 to the first USB virtual comport)
After that you can use PNut.exe for programming the virtual Prop2 (in the FPGA). Or you could use Dave Hein's tools. I use Dave's loadp2 which has a convenient terminal emulator built in. This allows simple reporting/debug.