Anyone written a two stage 64k serial loader for the P1?
Peter Jakacki
Posts: 10,193
I'm thinking of writing a cross-platform app to load more than the 32k limit of the Propeller bootloader. There have been so many times I would love to load a 64k file from the PC but can't. I downloaded Xojo so I'm keen to do more than play with it and figure that this might be a good start, unless of course someone has invented that wheel already?
Btw, I figure if after loading the 1st stage loader that runs off the crystal it can write directly to a buffer while another cog writes 128 byte pages to the EEPROM so that a full 64k load should take less than 3 seconds. This also means that I can distribute fully built Tachyon images too as they use the upper 32k of EEPROM for ROMS and extended dictionary etc.
Btw, I figure if after loading the 1st stage loader that runs off the crystal it can write directly to a buffer while another cog writes 128 byte pages to the EEPROM so that a full 64k load should take less than 3 seconds. This also means that I can distribute fully built Tachyon images too as they use the upper 32k of EEPROM for ROMS and extended dictionary etc.
Comments
Extracting the loader code or adding a command line parameter to load the upper eeprom should also not be too difficult to do. I must add that recent builds have removed the eeprom_cache.dat code that is required for that function but it is easily recoverable.
As an alternative I wrote a Java loader with the same features.
Well that sounds like a solution but I'm wondering if the 1st stage loader can take it's crystal parameters from the target binary so that it can run at the correct clock setting. At 256 bytes/page at 5ms max page write cycle the EEPROM could well be programmed in under 1.5 seconds but THAT pretty much means we need to have a cog dedicated to programming the EEPROM while the data is being received serially. There would be two ways to verify correct EEPROM programming and that would be to verify each page as it is programmed although that would slow things down, or simply match a CRC16 which could in turn be stored in the EEPROM as a power-up integrity check. So the CRC verify would be a great deal faster since it can continue to read a full 64k sequentially at full 400kHz speed or even 1MHz speed since the 24M01s allow this.
The rough part is how you implement to 2nd stage or not 2ndstage boot. I wound up using the last byte of the lower 32K. If it is non-zero, boot 2nd stage. The next thing I am implementing is a "reset" button to zero that byte if powered on with the button pushed.
As for the two stage loader I'm simply referring to a program that is loaded into RAM that then runs off the crystal with a simple receive protocol while maintaining a CRC. The second cog handles all the page writes to the EEPROM. So the first stage loads the code to the EEPROM and can verify the CRC of the EEPROM file and disable the EEPROM from booting if it is bad, as well as signaling a rare load failure serially. I'm cloning scores of Props over RS485 using a simple serial protocol, it doesn't need to be anything complicated for what is essentially direct connection, a "serial data bus".
Yes, I don't mark the EEPROM bootable to the 2nd stage until the last validated block is received. Doing a real CRC (as opposed to multiple checksums like xmodem) for the whole file would work perfectly. When the CRC is valid, mark it as bootable.
I am thinking of doing something very similar for my DMX light controllers. DMX is RS485 at the physical layer.
Update the firmware of all of them at once
Don't know how you'd go with updating firmware over DMX as although it is RS485 it does however operate in unidirectional daisy-chain which is rather limited. My ping-pong protocol is virtual full-duplex over a parallel multidrop bus so I can clone a whole group of devices in a fraction of a second when I am running at 2M baud. I suppose though that if the daisy chain is only at the connector level but then does the protocol allow group selection or would you have to do it one at a time.
Sure, just catching bits n pieces of the forum as I'm in and out but that's fine by me, I can write some Spin/PASM code for the the Prop side to then handle the higher speeds and background EEPROM cog.
I would love to take a look at your ping-pong fullduplex! Is that a part of Tachyon?
@ke4pjw - ping-pong networking or PPNET as I'm calling it now is embedded with the serial console and console output is mirrored and synch'd if need be to PPNET so it really is very handy for a virtual console connection, everything works the same way as a direct local full-duplex connection. If it is a single point-to-point connection then all console output is sent back a character at a time for every character (or null) received. If it is part of a group or global select then it simply listens and does not try to transmit. So at the higher level it can talk to Tachyon but built in are a variety of low-level commands including memory read/write as part of cloning. So if I make this a Spin/PASM object it can be used just as another object but I intend to also implement this in ARM/PIC/8051 assembly real soon to open up the bus to "itty-bitty" slaves.