I considered that pin mapping, too, but because pins 87..80 are Byte3 of PortC, they need to be used for potentially-multiple data bits, as this allows efficient MOVF instructions to grab 4 or 8 bits at a time and pack them into a variable quickly. If they were shifted down by one, you couldn't read or write them very efficiently.
Maybe we should formulate the goals to archive and then decide what to do:
#1 Cluso wants to have the ability to build a board without flash IF he needs sd anyway. Else boot from flash ok.
#2 Me and others where speaking about Firmware-updates in the field where flashing/serial with a pc is not available.
Are there Flash in sockets? this would eliminate #2
I still think #1 is valuable.
having Flash and sd on the same pins is not sensible - see c3. If you have flash sd can be anywhere if needed with full fat-support.
but booting from removabe media is way cool. since we can create any bootable sd on a prop or make it bootable there. what about those unused sectors after the mbr? we need 8 sectors for a cog. Just read sector 3 to 11. start what is there to do more.
or - forget about it and put my MONITOR in.
@chip why backdoor? If it fails to load the program in the first place there is nothing to protect ?
If it does this because of an abort? hm. a fuse to disable onboard monitor?
having the ability to write to the hub via serial-debug and start a cog with some adress? THAT would be cool.
and having some standard adress to jump to for starting a MONITOR without wasting precious program-code is very tempting.
It could be that the 4 SPI pins could connect to either a flash or an SD card. If you wanted both, just connect the non-booter's spi_cs pin elsewhere with a pull-up resistor.
I know, removable media for booting would be really neat, without any potential hang-up in a pre-SD-boot flash.
You're right about the back door not being a problem - Duh! Some people don't want anyone running unauthorized code on their chip, though, so I think if you had a non-0 key pattern, it shouldn't run the monitor.
I agree that for a monitor to be able to read and write hub memory and launch cogs would be cool. It could be very small, too. It would have to auto-baud, though, as the chip runs from an RC clock on power up, and you couldn't make any assumptions about a crystal. It seems to me that you could measure all low pulses coming into RX and bin them out to realize some integral relationship, which you could determine the baud rate from. This should be going on constantly to track drift if the chip heats (tweaking the RC oscillator), or changes speed due to a cog turning on another clock source. Maybe a few <enter> taps could always correct it.
Maybe the commands could be like this:
<enter> 'dump next 16 bytes
address 'dump 16 bytes starting at address
W address byte byte byte 'write byte(s) to address
G cog address address 'start cog with code and parameter addresses
X cog 'stop cog
P value 'write value to hub clock control
A command-based monitor is cool because it doesn't need any other COG to feed its data structures or interact with it - commands come from a serial host and results go back to the host. It only needs to be started.
Wait! this could only be automatically launched on boot-fail if all the security fuse bits were 0's (not set, so no key was in use). Otherwise, this would be a huge back door past security. You know, it could even serve, incidentally, as a text-based loading mechanism that would be trivial to operate.
I couldn't find the original post suggesting a monitor so I'll reply to this one. I suppose I'll get a lot of flack for this suggestion but if you're thinking of adding a monitor, you might want to consider something based on Forth. It has been used in the past in Open Firmware although that itself is certainly too big but doing a very simple Forth would allow you a bit of programmability that you won't get with just a simple command parser.
I couldn't find the original post suggesting a monitor so I'll reply to this one. I suppose I'll get a lot of flack for this suggestion but if you're thinking of adding a monitor, you might want to consider something based on Forth. It has been used in the past in Open Firmware although that itself is certainly too big but doing a very simple Forth would allow you a bit of programmability that you won't get with just a simple command parser.
You mean something along the lines of Peter J's Tachyon???? Hmmmmm, Forth, the serendipity of place and time converging on the P2!
You mean something along the lines of Peter J's Tachyon???? Hmmmmm, Forth, the serendipity of place and time converging on the P2!
Exactly but unfortunately even that may be too big for the ROM. I've lost track of this discussion. Are we still talking about 150 spare longs or has the ROM been expanded?
I suppose I'll get a lot of flack for this suggestion but if you're thinking of adding a monitor, you might want to consider something based on Forth.
Consider yourself well and truly flaked:)
Please God, let it not fit.
Now, if your monitor could provide commands for setting pin direction and reading/writing pins the Prop II would make a great I/O expander without having to write a line of code for it:)
Now, if your monitor could provide commands for setting pin direction and reading/writing pins the Prop II would make a great I/O expander without having to write a line of code for it:)
Sorry, I'm not a Forth evangalist but I do like programmable systems and I think Forth is probaby the best way to add programmability in a tiny amount of space.
Exactly but unfortunately even that may be too big for the ROM. I've lost track of this discussion. Are we still talking about 150 spare longs or has the ROM been expanded?
If it gets expanded then it better damn well be bank switchable with the RAM.
We have had a lot of trouble at Parallax with soldering leadless IC's, too. They are a pain. I totally blame the lousy solder chemistry that has been forced on us. Eutectic tin/lead always worked perfectly. Now, we have poor wetting and a long plastic state during cooling.
Odd. I actually like soldering QFNs. If it's the solder that seems to be the problem, SparkFun has a "Special Blend" lead-free solder that feels extremely similar to tin/lead; at least it has nearly the same surface tension. Using this, I've had no trouble soldering QFNs by hand, and actually prefer them over QFPs.
I'm actually glad to hear that. I wasn't really in favor of giving up hub RAM in exchange for a more complex boot program. However, I'm not an embedded system designer so I have to trust Parallax to know whether the value to their customers of the features being discussed here really outweigh the loss of hub RAM.
Now, if your monitor could provide commands for setting pin direction and reading/writing pins the Prop II would make a great I/O expander without having to write a line of code for it:)
You mean like....hmmmmm...Forth? {well past flaked, thank you!!}
Was thinking more about this first loader just being used to start a second loader that will allow you to load via USB, FAT SD, or JEDEC identified flash, etc...
Seems that 99.9% of the time, you'd just want to load some simple code off of SPI compatible flash.
The only reason maybe to do otherwise is the update the SPI code.
In that case, I think you do want the SPI boot to be last in the sequence with serial and SD coming first.
But, it'd be nice for the SD booter to read just the first couple bytes of block 0 for some special code that signifies that we want it to boot....
Cluso's already claimed that part. Assuming he can get the SD code to fit that is.
I wish him good luck. I'd offer to help but I think Cluso is a better PASM programmer than I am. Are there low-level SPI functions in the SPI flash boot code that can be used?
some posts ago someone was taking about how to indicate boot failure.
In the old days on the early HP-Vectra PCs we indicated boot failures by blinking some LED in different specific pattens. (or beep the speaker)
Would it make sense in a multi-boot setup to indicate what went wrong by blinking a LED (on one of the boot pins) ? - of course with LED OPTIONAL !!
there is nothing more to do for the prop anyhow ...
I agree a tiny forth would be just as cool as a monitor would be. If either one can go in that space, and I'm quite sure a simple monitor could, I'm all for that, provided it's got the options Heater mentioned. Maybe SD just won't work due to complexitites. If that's true, adding one or these would be great! And I think the Forth would be particularly great, because it is programmable. Of course, a tiny forth kernel can be stuffed through the monitor, then launched too. Either way, it would be possible to boot strap a prop into some interactive, programmable mode via serial only. Cool, but not strictly necessary.
A while back I used a program on the Apple that did precisely that. One powers up the machine, it fails to boot, enter monitor and from there, either type a kernel in, or take it over serial. Once that is running, the machine has "booted" and lots can be done. (ADT does this to establish a boot disk on an Apple that doesn't have one.)
Been thinking about SD card. Removable media is compelling for a whole lot of reasons. The flash chips go into sockets, meaning we've got what we have now with EEPROM. That does meet the goal, just not in that really easy way SD does.
The big draw on an SD card is the idea that one can just connect to a PC and write to a filesystem to do updates. Are there, or can there be devices designed and built that basically do a similar thing with flash over USB? Make simple media, in other words. Maybe costs are too high for this, but I thought it worth some discussion. After all, there will be a considerable length of time to build solutions for completed P2 chips. Maybe a really big run makes sense to get them down to some reasonable per part cost. Existing adapters can be utilized too, just need to insure the form factors all make sense. Lots of choices there. Worth a thought, IMHO.
A prop based board could interface with the PC too, or use some other device, doesn't matter. What would matter is that flash chip would be presented to the PC as a file system. User does a simple file operation, that gets translated and the data ends up on the chip same as it would for an SD card. That doesn't get all the "remote tech has PC only" use cases, but it does address a whole lot of them.
RE: Code authorization. (I really hate this, but it's necessary in the ugly world we live in)
Suppose there are two cases. Unfused prop. That one is easy. On boot fail, launch it, and it waits for keystrokes to understand comms.
For a fused prop, send same keystrokes, then the damn hash, then launch it? Or just don't... Probably don't is the best case, because that's a back door attempt made easy, though it would take a LOT of tries...
Another random thought: A monitor that can fire off a LMM program would be useful. Doesn't need to be the most efficient kernel, just one that works. Large programs could be uploaded in one stage that way. One could input PASM directly and run it, without firing off another COG too.
Chip: Is there any chance you could post the low-level code for accessing both the SPI bus and the UART? It would be helpful in determining if interesting stuff will fit in the remaining 150 longs. A lot more can be done if there is some low-level code to build on.
I recommend two ChipSelect (CS) lines, so official there can be both SPI-Flash and SD-card both sharing same SPI lines.
If board designer want to use different SD pins for speed reason, the custom SD fat16 in spi-flash would take care of that.
But to be able to eliminate FDI chips etc, with an empty or corrupt spi-flash (or a jumper on the board to temp disable its CS line)
So Prop-II will first try to boot for SPI-Flash and then move on to SD
There should be a header in boot code to say: copy code on SD-Card to SPI-Flash.
Great for in field firmware upgrade, one SD card you move from device to device.
Maybe a 4 second delay, so you have time to restore jumper to re-enable Spi-Flash.
Though sounds cumbersome, it will actually protect for accidental rewriting of firmware.
There should be a header in boot code to say: copy code on SD-Card to SPI-Flash.
Great for in field firmware upgrade, one SD card you move from device to device.
Maybe a 4 second delay, so you have time to restore jumper to re-enable Spi-Flash.
Though sounds cumbersome, it will actually protect for accidental rewriting of firmware.
That would be very nice, and wouldn't require anything beyond having bootable SPI flash which checks for an SD card and performs this operation. It could indicate completion by blinking a green LED.
Maybe we could reuse two boot pins to drive a bi-color LED for boot signalling.
Chip: Is there any chance you could post the low-level code for accessing both the SPI bus and the UART? It would be helpful in determining if interesting stuff will fit in the remaining 150 longs. A lot more can be done if there is some low-level code to build on.
Thanks,
David
It's in the first code block of post #562. It's so simple to do SPI that the bit twiddling just mixes into the loops which you'd need, anyway, to handle the data. So, there's not much to reuse, but not much to recreate, either.
It's in the first code block of post #562. It's so simple to do SPI that the bit twiddling just mixes into the loops which you'd need, anyway, to handle the data. So, there's not much to reuse, but not much to recreate, either.
>require anything beyond having bootable SPI flash
The idea is to have this function in Prop-II rom, as to avoid the chicken or the egg situation.
LED boot signaling would be nice, simple putting a bi-color led to both CS lines should suffice.
I agree a tiny forth would be just as cool as a monitor would be. If either one can go in that space, and I'm quite sure a simple monitor could, I'm all for that, provided it's got the options Heater mentioned. Maybe SD just won't work due to complexitites. If that's true, adding one or these would be great! And I think the Forth would be particularly great, because it is programmable. Of course, a tiny forth kernel can be stuffed through the monitor, then launched too. Either way, it would be possible to boot strap a prop into some interactive, programmable mode via serial only. Cool, but not strictly necessary.
A while back I used a program on the Apple that did precisely that. One powers up the machine, it fails to boot, enter monitor and from there, either type a kernel in, or take it over serial. Once that is running, the machine has "booted" and lots can be done. (ADT does this to establish a boot disk on an Apple that doesn't have one.)
Been thinking about SD card. Removable media is compelling for a whole lot of reasons. The flash chips go into sockets, meaning we've got what we have now with EEPROM. That does meet the goal, just not in that really easy way SD does.
The big draw on an SD card is the idea that one can just connect to a PC and write to a filesystem to do updates. Are there, or can there be devices designed and built that basically do a similar thing with flash over USB? Make simple media, in other words. Maybe costs are too high for this, but I thought it worth some discussion. After all, there will be a considerable length of time to build solutions for completed P2 chips. Maybe a really big run makes sense to get them down to some reasonable per part cost. Existing adapters can be utilized too, just need to insure the form factors all make sense. Lots of choices there. Worth a thought, IMHO.
A prop based board could interface with the PC too, or use some other device, doesn't matter. What would matter is that flash chip would be presented to the PC as a file system. User does a simple file operation, that gets translated and the data ends up on the chip same as it would for an SD card. That doesn't get all the "remote tech has PC only" use cases, but it does address a whole lot of them.
RE: Code authorization. (I really hate this, but it's necessary in the ugly world we live in)
Suppose there are two cases. Unfused prop. That one is easy. On boot fail, launch it, and it waits for keystrokes to understand comms.
For a fused prop, send same keystrokes, then the damn hash, then launch it? Or just don't... Probably don't is the best case, because that's a back door attempt made easy, though it would take a LOT of tries...
Another random thought: A monitor that can fire off a LMM program would be useful. Doesn't need to be the most efficient kernel, just one that works. Large programs could be uploaded in one stage that way. One could input PASM directly and run it, without firing off another COG too.
I need a crash course on Forth to gain some understanding of it. Sounds neat.
Potatohead, code authentication is a really neat thing. It not only has a security aspect, but serves as a thorough validation mechanism. Image you read a bunch of data out of a flash that you intend to execute. It would be good to know that you've got a real program, or that the flash was even plugged in, before running the code. HMAC does this in a very fail-safe way. In practice, chips will have their keys=0 in development environments, meaning that you just compute the HMAC with a key of 0. A default monitor program would even bypass all this.
I need a crash course on Forth to gain some understanding of it. Sounds neat.
If anyone is really seriously considering it as an option for a monitor program someone should ask Peter Jakacki about whether it is possible to squeeze a useful subset of Forth into the space we have remaining. He seems to be the current wizard of tiny implementations of Forth for the Propeller.
That would be very nice, and wouldn't require anything beyond having bootable SPI flash which checks for an SD card and performs this operation. It could indicate completion by blinking a green LED.
Maybe we could reuse two boot pins to drive a bi-color LED for boot signalling.
Meh, leave this up to the second stage boot loader code, seems likes a waste of ROM to me...
Comments
What pins You use -- That You know better that me.
BUT -- only criteria are as it have ---> 2 separate CS signals for Flash and SD.
pin xx = SPI CSF
> Flash
pin xx = SPI CSD
> SD
Here is an 8-pin DIP flash chip: http://www.digikey.com/product-detail/en/W25Q80BVDAIG/W25Q80BVDAIG-ND/2208452
It could be that the 4 SPI pins could connect to either a flash or an SD card. If you wanted both, just connect the non-booter's spi_cs pin elsewhere with a pull-up resistor.
I know, removable media for booting would be really neat, without any potential hang-up in a pre-SD-boot flash.
You're right about the back door not being a problem - Duh! Some people don't want anyone running unauthorized code on their chip, though, so I think if you had a non-0 key pattern, it shouldn't run the monitor.
I agree that for a monitor to be able to read and write hub memory and launch cogs would be cool. It could be very small, too. It would have to auto-baud, though, as the chip runs from an RC clock on power up, and you couldn't make any assumptions about a crystal. It seems to me that you could measure all low pulses coming into RX and bin them out to realize some integral relationship, which you could determine the baud rate from. This should be going on constantly to track drift if the chip heats (tweaking the RC oscillator), or changes speed due to a cog turning on another clock source. Maybe a few <enter> taps could always correct it.
Maybe the commands could be like this:
if called by abort/userprogram it can just read current clock-settings. but on startup we do not know. you have a point there.
another command would be some kind of trigger-wach this long until whatever happens, then start pushing out data do the debug window.
remember even if everything is ok you can start a cog with it and watch your program. If you have a cog left free.
even if you need to type a couple of 'U' s for baud-detection. It is small and useful.
disabled when encrypted might do it. It is more for the development stage.
we could use TV and make it BLUE!
Enjoy!
Mike
trigger on mailbox-longs... you see when and if what happens ...just giving out cnt, adress, value on change of the value of adress.
Mike
You mean something along the lines of Peter J's Tachyon???? Hmmmmm, Forth, the serendipity of place and time converging on the P2!
Consider yourself well and truly flaked:)
Please God, let it not fit.
Now, if your monitor could provide commands for setting pin direction and reading/writing pins the Prop II would make a great I/O expander without having to write a line of code for it:)
If it gets expanded then it better damn well be bank switchable with the RAM.
It would seem now that the only thing missing is the kitchen sink.
Tachyon currently uses 2 COGs - 1 for Tachyon engine and one for HS serial output. It would need some trimming and redesigned a bit.
You mean like....hmmmmm...Forth? {well past flaked, thank you!!}
Seems that 99.9% of the time, you'd just want to load some simple code off of SPI compatible flash.
The only reason maybe to do otherwise is the update the SPI code.
In that case, I think you do want the SPI boot to be last in the sequence with serial and SD coming first.
But, it'd be nice for the SD booter to read just the first couple bytes of block 0 for some special code that signifies that we want it to boot....
Cluso's already claimed that part. Assuming he can get the SD code to fit that is.
He mentioned using that as one of his objectives.
In the old days on the early HP-Vectra PCs we indicated boot failures by blinking some LED in different specific pattens. (or beep the speaker)
Would it make sense in a multi-boot setup to indicate what went wrong by blinking a LED (on one of the boot pins) ? - of course with LED OPTIONAL !!
there is nothing more to do for the prop anyhow ...
A while back I used a program on the Apple that did precisely that. One powers up the machine, it fails to boot, enter monitor and from there, either type a kernel in, or take it over serial. Once that is running, the machine has "booted" and lots can be done. (ADT does this to establish a boot disk on an Apple that doesn't have one.)
Been thinking about SD card. Removable media is compelling for a whole lot of reasons. The flash chips go into sockets, meaning we've got what we have now with EEPROM. That does meet the goal, just not in that really easy way SD does.
The big draw on an SD card is the idea that one can just connect to a PC and write to a filesystem to do updates. Are there, or can there be devices designed and built that basically do a similar thing with flash over USB? Make simple media, in other words. Maybe costs are too high for this, but I thought it worth some discussion. After all, there will be a considerable length of time to build solutions for completed P2 chips. Maybe a really big run makes sense to get them down to some reasonable per part cost. Existing adapters can be utilized too, just need to insure the form factors all make sense. Lots of choices there. Worth a thought, IMHO.
A prop based board could interface with the PC too, or use some other device, doesn't matter. What would matter is that flash chip would be presented to the PC as a file system. User does a simple file operation, that gets translated and the data ends up on the chip same as it would for an SD card. That doesn't get all the "remote tech has PC only" use cases, but it does address a whole lot of them.
RE: Code authorization. (I really hate this, but it's necessary in the ugly world we live in)
Suppose there are two cases. Unfused prop. That one is easy. On boot fail, launch it, and it waits for keystrokes to understand comms.
For a fused prop, send same keystrokes, then the damn hash, then launch it? Or just don't... Probably don't is the best case, because that's a back door attempt made easy, though it would take a LOT of tries...
Another random thought: A monitor that can fire off a LMM program would be useful. Doesn't need to be the most efficient kernel, just one that works. Large programs could be uploaded in one stage that way. One could input PASM directly and run it, without firing off another COG too.
Chip: Is there any chance you could post the low-level code for accessing both the SPI bus and the UART? It would be helpful in determining if interesting stuff will fit in the remaining 150 longs. A lot more can be done if there is some low-level code to build on.
Thanks,
David
If board designer want to use different SD pins for speed reason, the custom SD fat16 in spi-flash would take care of that.
But to be able to eliminate FDI chips etc, with an empty or corrupt spi-flash (or a jumper on the board to temp disable its CS line)
So Prop-II will first try to boot for SPI-Flash and then move on to SD
There should be a header in boot code to say: copy code on SD-Card to SPI-Flash.
Great for in field firmware upgrade, one SD card you move from device to device.
Maybe a 4 second delay, so you have time to restore jumper to re-enable Spi-Flash.
Though sounds cumbersome, it will actually protect for accidental rewriting of firmware.
That would be very nice, and wouldn't require anything beyond having bootable SPI flash which checks for an SD card and performs this operation. It could indicate completion by blinking a green LED.
Maybe we could reuse two boot pins to drive a bi-color LED for boot signalling.
It's in the first code block of post #562. It's so simple to do SPI that the bit twiddling just mixes into the loops which you'd need, anyway, to handle the data. So, there's not much to reuse, but not much to recreate, either.
The idea is to have this function in Prop-II rom, as to avoid the chicken or the egg situation.
LED boot signaling would be nice, simple putting a bi-color led to both CS lines should suffice.
I need a crash course on Forth to gain some understanding of it. Sounds neat.
Potatohead, code authentication is a really neat thing. It not only has a security aspect, but serves as a thorough validation mechanism. Image you read a bunch of data out of a flash that you intend to execute. It would be good to know that you've got a real program, or that the flash was even plugged in, before running the code. HMAC does this in a very fail-safe way. In practice, chips will have their keys=0 in development environments, meaning that you just compute the HMAC with a key of 0. A default monitor program would even bypass all this.
Meh, leave this up to the second stage boot loader code, seems likes a waste of ROM to me...