P2 Boot ROM
David Betz
Posts: 14,516
in Propeller 2
I've been away for a few weeks. What got decided about what goes in the P2 boot ROM?
Comments
Windows 10. I'm a little nervous about it.
Actually, Cluso99 and Peter are working on SD card boot and Tachyon implementations.
Nah, I'm sure Chip just banked on using the free, ad supported version.
peter is working on a minimalistic TACHION-kernel currently called TAQOZ, being called if no other boot-medium found. There are rumors that ozprodev's debugger might end up there too.
There was also some talk about common BIOS routines, callable from any used language to allow mixed language programming and common IO but it stalled.
seems to be quite fluid still, what will end up there.
Mike
Supposing the MBR program had access to low-level SD block routines shipped with TAQOZ, I'll bet it would be capable of finding the right partition and loading a file out of it by name.
Putting a script like this in the MBR would also allow support for other filesystems (e.g. ext2/3/4) to be added later, just by writing an MBR script for that filesystem type.
Yeah. Take the SD card out of its socket, turn the device on, and then put the SD card back in after it falls back to TAQOZ because it can't find a boot device.
I've got a very busy week at the moment but I will get back to finalizing some aspects including the SD section as I am trying to make that as efficient and useful as possible. There is still the issue of why it has been crashing on V27z/zz which is why all my testing at present is on V26 but I intend to get to the bottom of the problem of course.
There's no obsession, and no complexity, since it is very easy to add a small microSD and it only requires 4 I/O, just like Flash. In fact these lines are shared except for chip select. I use SD very often and not only for logging purposes. Of course I could include a serial Flash chip but they are very limited in terms of capacity plus SD has another advantage in that it is very standardized with 512 byte sectors and include their own wear leveling etc. Serial Flash is fine for a few megabytes, well suited for firmware but sector sizes are quite large and non-standard and the Prop would have to handle block erase and all that entails with buffering files etc. For $7 locally I can have 16GB of SD memory so that's at least 24MB for a cent!
Just makes practical sense, so why would we spend more dollars to add a chip just for a few lousy MBs of Flash? BTW, I've got nothing against serial Flash, I build it into most designs too, but I like to the option.
Maybe the education market will get by quite nicely without SD but then again, for bots and various applications being able to playback sound files or log large files could be really useful, and all for just a few dollars.
Why are you against an option to boot directly from an SD card without the need for a SPI FLASH chip?
My P8XBlade2 board has to have an eeprom to boot the SD card. I preprogrammed the eeprom to boot the SD card OS, and by default the eeprom is write protected. The eeprom requires 3x 10K pull-ups (a 4x10K pack) and a 0.1uF bypass cap.
A flash chip also requires at least a 0.1uF bypass capacitor, and probably a 1uF bulk capacitor would not be amiss either. So that is 3 additional parts that aren't necessary. Pull-up resistors might also be required. It's not the raw component cost, but the board space, placement costs, testing costs, and inventory costs. The burdened cost is likely 5x the raw component cost. FWIW 20 years ago, the cost to place an smt resistor was 0.1c for the resistor, 15% wastage allowance, and 10c to place the part by machine.
Take a robot using a P2 board. The option may be to use an SD card to store the program. Therefore, not only the SPI Flash could be redundant, but so might be the usual USB connection, including associated parts.
Many will like being able to prep a card, either with another embedded system, or standard PC. Pick your flavor there.
Given the robust multimedia capabilities in P2, holding large or numerous assets and being able to create, update and or manage them with standard, simple tools is a big win IMHO.
I use the Smile out of SD cards now. All sorts of things, camera, PC, 3D printer, phone. Moving data with them is great. I keep a few, and two adapters in my road bag. The micro SD adapter, and a reader for the odd machine lacking one.
My P1 boards with SD saw the most use.
I had really mixed feelings about non partition / filesystem comparability options early on. (Not that the schemes didn't work well. They did. Just my internal product manager balking.)
Now that real filesystem and partition support is on the table, it seems foolish not to do SD.
A robust ROM, with on chip capable tools to follow is also super compelling.
Frankly, these features will contribute greatly to P2 being seen as a mini-computer on chip in addition to being a microcontroller.
And, unlike a Pi or those killer computer modules, we won't have to deliver a complex OS to get a ton of basic functionality people will find useful.
It's possible to do: Loggers, logic trace, scope, signal generate, basic video and audio record, playback, quick app toolkits, calculator, real time non compiled languages, spectrum analyzer, audio synth, and so on....
Given the chip is positioned in this way, a reasonable ecosystem will produce most, if not all of that and more.
Put in the, "Hey it runs cool apps" context, SD makes sense. Seems to me, a no OS, or super lean OS like a DOS, and some command utilities, drops right into the gap between where older gen machines were, and where a Pi starts today.
And it's not about cost. Hard to beat a Pi. It's about utility, and having that be lean, consistent, potent.
For development serial boot will be the primary source, but once out in the field a FLASH upgrade/update needs some form of programmer/PC connection, while sending a SD-card to a customer requires just - hmm - a SD card, easily fitting into a mail envelope.
As for writing a MBR, it is very easy on MAC/UNIX/LINUX using DD and even on Windows one can access a SD as RAW device, providing the SD-content as one large file.
Cluso's should be able to load a complete HUB image (even including the ROM area and overwriting TAQOZ) like the serial and FLASH boot-code already does, if I am not mistaken. And using the MBR basically allows to read any sector of the SD, completely independent of partitions or file-systems used.
Peters TAQOZ seems to include FAT32 handling, it will be able to load a specific file from any location and does not need to use the MBR. I plead here for a simple to understand startup file like a autoexec.bat called something alike cexeotua.taq so that the name is more understandable for FORTH user.
This Textfile could contain a TAQOZ command like "myapp.bin RUNBINARY" or something like that. Now you can startup your P2 from any file on SD with any program you want, written in any language you prefer.
Without even knowing anything about TAQOZ at all. You could be completely unaware of its existence, say in a robotics course with Blockly and C.
But @cluso99 could provide a SD-boot even overwriting the ROM area since running in a COG, while TAQOZ might have problems to load the complete HUB ram and starting it.
And here now comes a question, bothering me.
@Chip extended Pnut to allow loading of the ROM area, but excluded the debug vectors on the end from being loaded. Why?
I think it would be VERY nice to have the ability to load a program with debug enabled?
anyways,
Mike
thanks,
Jonathan
No. It is an option.
Wen the customer need a firmware update, you can send him a file, ask to put it on the root of SD card, and let it boot with it. Updating the eeprom.
A this time P1 you need to put a serial com port, and install drivers depending and connectors.
So if you get an SD slot on you pcb, you can ask a basic tech to make the upgrade ;-)
On my P1 board, code can be changed by simply changing the boot file on the SD card. Eeprom automatically boots from one of two files on the SD. No serial/USB port required. Nor is it necessary to change eeprom code. Just overwrite the SD file
To clarify, secure/copy-protected applications are not an option, regardless of boot options. There had been some work based on fuses, but there turned out to be a hardware design issue that could not be reliably overcome without significant rework. The decision was made to leave this capability out of the P2, at least for the initial release.
As for boot options, they still include both SPI Flash and serial. If SD becomes an option, it will be in addition to the existing options.
It might even be argued that SD card boot was a significant contributor to the success of the RPi. It made the board immediately accessible to non-hardware people.
Applying this to the P2, imagine a simple Arduino-like board (no, not one running Arduino, just the general form factor) that simply exposes the 64 I/O pins via headers. The only other hardware on the board is the voltage regulator(s), maybe onboard USB-serial, and an SD card slot. With that alone, a new user could load an image on an SD card and get the board running just as easily as one does with the RPi. It might be that the "stock image" does nothing more than give you a nice serial terminal (over USB) to interact with and explore the P2 board further. But that would be a great start!
From there, it would obviously be possible to make daughter boards (plates, hats, etc.). However, this is where the design leapfrogs both Arduino and RPi. A pre-programmed SD card could be included with the daughter board to provide immediate capability (e.g. a servo controller board could provide an enhanced serial interface to play with attached servos). Additionally, since all 64 pins are exposed, it would also be possible to put boot flash on the daughter boards, when that makes sense (e.g. erco's upcoming turnkey flamethrowing robot controller board
Of course, what you hope is that people will get more hands on with the hardware than this, but the first step is just getting it into their hands in the first place. And I think that's what the SD boot on the RPi helped do.
True, but I think that's still too limiting. Whatever is in the ROM is fixed in stone. To get anything more or different, you will still need the SD card.
Agree 100% just from watching people I know in real life with an RPi. They never would have even tried if it didn't have "plug and chug" with an SD boot option.