Chip's likely not to make any changes. He just entertains them. Only the boot loader is up for suggestions right now.
Thanks,
That's correct. Don't suggest any changes for Propeller 2 at this stage. There is no more opportunity for making any further changes to the design at this stage - restarting any aspect of this design whether big or small costs $100K (or $25K, or $200K, I don't know). Small changes take design time from Chip, Beau, and from the synthesis company (very expensive). Unless you're willing pay for your requests at a factor of 10x our costs, this project wants to be finished. <= never said anything like that to our customers before - hopefully I don't get in trouble with you guys!
This whole design has been done in the open, so please honor our request.
No more changes are welcome that relate to the die design. Only boot loader is open for discussion.
Chip's likely not to make any changes. He just entertains them. Only the boot loader is up for suggestions right now.
I think he's gonna at least try a fit of a simple slicer - very low impact on what's already done. It's really a good idea to keep a deterministic hardware thread along side the switcher instructions - which I see as really being used for higher level LMM tasks. This way it frees up most every Cog for both drivers and computation.
Okay, no problem. But in our defence it has been one of those nagging issues ...
No problem. Without making total transparency our goal, forum members need to understand is that a continued delay of any kind puts Parallax (and our customers) in a very bad position. The development process is very expensive, and it's been self-funded through the products you purchase. It's a critical balance to support Chip's desires to produce the most complete chip yet keep the business functioning so that we can support and sell the chip when he's finished. Almost nothing is worth a further delay unless there's a bug in the design.
I think the things that we should be discussing and figuring out are what comes after the built in ROM. There's the rest of the boot up process (which may differ depending on a number of things), the new Spin interpreter (which will be downloaded into the chip along with the Spin code as needed), and other tools needed.
All software stuff that will help keep Ken from having to put on the bad guy hat.
I think the things that we should be discussing and figuring out are what comes after the built in ROM. There's the rest of the boot up process (which may differ depending on a number of things), the new Spin interpreter (which will be downloaded into the chip along with the Spin code as needed), and other tools needed.
All software stuff that will help keep Ken from having to put on the bad guy hat.
Engineers need a bad guy around them sometimes, even including Chip.
That's right. Just a sampling of what lies ahead in no particular order:
Spin interpreter and C kernel, plus the design team for the latter
C/C++ compiler from Roy
GCC port to P2
Eclipse, hopefully
Simple IDE support
Improved solution for OBEX (people has been mobilized)
Datasheet
Qualification and testing
Manual
Propeller Tool support
Application Notes and documentation
Packaging process
Pricing, marketing considerations
Testing hardware and testing firmware, both for manual process at Parallax and high-volume on chip handlers at the packaging company
It's going to take the community this time wherever where they can be plugged into the process.
So back to my thread.... ROM code possible to boot from SD card if no SPI FLASH.
Kye is meant to have the knowledge to know if that's a universal (meaning all SD cards) option.
EDIT: I'm assuming this will be a raw block sequence loading, not a filesystem. So any use of SD cards for booting will be limited to non-standard use. Given this restriction, is it even worth pursuing?
Just to make sure it's clear, when Ken says "C/C++ compiler from Roy" he means the C/C++ version of the Spin/PASM compiler. It exists now for P1, and it's in the works for P2. I'm not about to go competing with the PropGCC (or other C) efforts.
Ken, is the plan going forward to continue with PropTool? I suppose if it's not too much effort, then it's okay, but I would think the focus would be on a cross platform and more open solution like SimpleIDE (or something derived from SimpleIDE) would be more desirable.
Despite some still-unresolved issues, I'd prefer to see the PropTool continue for the time being -- at least until SimpleIDE has a non-project-oriented mode available.
Boot from SD would be nice, and in my opinion would be more practical to have in ROM than a debugger which could be loaded later if necessary. Now I admit, I don't really know anything about the FAT file system, but I'll throw out a thought that might enable the boot loader to be file system indifferent (please correct me if I'm wrong): Place the fixed-size binary file contiguously at the very end of the SD memory space. This would require the use of a special program on the PC-side in order place the file in the proper location, but the P2 would only need to determine the size of the card, and jump towards an offset from the end where it always expects that file to reside.
On another note, congratulations on this milestone! I'm so glad you're talking about the bootloader now. The P2 is so close I can almost feel it, and I can't wait until I actually do! Also, I see no reason to even consider adding any more functionality in silicon at this point. After all, what would be left for the P3?
Phil,
I still don't really understand why you (or anyone really) would want/need a non-project based mode. Is it just because you are used to it in Prop Tool? Also, Prop Tool (after some thinking about it) is likely going to require significant reworking in order to support Prop 2, I think it's wasted effort on a non-open, non-cross platform, tool. Also, at this point only Jeff Martin can work on Prop Tool, and he's got enough on his plate.
markaeric and others, you all keep asking for boot from SD cards in ROM, but you all keep ignoring Chip and Kye when they say it won't fit. It would be very unwise of Parallax to put in some hacked special case version of SD booting, since it will cause them no end of support nightmares. SD cards are a moving target. It's much safer to have SD card reading in a location that can be updated.
I still don't really understand why you (or anyone really) would want/need a non-project based mode.
It's just not the way I work play. I can have several versions of the same top-level program open at once for co-development and comparison. Having to create a separate "project" for each is a major PITA. Besides, each top-level program implicitly defines its own project via the object tree. There's no need to do it twice. That's just C-think extending its tentacles into Spin's inherent simplicity. I never liked project structuring in Atmel's AVR IDE, and I especially don't like it for Prop development.
In any event, I expect that, by the time the P2 is ready, Steve will have made the necessary accommodations to SimpleIDE for non-professional programmers such as myself.
My understanding was that it wouldn't fit due to FAT FS overhead, so I suggested a method that could eliminate that requirement without having to use some proprietary P2-specific file system, which would be an obvious no-go. While your points may be valid, I thought I'd mention an method to enable a previously desired feature before it was simply discarded as impossible. It may not be a perfect solution, but then again, nothing ever is. I don't think I was being out of line or exceptionally stubborn here.
SPI flash is still cheaper and faster than an SD card. I'm sure there are a lot of applications where SPI flash is preferred over SD (high vibration environments, highly embedded devices).
Ken, another thing to add to the list:
* Parallax Crypto Wizard for generating keys, burning keys, encrypting code, signing the loader, and keyring support.
Boot from SD would be nice, and in my opinion would be more practical to have in ROM than a debugger which could be loaded later if necessary.
The SD card has been adopted by the industry as a whole in mass. Everything uses sd, microsd, or minisd. Its not going away, and i have yet to encounter a SD card that wasn't readable using older sd card readers. Everything might not go as fast as the card can but it all still works. Kinda like USB..
USB is a standard today. we even use it to power our cell phones and novelty fans.
Sd has become the standard today for everything. Booting from sd would make sense from the fact that the P2 will be able to handle media. So one would most likely already have a sd card in use.
It would greatly reduce the parts cost, because most p2 configurations will probably take advantage of the large size of SD mixed with HD content spun using P2.
Booting from sd would make sense from the fact that the P2 will be able to handle media. So one would most likely already have a sd card in use.
Sure, when wanting a filesytem, by all means add an SD card reader to the system. But it's not really relevant to a boot process where a filesystem is just a burden.
And the vibration concern is very real too. Give people that much rope and they'll surely needlessly hang themselves with it.
EDIT: Ok, the one biggie that is wanted from SD cards is the easy field exchanging of updates, right? No need for linking in a laptop to do the programming from. That sort of thing. This can still be done with a simple embedded SPI firmware. It even gives possibility of diagnostic indicators/display when the SD card is not inserted - Which will happen.
Drop the Prop Tool.
Surely now that there are all these wonderful open source tools available for the Propeller continuing work on the old Prop Tool is a waste of effort and creates an ongoing suppprt task.
I tend to agree that a project should not be required to build a Spin program. Unlike C a Spin object knows all the sub objects it wants to pull in and the compiler can do so building the whole program in one go. It works like Python, Pascal etc.
So it should be just load and click and there it is running. As this is "simple" IDE there should perhaps not be any visible project menue items or buttons visible to the Spin programmer.
My opinion was that Parallax should maintain the PropTool for the Prop 1 only, which means bugfixes when needed. The P2 should be supported by the OSS tools Parallax has put effort behind. The problem arises when Jeff adds P2 support to the Proptool and OSSPIN is being worked on independently. This is duplicate effort and doesn't declare any authoritative source.
SimpleIDE is the clear contender to replace PropTool for ease of use and integration with both the C and SPIN OSS tools. If Ken decided this was the way to go, SimpleIDE could quickly have the appropriate changes made to make it more friendly.
Also, since a Crypto Wizard will be needed, using the SimpleIDE framework to bolt it into could make development more rapid. Even independent of SimpleIDE, it could have a Qt interface.
It is also important that any and all tools from this point forward are non-interactive compatible (command line friendly). The "real" software development world uses build systems that don't require MickeySoft interfaces.
SPI flash is still cheaper and faster than an SD card. I'm sure there are a lot of applications where SPI flash is preferred over SD (high vibration environments, highly embedded devices).
By no means am I implying that SPI flash support be traded for SD. And some of the boot code could probably be used for both.
Sure, when wanting a filesytem, by all means add an SD card reader to the system. But it's not really relevant to a boot process where a filesystem is just a burden.
That's why I proposed a FS-insensitive SD boot method. Having an SPI flash chip is a waste if you intend to immediately resort to SD for code and data storage. Another benefit would be that you wouldn't have to use a special programming device to upload software.
Yeah, keep the Prop Tool around for P1, after all it does work, but it makes little sense to invest major dev effort on it.
I think SimpleIDE would make an excellent Prop Tool replacement BUT it should come in a version for Spin only devlopment where nothing to do with C or projects shows up in the UI. Or there should be an install time option or button to hide/enable all that stuff.
That's why I proposed a FS-insensitive SD boot method. Having an SPI flash chip is a waste if you intend to immediately resort to SD for code and data storage. Another benefit would be that you wouldn't have to use a special programming device to upload software.
Heh, I inadvertently addressed the programming issue in my prior edit. Which also covered that SPI initial boot is not a waste at all in SD booting process.
That said, yep, it's certainly possible to have a partition friendly non-filesystem boot process so I can't argue on that front.
EDIT: Actually, maybe I can argue on the basis of difficultly of the development tools getting privileged access to perform raw block reads/writes to a formatted and mounted SD card when in the computer. If this were to be a supported method of initial booting then the development tools have to fully support it.
I'm not suggesting that the Prop should boot from SD, especially if it involves try to hide code in secret places and hoping that whatever file system is used on fhe card does not get upset by it or trample on it. However it just so happens that the Raspberry Pi Soc boots from SD only and Pi users have no problem getting raw disk images onto their cards under any PC OS.
I'm gonna guess the RPi can read FAT filesystem when booting. I'd recommend the Prop go down the same path via an embedded SPI boot ROM. We could even have a generic proven image for everyone to start from.
As for implementing a raw boot "file" in a friendly manner along side existing FAT filesystem, it can be done quite well (not hidden) just by giving it's it's own partition and partition type. Not unlike certain rescue partitions. Just requires a little repartitioning is all.
But accessing that allocated partition is where the tools need privilege. It prolly doesn't take a lot but it'll be a little different for each OS.
EDIT: Hehe, just did a search and found that the RPi SD boot image is raw and requires the use of privileged tools to write the image. Not even worried about having partitions at all it seems.
I've been thinking about this single-clock-granular task switching, and I'm pretty confident that I know exactly how to implement it, but there's a problem:
Let's say you've got four tasks running and each task is coded using only single-clock instructions, so that timing is totally determinant. This is great, because now you've got four fast tasks that can behave just like hardware. This isn't realistic, though, because at least one of those tasks will need to do RDxxxx/WRxxxx instructions to communicate with the hub, lest there be no memory communication with other cogs. This will destroy determinancy. Why do this if there can't be practical determinancy?
I calculated that this feature would add about 0.1 sq mm of silicon to the current 9.5 sq mm, which is negligible. I could implement it in one day and it would not affect the critical path of the synthesis work, which is now focused on scripting the post-layout tools. Introducing new Verilog would only mean having the synthesis engineer compile it and push it through his scripts. No engineering work would have to be done by him to accommodate the change. It would mean, to us, paying for a few hours of his time to have him perform this rote effort, which he's already done at least ~60 times since things have been in final form. There were ~60 versions before we even got to that point. Right now, we are on version 124.
So, never minding Ken's concerns, can anyone make an argument for having this feature, despite it's serious flaw? Kye and I talked earlier that lack of timing determinancy would fatally undermine intended performance, since no task could be sure of timing, from instruction to instruction. By doing scheduled task switching in software using WAITCNT, on the other hand, you'd get timing perfection, though at a much coarser granularity.
Can't ---- RDxxxx/WRxxxx instructions --- have any IN USE flag tat task switching use to determine if it is time to pay attention to it in task that use it.
else skip it and go to next task.
BUT that need at --- RDxxxx/WRxxxx instructions -- are completely automated to one cycle for its preparing all necessary data to be placed on HUB bus and then not need COGs time before it is time to read value from HUB.
I've been thinking about this single-clock-granular task switching, and I'm pretty confident that I know exactly how to implement it, but there's a problem:
Let's say you've got four tasks running and each task is coded using only single-clock instructions, so that timing is totally determinant. This is great, because now you've got four fast tasks that can behave just like hardware. This isn't realistic, though, because at least one of those tasks will need to do RDxxxx/WRxxxx instructions to communicate with the hub, lest there be no memory communication with other cogs. This will destroy determinancy. Why do this if there can't be practical determinancy?
I calculated that this feature would add about 0.1 sq mm of silicon to the current 9.5 sq mm, which is negligible. I could implement it in one day and it would not affect the critical path of the synthesis work, which is now focused on scripting the post-layout tools. Introducing new Verilog would only mean having the synthesis engineer compile it and push it through his scripts. No engineering work would have to be done by him to accommodate the change. It would mean, to us, paying for a few hours of his time to have him perform this rote effort, which he's already done at least ~60 times since things have been in final form. There were ~60 versions before we even got to that point. Right now, we are on version 124.
So, never minding Ken's concerns, can anyone make an argument for having this feature, despite it's serious flaw? Kye and I talked earlier that lack of timing determinancy would fatally undermine intended performance, since no task could be sure of timing, from instruction to instruction. By doing scheduled task switching in software using WAITCNT, on the other hand, you'd get timing perfection, though at a much coarser granularity.
Can't ---- RDxxxx/WRxxxx instructions --- have any IN USE flag tat task switching use to determine if it is time to pay attention to it in task that use it.
else skip it and go to next task.
BUT that need at --- RDxxxx/WRxxxx instructions -- are completely automated to one cycle for its preparing all necessary data to be placed on HUB bus and then not need COGs time before it is time to read value from HUB.
We'd have to put flops in to separate the hub timing from the instruction timing. It could easily create a critical path, since those flops would have to be mux'd with the live circuits which are already in the critical-path zone.
Comments
That's correct. Don't suggest any changes for Propeller 2 at this stage. There is no more opportunity for making any further changes to the design at this stage - restarting any aspect of this design whether big or small costs $100K (or $25K, or $200K, I don't know). Small changes take design time from Chip, Beau, and from the synthesis company (very expensive). Unless you're willing pay for your requests at a factor of 10x our costs, this project wants to be finished. <= never said anything like that to our customers before - hopefully I don't get in trouble with you guys!
This whole design has been done in the open, so please honor our request.
No more changes are welcome that relate to the die design. Only boot loader is open for discussion.
Ken Gracey
I think he's gonna at least try a fit of a simple slicer - very low impact on what's already done. It's really a good idea to keep a deterministic hardware thread along side the switcher instructions - which I see as really being used for higher level LMM tasks. This way it frees up most every Cog for both drivers and computation.
Go Chip!
Okay, no problem. But in our defence it has been one of those nagging issues ...
No problem. Without making total transparency our goal, forum members need to understand is that a continued delay of any kind puts Parallax (and our customers) in a very bad position. The development process is very expensive, and it's been self-funded through the products you purchase. It's a critical balance to support Chip's desires to produce the most complete chip yet keep the business functioning so that we can support and sell the chip when he's finished. Almost nothing is worth a further delay unless there's a bug in the design.
All software stuff that will help keep Ken from having to put on the bad guy hat.
Engineers need a bad guy around them sometimes, even including Chip.
That's right. Just a sampling of what lies ahead in no particular order:
- Spin interpreter and C kernel, plus the design team for the latter
- C/C++ compiler from Roy
- GCC port to P2
- Eclipse, hopefully
- Simple IDE support
- Improved solution for OBEX (people has been mobilized)
- Datasheet
- Qualification and testing
- Manual
- Propeller Tool support
- Application Notes and documentation
- Packaging process
- Pricing, marketing considerations
- Testing hardware and testing firmware, both for manual process at Parallax and high-volume on chip handlers at the packaging company
It's going to take the community this time wherever where they can be plugged into the process.Kye is meant to have the knowledge to know if that's a universal (meaning all SD cards) option.
EDIT: I'm assuming this will be a raw block sequence loading, not a filesystem. So any use of SD cards for booting will be limited to non-standard use. Given this restriction, is it even worth pursuing?
Ken, is the plan going forward to continue with PropTool? I suppose if it's not too much effort, then it's okay, but I would think the focus would be on a cross platform and more open solution like SimpleIDE (or something derived from SimpleIDE) would be more desirable.
Since this came up in another thread, can this C/C++ version of the Spin/PASM compiler. support include of Text files ?
-Phil
On another note, congratulations on this milestone! I'm so glad you're talking about the bootloader now. The P2 is so close I can almost feel it, and I can't wait until I actually do! Also, I see no reason to even consider adding any more functionality in silicon at this point. After all, what would be left for the P3?
I still don't really understand why you (or anyone really) would want/need a non-project based mode. Is it just because you are used to it in Prop Tool? Also, Prop Tool (after some thinking about it) is likely going to require significant reworking in order to support Prop 2, I think it's wasted effort on a non-open, non-cross platform, tool. Also, at this point only Jeff Martin can work on Prop Tool, and he's got enough on his plate.
markaeric and others, you all keep asking for boot from SD cards in ROM, but you all keep ignoring Chip and Kye when they say it won't fit. It would be very unwise of Parallax to put in some hacked special case version of SD booting, since it will cause them no end of support nightmares. SD cards are a moving target. It's much safer to have SD card reading in a location that can be updated.
In any event, I expect that, by the time the P2 is ready, Steve will have made the necessary accommodations to SimpleIDE for non-professional programmers such as myself.
-Phil
My understanding was that it wouldn't fit due to FAT FS overhead, so I suggested a method that could eliminate that requirement without having to use some proprietary P2-specific file system, which would be an obvious no-go. While your points may be valid, I thought I'd mention an method to enable a previously desired feature before it was simply discarded as impossible. It may not be a perfect solution, but then again, nothing ever is. I don't think I was being out of line or exceptionally stubborn here.
Ken, another thing to add to the list:
* Parallax Crypto Wizard for generating keys, burning keys, encrypting code, signing the loader, and keyring support.
The SD card has been adopted by the industry as a whole in mass. Everything uses sd, microsd, or minisd. Its not going away, and i have yet to encounter a SD card that wasn't readable using older sd card readers. Everything might not go as fast as the card can but it all still works. Kinda like USB..
USB is a standard today. we even use it to power our cell phones and novelty fans.
Sd has become the standard today for everything. Booting from sd would make sense from the fact that the P2 will be able to handle media. So one would most likely already have a sd card in use.
It would greatly reduce the parts cost, because most p2 configurations will probably take advantage of the large size of SD mixed with HD content spun using P2.
And the vibration concern is very real too. Give people that much rope and they'll surely needlessly hang themselves with it.
EDIT: Ok, the one biggie that is wanted from SD cards is the easy field exchanging of updates, right? No need for linking in a laptop to do the programming from. That sort of thing. This can still be done with a simple embedded SPI firmware. It even gives possibility of diagnostic indicators/display when the SD card is not inserted - Which will happen.
Surely now that there are all these wonderful open source tools available for the Propeller continuing work on the old Prop Tool is a waste of effort and creates an ongoing suppprt task.
I tend to agree that a project should not be required to build a Spin program. Unlike C a Spin object knows all the sub objects it wants to pull in and the compiler can do so building the whole program in one go. It works like Python, Pascal etc.
So it should be just load and click and there it is running. As this is "simple" IDE there should perhaps not be any visible project menue items or buttons visible to the Spin programmer.
"Engineers need a bad guy"
Aw shucks Ken. Some how Chip managed to escape from his dungeon at Castle Parallaxenstein for Saturday afternoon and we were having such fun.
SimpleIDE is the clear contender to replace PropTool for ease of use and integration with both the C and SPIN OSS tools. If Ken decided this was the way to go, SimpleIDE could quickly have the appropriate changes made to make it more friendly.
Also, since a Crypto Wizard will be needed, using the SimpleIDE framework to bolt it into could make development more rapid. Even independent of SimpleIDE, it could have a Qt interface.
It is also important that any and all tools from this point forward are non-interactive compatible (command line friendly). The "real" software development world uses build systems that don't require MickeySoft interfaces.
By no means am I implying that SPI flash support be traded for SD. And some of the boot code could probably be used for both.
That's why I proposed a FS-insensitive SD boot method. Having an SPI flash chip is a waste if you intend to immediately resort to SD for code and data storage. Another benefit would be that you wouldn't have to use a special programming device to upload software.
I think SimpleIDE would make an excellent Prop Tool replacement BUT it should come in a version for Spin only devlopment where nothing to do with C or projects shows up in the UI. Or there should be an install time option or button to hide/enable all that stuff.
Heh, I inadvertently addressed the programming issue in my prior edit. Which also covered that SPI initial boot is not a waste at all in SD booting process.
That said, yep, it's certainly possible to have a partition friendly non-filesystem boot process so I can't argue on that front.
EDIT: Actually, maybe I can argue on the basis of difficultly of the development tools getting privileged access to perform raw block reads/writes to a formatted and mounted SD card when in the computer. If this were to be a supported method of initial booting then the development tools have to fully support it.
As for implementing a raw boot "file" in a friendly manner along side existing FAT filesystem, it can be done quite well (not hidden) just by giving it's it's own partition and partition type. Not unlike certain rescue partitions. Just requires a little repartitioning is all.
But accessing that allocated partition is where the tools need privilege. It prolly doesn't take a lot but it'll be a little different for each OS.
EDIT: Hehe, just did a search and found that the RPi SD boot image is raw and requires the use of privileged tools to write the image. Not even worried about having partitions at all it seems.
Let's say you've got four tasks running and each task is coded using only single-clock instructions, so that timing is totally determinant. This is great, because now you've got four fast tasks that can behave just like hardware. This isn't realistic, though, because at least one of those tasks will need to do RDxxxx/WRxxxx instructions to communicate with the hub, lest there be no memory communication with other cogs. This will destroy determinancy. Why do this if there can't be practical determinancy?
I calculated that this feature would add about 0.1 sq mm of silicon to the current 9.5 sq mm, which is negligible. I could implement it in one day and it would not affect the critical path of the synthesis work, which is now focused on scripting the post-layout tools. Introducing new Verilog would only mean having the synthesis engineer compile it and push it through his scripts. No engineering work would have to be done by him to accommodate the change. It would mean, to us, paying for a few hours of his time to have him perform this rote effort, which he's already done at least ~60 times since things have been in final form. There were ~60 versions before we even got to that point. Right now, we are on version 124.
So, never minding Ken's concerns, can anyone make an argument for having this feature, despite it's serious flaw? Kye and I talked earlier that lack of timing determinancy would fatally undermine intended performance, since no task could be sure of timing, from instruction to instruction. By doing scheduled task switching in software using WAITCNT, on the other hand, you'd get timing perfection, though at a much coarser granularity.
Oh, gee ... I so want to have an answer ...
EDIT: Can't multiple pipes be multiplexed to the ALU? Yeah, I know, that's still bigger again ...
Can't ---- RDxxxx/WRxxxx instructions --- have any IN USE flag tat task switching use to determine if it is time to pay attention to it in task that use it.
else skip it and go to next task.
BUT that need at --- RDxxxx/WRxxxx instructions -- are completely automated to one cycle for its preparing all necessary data to be placed on HUB bus and then not need COGs time before it is time to read value from HUB.
We'd have to put flops in to separate the hub timing from the instruction timing. It could easily create a critical path, since those flops would have to be mux'd with the live circuits which are already in the critical-path zone.