A pointer in ROM stating the current RAM size should be available, but it seems that ROM is closing soon, maybe this discussion is already to late.
I'd like to see at least this, if there's any space left in the ROM.
And I strongly disagree with not writing programs in different languages, fastspin provides this flawlessly, I can use spi2 objects from Basic or C, C objects from Spin and Basic and Basic objects from C and Spin.
For purposes of this discussion all of the fastspin 'dialects" (C, Basic, Spin) should be considered as the same language. The major "high level" languages available now for the P2 are Tachyon Forth, p2gcc, and fastspin. All 3 of these have configuration areas located in various places and with various different things in them. It'd be nice to standardize on some of these things.
I think that since TAQOZ exists already and is in the ROM it makes sense to use it as a model (the other languages, being not burned in ROM, can more easily change to accomodate TAQOZ than vice-versa). If I've read it correctly, TAQOZ's config area is from $0 to $34, followed by some TAQOZ specific vectors. The config area starts with a JMP, and the next 8 bytes are an ID.
fastspin only needs 3 of the configuration longs that TAQOZ has defined: the _CPUHZ at $14 (final clock frequency), _CLKCFG at $18 (clock configuration mode), and baud rate at $1c. Conveniently for me, they are together. Presently fastspin has those at $10, $14, and a variable address (not exported to other programs). I will move them to match TAQOZ unless someone can convince me otherwise.
p2gcc seems to also have 3 configuration longs: clock frequency (TAQOZ $14), user baud (TAQOZ $1c), and bitcycles (not presently stored in TAQOZ, but can be calculated from the previous 2 values). If I'm reading the source correctly these are stored starting at $400. @"Dave Hein" : it looks like it shouldn't be too bad to move those down to start at $14, or am I missing something in the p2gcc init code?
So: I propose that we standardize for now on TAQOZ's use of $10 to $20 as _XIN, _CPUHZ, _CLKCFG, and _BAUD, with $0-$F reserved for a jump instruction and anything else the language runtime wants to use to initialize. _XIN is not likely to change at run time, so I'd be fine with moving that to the ROM area, but the other 3 values are pretty likely to be set by the runtime environment, so I think putting them in RAM makes sense.
I'd also like to propose that we set aside the "top" 1K of memory (just below the ROM shadow copy) as reserved for future mailboxes and inter-COG communication. We can hash out the details later.
TAQOZ doesn't reside in hub $0. It is copied there, if and only if it is invoked. So that area is not preloaded with TAQOZ under normal circumstances.
I concur it is critical at minimum for there to be a standard area to store the 3 longs that ersmith is talking about, and hoping that shared OBEX code would look at these number and adjust accordingly.
They shouldn't be in a protected area because user code will want to change them.
IMHO they should be in protected area. You can unlock (enable) to change and then protect again. When we talk about the ROM, we really mean the top 16KB of a 1MB hub ram model, which can be write protected and unprotected by instructions. This 16KB is also windowed to the top 16KB of whatever is the maximum hub ram in this chip. The serial ROM is auto-loaded into this area on power up/reset, but its not write protected by default.
As far as I read it the protect ROM is a one way step, there is no unprotect ROM, or I am to stupid to find it, same goes for debug interrupt can write write protected rom, I do not find anything about that either, am I missing some documentation?
curious,
On the sixth page of the "Parallax Propeller 2 Documentation" there is a section on Hub Ram. It contains the following:
The last 16KB of RAM can be hidden from its normal address range and made read-only at $FC000..$FFFFF. This is useful for making the last 16KB of RAM persistent, like ROM. It is also how debugging is realized, as the RAM mapped to $FC000..$FFFFF can still be written to from within debug interrupt service routines, permitting the otherwise-protected RAM to be used as debugger-application space and cog-register swap buffers for debug interrupts.
TAQOZ doesn't reside in hub $0. It is copied there, if and only if it is invoked. So that area is not preloaded with TAQOZ under normal circumstances.
Yes, I understand that -- sorry I wasn't clearer.
I'm proposing that fastspin will update the area at $10 if the user calls clkset() or _setbaud() to change the frequency or the serial baud rate.
The default fastspin configuration builds an image that starts at 0, and I'll populate the $10 area in the image with default values. These can be patched by the loader (loadp2 can do this) at load time.
It is also possible to build fastspin images that start elsewhere (using the -H and -E flags). These could be loaded from disk. In that case they will still look at $10 for clock and baud settings (if the user asks for these) but will not overwrite them. So for example it should be possible to build an image that starts above 64K and load it from Tachyon. Or, to invoke TAQOZ from a fastspin program -- in that case TAQOZ will overwrite the config values, but that's OK because the fastspin program will be able to see the updated values and adjust itself accordingly.
p2gcc seems to also have 3 configuration longs: clock frequency (TAQOZ $14), user baud (TAQOZ $1c), and bitcycles (not presently stored in TAQOZ, but can be calculated from the previous 2 values). If I'm reading the source correctly these are stored starting at $400. @"Dave Hein" : it looks like it shouldn't be too bad to move those down to start at $14, or am I missing something in the p2gcc init code?
So: I propose that we standardize for now on TAQOZ's use of $10 to $20 as _XIN, _CPUHZ, _CLKCFG, and _BAUD, with $0-$F reserved for a jump instruction and anything else the language runtime wants to use to initialize. _XIN is not likely to change at run time, so I'd be fine with moving that to the ROM area, but the other 3 values are pretty likely to be set by the runtime environment, so I think putting them in RAM makes sense.
I can move the configuration block for p2gcc from $400 to $14 without too much effort. I included the bitcycles for convenience, but I can compute that in the start up code, so that's not a problem.
Isn't the very top 64B??? used for interrupt code/vectors???
I think we need to understand this!
Then if we reserve the next lower 4 longs for the 4 clock/baud parameters, and a long pointer to the mailbox area. We can load this pointer from ROM with $FFFF_FFFF to indicate its invalid to start with. That will cover us into the future.
So, presuming we need to keep the top 64 bytes free for the interrupt routines...
$000F_FFAC = pointer to hub mailbox/parameters (initially $FFFF_FFFF = unknown)
$000F_FFB0 = clock frequency (initially ~23MHz?)
$000F_FFB4 = xtal frequency, b31:30=%00=OFF, %01=OSC, %10=15pF, %11=30pF (initially $0 = unknown)
$000F_FFB8 = clockmode (initially = ???) - need to define what we want here!!
$000F_FFBC = serial-parameter=(_cpufreq/baud)<<16+7 (initially set to autobaud a0 if initialised, else $0)
$000F_FFC0-$000F_FFFF = interrupt routines - need to check with Chip what is required here???
Question for serial parameter would be what baudrate? What mode(s)/pin(s)? This would just catch the autobaud value and that does not help much when started from flash or SD, belongs into the mailbox area, not into the ROM.
The pointer to the mailbox area would allow to switch between Mailbox-areas, but also means a further indirection, needed to be resolved on every access.
First read pointer to current mailbox-area, then add pointer to mailbox you want, then access mailbox.
Might make sense for position independent code, say start your Program from $0 with mailbox at say $20 or start it from TAQOZ at $1000 with mailbox at $1020.
But putting this basic information at the top of the ROM would keep 0-xxx free, could handle different memory sizes, and could be 'locked in' with ROM write protect.
And yes, thank you guys, I found the part about locking and unlocking the ROM and - hmm - I was wrong, it does goes both ways and it does states that in Debug you can access even a write protected ROM. How did I missed that, it is perfect the way it is now.
Question for serial parameter would be what baudrate? What mode(s)/pin(s)? This would just catch the autobaud value and that does not help much when started from flash or SD, belongs into the mailbox area, not into the ROM.
The serial parameter is just the baud<<16 = 7 (7=8 bits) so it's the value loaded by wxpin into the smartpin. It is only valid if the rom autobaud code runs. Otherwise it needs to be set by user code.
The pointer to the mailbox area would allow to switch between Mailbox-areas, but also means a further indirection, needed to be resolved on every access.
First read pointer to current mailbox-area, then add pointer to mailbox you want, then access mailbox.
Might make sense for position independent code, say start your Program from $0 with mailbox at say $20 or start it from TAQOZ at $1000 with mailbox at $1020.
Indirection only needs to occur once (per program)
But putting this basic information at the top of the ROM would keep 0-xxx free, could handle different memory sizes, and could be 'locked in' with ROM write protect.
And yes, thank you guys, I found the part about locking and unlocking the ROM and - hmm - I was wrong, it does goes both ways and it does states that in Debug you can access even a write protected ROM. How did I missed that, it is perfect the way it is now.
I had a chat to Peter, and he pretty much convinced me this is not important.
Any program that is going to use all this info can be loaded, and when loading can determine where to place this info. It's not critical for the ROM to know.
Do we know how future chip revisions will set the hub ram size? It seems like it would be nice for the ROM to store this so programs can fetch it without having to have a big table chip revisions and ram size, and without having to know how this will vary in the future.
I had a chat to Peter, and he pretty much convinced me this is not important.
Any program that is going to use all this info can be loaded, and when loading can determine where to place this info. It's not critical for the ROM to know.
I'm not sure I agree with this. There are some things that the boot ROM discovers (like the autobaud value, or where we were booted from) that loaded programs might like to know but which they would be unable to determine by themselves, or which it would be awkward for them to determine.
We have config parameters that only apply at boot time. We have config parameters that apply at run time. Then run time parameters that are language dependent.
Yet here we are trying to put them all into one basket without even trying to test out the "standards" that we are proposing.
I said to Cluso99 that at boot time all his SD bootloader should care about after it has determined that there is a file, whether that be dentified as a raw sector or a FAT32 file, is whether it can change to a higher clock rate. But it doesn't need to know anything about the type of crystal or oscillator it is, all it needs is the clock config long that gets loaded with hubset. That way it can switch to a faster clock that has been specified by the user and in this case stored in the MBR maybe along with some other parameters and strings, but the hubset value is all it needs to do it's job faster. I don't expect to take that SD card and expect it to work in some totally different board. That's asking for way too much interoperability.
Maybe the standards committee can come up with a standard for the way standards are determined so we can at least be standard in determining the standard. Of course that makes no sense. Everyone will have a different opinion because they have different needs, real or perceived, and different ways of achieving it. But there are some basics we could agree on, and the boot hubset parameter can be one of them. Why should be have a slow load at RCFAST when we know and have told that board that it can use "this hubset" parameter. No need for a second stage loader. Remember, Cluso99 and I are talking about the ROM, not a 21st century version of Bender's Misoperating System (which btw is 6502 based anyway).
Run time parameters will be language dependent. TAQOZ can have them at $00000 and other languages can choose where they have theirs.
I see the ROM SD BOOTER slightly different to Peter.
I check that SD pull-up is present. This is not a real pull-up, but an internal pull-up provided by the SD card itself. No card = no pull-up.
Then there are a few checks to find where to load and run a block of data from, and in this order...
1. The MBR (sector 0)
2. The VOL (sector gets calculated from PTN0 Table and card must be formatted as FAT32)
3. The FAT32 file “_BOOT_P2.BIX” else “_BOOT_P2.BIY”, case required.
4. Else currently goes back to try serial.
MBR and VOL perform the same checks (I am not at my computer so cannot give offset values)
5. Looks for identifier “Prop” at offset xxx. If found loads 512 byte sector into hub $0 and copies into COG RAM and starts COG (should be cog 0) and JUMPS to COG $020 (sector offset the $80.
6. Looks for identifier “ProP” at offset xxx. If found, uses long at offset xxx for the sector address, and offset xxx for the length (in bytes), rounds this up to a whole 512 bytes and maes this a maximum of 512KB-16KB (so ROM is not overwritten) and uses these values to load sectr(s) into hub $0 and then copies 512 bytes or 496 longs (need to check -should be 496 longs) from hub $0 into COG $000 and then JUMPS to COG $000.
_BOOT_P2.BIX and _BOOT_P2.BIY files find the first file sector and length from the file label (dir entry) and loads and runs as per MBR/VOL in 6. above. Note the files data sectors must be contiguous as this is not checked.
Now, the MBR/VOL or file data can do whatever pasmcode is contained in those sector(s). They can execute a 2-stage loader at some higher clock frequency, or whatever you desire. Choice is yours.
Note exFAT formatted SD cards must use the MBR method as exFAT is patented.
Nowhere here is there any clock frequency, crystal/oscillator frequency or pll parameter setting identified. It is up to the program loaded.
The whole point of having a clock hubset parameter is so that we can load at a much faster rate. At 340MHz TAQOZ can read at a 3.5MB/s rate. That means that the SD bootloader can boot a 64k image in under 20ms rather than seconds. Surely the bootloader is designed to be flexible. Safe and sure when it doesn't know, but able load a boot file from a raw sector when told, and also to load it faster when told.
I checked changes to loadp2 into GitHub so that it now puts the clock frequency, clock mode and baud rate at location $14, $18 and $1C. I also changed p2gcc tools and libraries so that the compiled C code uses those locations.
I checked changes to loadp2 into GitHub so that it now puts the clock frequency, clock mode and baud rate at location $14, $18 and $1C. I also changed p2gcc tools and libraries so that the compiled C code uses those locations.
Awesome! Thanks, Dave. TAQOZ, fastspin, and p2gcc all agree on at least those three things, so that's a start .
Comments
As far as I read it the protect ROM is a one way step, there is no unprotect ROM, or I am to stupid to find it, same goes for debug interrupt can write write protected rom, I do not find anything about that either, am I missing some documentation?
curious,
Mike
Yes, I understand that -- sorry I wasn't clearer.
I'm proposing that fastspin will update the area at $10 if the user calls clkset() or _setbaud() to change the frequency or the serial baud rate.
The default fastspin configuration builds an image that starts at 0, and I'll populate the $10 area in the image with default values. These can be patched by the loader (loadp2 can do this) at load time.
It is also possible to build fastspin images that start elsewhere (using the -H and -E flags). These could be loaded from disk. In that case they will still look at $10 for clock and baud settings (if the user asks for these) but will not overwrite them. So for example it should be possible to build an image that starts above 64K and load it from Tachyon. Or, to invoke TAQOZ from a fastspin program -- in that case TAQOZ will overwrite the config values, but that's OK because the fastspin program will be able to see the updated values and adjust itself accordingly.
I think we need to understand this!
Then if we reserve the next lower 4 longs for the 4 clock/baud parameters, and a long pointer to the mailbox area. We can load this pointer from ROM with $FFFF_FFFF to indicate its invalid to start with. That will cover us into the future.
So, presuming we need to keep the top 64 bytes free for the interrupt routines...
Question for serial parameter would be what baudrate? What mode(s)/pin(s)? This would just catch the autobaud value and that does not help much when started from flash or SD, belongs into the mailbox area, not into the ROM.
The pointer to the mailbox area would allow to switch between Mailbox-areas, but also means a further indirection, needed to be resolved on every access.
First read pointer to current mailbox-area, then add pointer to mailbox you want, then access mailbox.
Might make sense for position independent code, say start your Program from $0 with mailbox at say $20 or start it from TAQOZ at $1000 with mailbox at $1020.
But putting this basic information at the top of the ROM would keep 0-xxx free, could handle different memory sizes, and could be 'locked in' with ROM write protect.
And yes, thank you guys, I found the part about locking and unlocking the ROM and - hmm - I was wrong, it does goes both ways and it does states that in Debug you can access even a write protected ROM. How did I missed that, it is perfect the way it is now.
Enjoy!
Mike
Any program that is going to use all this info can be loaded, and when loading can determine where to place this info. It's not critical for the ROM to know.
I'm not sure I agree with this. There are some things that the boot ROM discovers (like the autobaud value, or where we were booted from) that loaded programs might like to know but which they would be unable to determine by themselves, or which it would be awkward for them to determine.
Yet here we are trying to put them all into one basket without even trying to test out the "standards" that we are proposing.
I said to Cluso99 that at boot time all his SD bootloader should care about after it has determined that there is a file, whether that be dentified as a raw sector or a FAT32 file, is whether it can change to a higher clock rate. But it doesn't need to know anything about the type of crystal or oscillator it is, all it needs is the clock config long that gets loaded with hubset. That way it can switch to a faster clock that has been specified by the user and in this case stored in the MBR maybe along with some other parameters and strings, but the hubset value is all it needs to do it's job faster. I don't expect to take that SD card and expect it to work in some totally different board. That's asking for way too much interoperability.
Maybe the standards committee can come up with a standard for the way standards are determined so we can at least be standard in determining the standard. Of course that makes no sense. Everyone will have a different opinion because they have different needs, real or perceived, and different ways of achieving it. But there are some basics we could agree on, and the boot hubset parameter can be one of them. Why should be have a slow load at RCFAST when we know and have told that board that it can use "this hubset" parameter. No need for a second stage loader. Remember, Cluso99 and I are talking about the ROM, not a 21st century version of Bender's Misoperating System (which btw is 6502 based anyway).
Run time parameters will be language dependent. TAQOZ can have them at $00000 and other languages can choose where they have theirs.
I check that SD pull-up is present. This is not a real pull-up, but an internal pull-up provided by the SD card itself. No card = no pull-up.
Then there are a few checks to find where to load and run a block of data from, and in this order...
1. The MBR (sector 0)
2. The VOL (sector gets calculated from PTN0 Table and card must be formatted as FAT32)
3. The FAT32 file “_BOOT_P2.BIX” else “_BOOT_P2.BIY”, case required.
4. Else currently goes back to try serial.
MBR and VOL perform the same checks (I am not at my computer so cannot give offset values)
5. Looks for identifier “Prop” at offset xxx. If found loads 512 byte sector into hub $0 and copies into COG RAM and starts COG (should be cog 0) and JUMPS to COG $020 (sector offset the $80.
6. Looks for identifier “ProP” at offset xxx. If found, uses long at offset xxx for the sector address, and offset xxx for the length (in bytes), rounds this up to a whole 512 bytes and maes this a maximum of 512KB-16KB (so ROM is not overwritten) and uses these values to load sectr(s) into hub $0 and then copies 512 bytes or 496 longs (need to check -should be 496 longs) from hub $0 into COG $000 and then JUMPS to COG $000.
_BOOT_P2.BIX and _BOOT_P2.BIY files find the first file sector and length from the file label (dir entry) and loads and runs as per MBR/VOL in 6. above. Note the files data sectors must be contiguous as this is not checked.
Now, the MBR/VOL or file data can do whatever pasmcode is contained in those sector(s). They can execute a 2-stage loader at some higher clock frequency, or whatever you desire. Choice is yours.
Note exFAT formatted SD cards must use the MBR method as exFAT is patented.
Nowhere here is there any clock frequency, crystal/oscillator frequency or pll parameter setting identified. It is up to the program loaded.
Awesome! Thanks, Dave. TAQOZ, fastspin, and p2gcc all agree on at least those three things, so that's a start