P2 Boot ROM

I've been away for a few weeks. What got decided about what goes in the P2 boot ROM?
«1

Comments

  • 34 Comments sorted by Date Added Votes
  • cgraceycgracey Posts: 8,355
    edited November 28 Vote Up0Vote Down
    David Betz wrote: »
    I've been away for a few weeks. What got decided about what goes in the P2 boot ROM?

    Windows 10. I'm a little nervous about it.

    Actually, Cluso99 and Peter are working on SD card boot and Tachyon implementations.
  • ROTFL!
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • cgracey wrote: »
    David Betz wrote: »
    I've been away for a few weeks. What got decided about what goes in the P2 boot ROM?

    Windows 10. I'm a little nervous about it.

    Actually, Cluso99 and Peter are working on SD card boot and Tachyon implementations.
    Ah, Windows 10. Good choice! Should make self hosting easy! Won't the Windows license significantly increase the cost of the P2 chips though? :-)
  • David Betz wrote: »
    Won't the Windows license significantly increase the cost of the P2 chips though? :-)

    Nah, I'm sure Chip just banked on using the free, ad supported version. ;) You'll just have to wait 10 seconds on bootup and again every hour during use while a random ad spontaneously downloads itself and plays across any video or audio device connected to the P2. Nothing big...right? :lol:
  • cgracey wrote: »
    Actually, Cluso99 and Peter are working on SD card boot and Tachyon implementations.
    And both will be placed in the boot ROM? Or is it a competition with only one winning?

  • cluso99 is working on SD-boot using the MBR as pointer. This will allow to basically boot a image from a SD-card, hopefully loading a complete image of 512k and really hopefully even able to overwrite the ROM area.

    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
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Probably can Run Windows %10 on the P2.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Why doesn't TAQOZ worry about SD boot? If it did, it would allow the boot code in the MBR to be written in TACHYON bytecode, which is much denser than PASM. This would allow for much more to be done with the same 446 bytes.

    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.
  • Why doesn't TAQOZ worry about SD boot? If it did, it would allow the boot code in the MBR to be written in TACHYON bytecode, which is much denser than PASM. This would allow for much more to be done with the same 446 bytes.

    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.
    Sounds like a good idea to me. Also, shouldn't there be a way to force entry into TAQOZ even if there is a bootable device present?
  • David Betz wrote: »
    Why doesn't TAQOZ worry about SD boot? If it did, it would allow the boot code in the MBR to be written in TACHYON bytecode, which is much denser than PASM. This would allow for much more to be done with the same 446 bytes.

    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.
    Sounds like a good idea to me. Also, shouldn't there be a way to force entry into TAQOZ even if there is a bootable device present?

    How? This is a Microcontroller chip, not a PC that usually has a keyboard or other standard device for such an option.

    Fast booting is more important than a lot of boot options for many applications so let any such functions come from a second level boot program.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • ElectrodudeElectrodude Posts: 1,118
    edited November 29 Vote Up0Vote Down
    David Betz wrote: »
    Why doesn't TAQOZ worry about SD boot? If it did, it would allow the boot code in the MBR to be written in TACHYON bytecode, which is much denser than PASM. This would allow for much more to be done with the same 446 bytes.

    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.
    Sounds like a good idea to me. Also, shouldn't there be a way to force entry into TAQOZ even if there is a bootable device present?

    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.
  • Cluso99 wanted to try out his SD boot which is no skin off my nose but it may mean that we might have to combine that part of it somehow with TAQOZ so that it can all fit together in memory otherwise we can leave it well enough alone. The 16kB of ROM is copied to the top of memory and has a write protect/enable CLKSET switch so it is suitable to use as some sort of useful BIOS too I guess.

    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.
    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • David Betz wrote: »
    Why doesn't TAQOZ worry about SD boot? If it did, it would allow the boot code in the MBR to be written in TACHYON bytecode, which is much denser than PASM. This would allow for much more to be done with the same 446 bytes.

    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.
    Sounds like a good idea to me. Also, shouldn't there be a way to force entry into TAQOZ even if there is a bootable device present?

    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.
    What if the boot device is a SPI flash? You can't just remove that from its socket.

  • Cluso99 wanted to try out his SD boot which is no skin off my nose but it may mean that we might have to combine that part of it somehow with TAQOZ so that it can all fit together in memory otherwise we can leave it well enough alone. The 16kB of ROM is copied to the top of memory and has a write protect/enable CLKSET switch so it is suitable to use as some sort of useful BIOS too I guess.

    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.
    I still don't understand the obsession with SD boot. It only saves a cheap SPI flash part but adds great complexity. How often is it likely to be used?
  • David Betz wrote: »
    I still don't understand the obsession with SD boot. It only saves a cheap SPI flash part but adds great complexity. How often is it likely to be used?

    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.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    Tachyon Forth News Blog
    TACHYON DEMONSTRATOR
    Brisbane, Australia
  • Cluso99Cluso99 Posts: 13,022
    edited November 29 Vote Up0Vote Down
    David Betz wrote: »
    Cluso99 wanted to try out his SD boot which is no skin off my nose but it may mean that we might have to combine that part of it somehow with TAQOZ so that it can all fit together in memory otherwise we can leave it well enough alone. The 16kB of ROM is copied to the top of memory and has a write protect/enable CLKSET switch so it is suitable to use as some sort of useful BIOS too I guess.

    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.
    I still don't understand the obsession with SD boot. It only saves a cheap SPI flash part but adds great complexity. How often is it likely to be used?
    To turn the tables around...
    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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • I'm not necessarily against SD boot. I just wonder how often it is likely to be used. I would think most embedded applications would either not have an SD card at all or would not want to require a correctly formatted card just to boot the system. The only downside I can see to allowing SD boot is if it slows down the boot process but I suspect you already have that potential problem solved.
  • SD is super compelling because it is familiar, and I'll second Peter in the more advanced tech included.

    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 crap 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.







    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • msrobotsmsrobots Posts: 1,775
    edited November 29 Vote Up0Vote Down
    I find SD-boot very useful.

    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

    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Sorry for not being up to speed on this...are we saying it will exclusively boot from SD? If so I am going to have a tough time getting my work to use the P2 for any kind of secure / copy-protected application. (It's hard enough with the P1 because of the simple-to-probe EEPROM.)

    thanks,
    Jonathan
    Free time status: see my avatar [8^)
    F32 - fast & concise floating point: OBEX, Thread
    Unrelated to the prop: KISSlicer
  • lonesock wrote: »
    Sorry for not being up to speed on this...are we saying it will exclusively boot from SD? If so I am going to have a tough time getting my work to use the P2 for any kind of secure / copy-protected application. (It's hard enough with the P1 because of the simple-to-probe EEPROM.)

    thanks,
    Jonathan

    No. It is an option.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • In business models, I see a big advantage.
    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 ;-)
  • Cluso99Cluso99 Posts: 13,022
    edited November 30 Vote Up0Vote Down
    Ltech wrote: »
    In business models, I see a big advantage.
    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 :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Ltech wrote: »
    In business models, I see a big advantage.
    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 :)
    I guess with the popularity of the RaspberryPi people have gotten used to booting up embedded systems from SD cards. I think the ESP8266 can even boot from an SD card. Does anyone know of an application that makes use of that?

  • kwinn wrote: »
    lonesock wrote: »
    Sorry for not being up to speed on this...are we saying it will exclusively boot from SD? If so I am going to have a tough time getting my work to use the P2 for any kind of secure / copy-protected application. (It's hard enough with the P1 because of the simple-to-probe EEPROM.)

    thanks,
    Jonathan

    No. It is an option.

    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.
  • David Betz wrote: »
    I guess with the popularity of the RaspberryPi people have gotten used to booting up embedded systems from SD cards.

    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 :lol:). SD could be used to update the flash, provide alternative implementations, etc. And all of this could be done without the user ever having to plug the hardware into a computer, using Propeller IDE, etc.

    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.
  • Seairth wrote: »
    David Betz wrote: »
    I guess with the popularity of the RaspberryPi people have gotten used to booting up embedded systems from SD cards.

    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 :lol:). SD could be used to update the flash, provide alternative implementations, etc. And all of this could be done without the user ever having to plug the hardware into a computer, using Propeller IDE, etc.

    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.
    If Tachyon gets put into the P2 ROM then you don't even need the SD card to be able to immediately play with the P2 or one of the "plates". Just type Forth commands.
  • David Betz wrote: »
    If Tachyon gets put into the P2 ROM then you don't even need the SD card to be able to immediately play with the P2 or one of the "plates". Just type Forth commands.

    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.
  • I think, too, that being able to totally define a system's software by just inserting an SD card is a big thing. No need for pre-programming a flash chip over a serial link, or anything else.
  • Seairth wrote: »

    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...

    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.

    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.
Sign In or Register to comment.