ROM changes for next silicon...
Cluso99
Posts: 18,069
in Propeller 2
BOOTER
This is the boot code that checks the pull-ups and pull-downs and decides whether to run the serial, load/run FLASH, or pass control to the SD BOOTER, or via serial to TAQOZ or the MONITOR.
This is Chip’s code and currently I am unsure if he has any changes planned. I know Peter would like control passed to TAQOZ if all other possibilities fail.
TAQOZ
Peter has been working tirelessly adding all sorts of features. I’ll leave him to comment.
SD BOOTER
I am tweeting the code to improve speed. The result is likely that it may no longer be “callable” from user programs. That also means the Monitor might not be able to call the SD BOOTER. Does this matter?
I am also considering removal of support for the older SD Cards where the address is byte rather than sector. It’s a 9bit shift but saves a few instructions. If FAT16 was supported (need to check) it will be removed. Only FAT32 will be supported, otherwise the MBR will be used for booting as is currently supported.
MONITOR/DEBUGGER
Other than possible removal of calling the SD BOOTER (as mentioned above), I don’t have anything planned. There really isn’t any space available.
Have I missed anything?
This is the boot code that checks the pull-ups and pull-downs and decides whether to run the serial, load/run FLASH, or pass control to the SD BOOTER, or via serial to TAQOZ or the MONITOR.
This is Chip’s code and currently I am unsure if he has any changes planned. I know Peter would like control passed to TAQOZ if all other possibilities fail.
TAQOZ
Peter has been working tirelessly adding all sorts of features. I’ll leave him to comment.
SD BOOTER
I am tweeting the code to improve speed. The result is likely that it may no longer be “callable” from user programs. That also means the Monitor might not be able to call the SD BOOTER. Does this matter?
I am also considering removal of support for the older SD Cards where the address is byte rather than sector. It’s a 9bit shift but saves a few instructions. If FAT16 was supported (need to check) it will be removed. Only FAT32 will be supported, otherwise the MBR will be used for booting as is currently supported.
MONITOR/DEBUGGER
Other than possible removal of calling the SD BOOTER (as mentioned above), I don’t have anything planned. There really isn’t any space available.
Have I missed anything?
Comments
Shame MS patented (invalid IMHO) exFAT. Otherwise I’d support the reading of files but too risky to fall foul of MS
I do really like your callable HUBexec methods, especially the ability to load a file from SD into any HUB location. will that still be possible?
The next thing I do not really like I that your boot file can NOT overwrite the ROM, why you restrict it to 512K - ROM length?
Since the ROM is RAM it would be nice to load a full 512K image, overwriting the ROM in HUB. One could load a full image and then write protect the ROM area (if this is still there, havn't found it yet)
Byte addressing can go, you can not buy SD cards that small anymore.
It would be nice if all the ROM code uses one fixed ROM location for the values of RX and TX,
same goes for the mode selector used, if they would be a fixed long in the ROM one could overwrite the 4 longs and jump into the ROM using different pins then 63/62,
The mode selector is especially important, because to use the ROM as a serial device, and being able to access MONITOR/DEBUGGER/TAQOZ via a serial driver from any program requires to set the RX pin mode running on smart pin 63 to some different pin to free 63 and make it listen to some neighboring pin so that one can be used for output in smart mode.
I have a thread here (https://forums.parallax.com/discussion/169620/hijacking-the-p2-eval-rom#latest) where I patch the ROM to do that, and it works nicely (except lsio in TAQOZ) but requires a lot of patches, it would be nice just to patch 4 longs.
So if it would be possible to spare 4 longs for this purpose that would be great. Actually its just 3 since TAQOZ has already a long for RXpin. Since TAQOZ now gets compressed in the ROM patching will be more complicated, thus asking for 4 fixed location is more important.
Enjoy!
Mike
This is easily overcome by using a simple 2-stage loader.
Yes, the write protect feature is still there. Agreed. This sounds simple, but...
Firstly, we didn't have ROM space.
But most importantly, the fixed locations need to be in cog, not hub. I am already taking 16 longs in cog to support the monitor. SD required another 32 longs in cog.
rxmode & tx mode can be patched in the ROM - 2 places.
baud and the receive buffer location can be externally set.
My experience has been that Twitter is useless for improvement of most things.
LOL
Smile autocorrection. Need to turn it off as it makes more mistakes than it fixes
That does currently work like a charm, except lsio resetting the PINs for TAQOZ, if you avoid lsio you can use TAQOZ as serial device.
But maybe I am wrong and the official way is for my program to include a complete TAQOZ, write TAQOZ code to switch the PINS, write TAQOZ code to start my own Program in COG1, include the whole shebang into every program I want to debug or use TAQOZ on liners and ignore completely that we have a TAQOZ in ROM.
Oh there is another way, I can just use a second P2, connect it serial to the first one and use that from my program as smart IO processor. It just would work on a different chip with different pins and to watch my program while running I just need a lot of wires to connect all pins I want to observe with TAQOZ.
I give up
Mike
Lower HUB RAM is convenient because it's easily accessible via immediate addressing. But if that's a problem let's reserve some space at the top of HUB RAM instead.
I don't think we need to define the contents of this space yet, just make sure that everyone agrees not to stomp on it. At some point in the future we can define how programs will populate it. Having the ROM routines leave it alone would be convenient for preserving data across soft resets, and for knowing that it's safe to call into the ROM without that memory being written to.
(In case it's not obvious I'm posting in this thread because I want the area to be defined across the system, and to know that ROM subroutines will leave this area alone. If we can put some "bread crumbs" in there, like any autobaud rate that the ROM has discovered, and/or an indication of the boot device, so much the better.)
How about:
0..3 = long Frequency
4..7 = long PLL/clock value for HUBSET
That's good, what about reserving fields for RCFAST and RCSLOW values, that could be calibrated & read from FLASH ?
The RCFAST would hold frequency pretty well over temperature, assuming the 1.8V core voltage was consistent. The RCSLOW is all over the place with temperature, though.
Holding calibration values seems like giving false hope.
Maybe for RCSLOW, but storing RCFAST calibrates is widespread industry practice - was you say, "RCFAST would hold frequency pretty well over temperature"
Users do not have to calibrate, but it seems if 'Useful values' space is being reserved, allocating a known-location where RCFAST could be found, would be useful.
A blank flash value could indicate no-valid.
Top of Hub just below the interrupt vectors might be better, and it can be write protected.
Some of the ROM boot code can be overwritten. For example, I overwrite Chips Flash and Serial for the Monitor’s default input buffer.
I think it would be great to be able to call TAQOZ from a user program. However I see a couple of flaws with this.
Firstly, Peter is still adding features. But some of these need to go to fit in ROM.
TAQOZ is still being extended and it won’t stop when the ROM freezes in a few days time.
It will need more ROM to support this.
The whole point here is that TAQOZ (for user program calling) would be better loaded from Flash or SD. So it could be made callable in the future, rather than diverting Peters attention now. And IMHO, it would then be a superior product than having a cut down version loaded from ROM. After all, TAQOZ is there to get the P2 talking and tested without requiring Flash or SD. Once you have Flash or SD, then anything can be loaded.
(or perhaps modify taqoz to recognize when the smartpin receive mode has been changed over to a message box)
Mike
If we put the config block at address 0 I think the first long should be a JMP over the config area (or to wherever the final code is).
Which actually is a good argument for moving the config area to the top of HUB RAM, because typically at boot time stuff gets loaded at the bottom. Perhaps right under the ROM area we could reserve 16 longs for config. WIth two of those longs being set to Frequency and PLL/clock value?
It's hard for me to get a feel for what would be optimal, yet.
What I was thinking is that the initial boot ROM could clear the config area (or fill it with sensible defaults) and subsequent programs could probe it and use the values there if they are valid. If the user changes things (e.g. the clock frequency) they should update the corresponding fields.
Here is the current TAQOZ config area:
00000 orgh 0 00000 000 org 00000 000 fd900058 jmp #initsys '**************** configuration block **************** ' '' 00004 001 452d3250 byte "P2-ES " ' 8 character ID' 0000c 003 03 _OPTIONS byte %0000_0011 ' options SD,FLASH 0000d 003 000000 byte 0,0,0 ' *** CLOCK *** ' 00010 004 01312d00 _XIN long XIN ' input freqency' 00014 005 11e1a300 _CPUHZ long CPUHZ ' final clock ' 00018 006 01000ef8 _CLKCFG long CLKCFG ''$014CB3FC 'CLKCFG ' *** SERIAL/VGA/KEYBOARD *** ' 0001c 007 0001c200 _BAUD long baud_rate 00020 008 03020100 _VGACFG long $03020100 ' VRGBH pins ' 00024 009 00000004 long 4 00028 00a 00000b8c _VGAINIT long @vgainit ' VGA code ' 0002c 00b 0aaaaab0 _VGASET long round(fset) 00030 00c 00000607 _KBCFG long $0607 ' *** RESET VECTORS *** ' 00034 00d 00000420 _RESET long @RESET 00038 00e 00001f8c _IDLE long @IDLE 0003c 00f 00002044 _TERMINAL long @TERMINAL ' COG0 TASK' 00040 010 00000000 _COG1 long 0 ' COG1 TASK ( 0=none ) 00044 011 00000000 _COG2 long 0 00048 012 00000000 _COG3 long 0 0004c 013 00000000 _COG4 long 0 00050 014 00000000 _COG5 long 0 00054 015 00000000 _COG6 long 0 00058 016 00000000 _COG7 long 0The only ones fastspin is likely to touch are the CPU frequency ($14), mode setting ($18), and baud rate ($1c).I'll move the fastspin config area to match TAQOZ in the next fastspin release, if that sounds good to everyone else.
Sound good, but maybe TAQOZ can be packed better, to make the most useful info lowest ?
eg final clock (CPUHZ) is the most useful, then XIN and CLKCFG, and then BAUD etc
there was also this point made :
ie Config info should not compromise speed of possible other code. Config info is read-rarely, so can go pretty much anywhere, it just needs to be a defined location and order.
There's no packing involved, they're all long words. So it really doesn't make any difference, and I suspect people will disagree vehemently about what words are "most useful"
Once you're using a table or vector you're calculating the address, so the speed of access will be the same wherever you are. I think the only benefit of low HUB memory is that it can be accessed via an instruction like "rdlong freq, #$14". Table accesses are going to look more like: I guess sometimes you could save a register if you could write "#tablebase" instead of "tableptr", which would be an argument for moving the config area later.
OTOH there's already a config table in TAQOZ (i.e. in the current ROM) so there's a pretty compelling argument for us to standardize on that and to keep it in future ROMs.
FWIW I still think it should be in top of hub. We can make the ROM load this correctly but time is slipping by quickly.
BTW, I'm not insisting. I've been pushing for a standard config block since I initially saw it as a way to make the bootloader itself load faster without being forced to go through a second stage loader. Having the option to simply read the config and change the clock to a higher rate and preferably one that has already been specified, can only be a good thing.
I can see the merits of having it in ROM but at the same time this complicates addressing since the first 256 locations of low mem (let's call it the page 0) can use 9-bit immediate, or at least 8-bit immediate if that has changed for this mode?
So I will have a look at what may be required.
And yes, we've been trying for years to get some consensus for where to place the mailbox things, but no-one wanted to discuss such things
BTW here is what I reserve in my P1 OS
' OS Hub Definitions... ' ------------------ bytes _HubFree = $7FFC ' 4 ' \ stores total hub available (typ $7800) ' | (hub is allocated to the OS above this value) ' / (eg $7000 means $0000-$6FFF is available) _OS_DateTime = $7FF8 ' 4 'Year20xx Month Date Hours Minutes Seconds ' (00-63) (1-12) (1-31) (00-23) (00-59) (00-59) ' 000000___0000____00000___00000____000000____000000 'To convert to FAT16/32 format, shift >>1 then add 16<<25 ' --> Y(7)M(4)D(5)H(5)M(6)S*2(5bits) Base=1980 ' (FYI seconds in 4yrs = 126,230,400) _OS_Rows = $7FF7 ' 1 ' \ combined <lf> and rows _LF_MASK = $80 ' | b7 : 1= <lf> ON; 0= strip <lf> _ROW_MASK = $7F ' / b0-6: no of rows on screen (0-127) _OS_Columns = $7FF6 ' 1 ' no of cols on screen (0-255) _OS_Cogs = $7FF5 ' 1 ' stay resident cogs: 1= don't stop on reboot _OS_Clkmode = $7FF4 ' 1 ' clkmode: saved fm hub byte $0004 _OS_Clkfreq = $7FF0 ' 4 ' clkfreq(Hz): saved fm hub long $0000 _SDpins = $7FEC ' 4 ' \ sd pins packed 4 bytes ' ' / Byte 3=/CS, 2=DI, 1=CLK, 0=DO _SIOpins = $7FE8 ' 4 ' \ serial pins and mode settings (and cog#) ' ' / Byte 3=cog, 2=mode, 1=SI, 0=SO _SIObaud = $7FE4 ' 4 ' serial baud (speed typ 115,200) _Hardware = $7FE0 ' 4 ' \ hardware: hi-word=company, lo-word=config ' | $0001 = Cluso99 $0001 = RamBlade 1 ' | $0001 = Cluso99 $0002 = TriBlade#2 ' | $0001 = Cluso99 $0003 = RamBlade3 ' | $0001 = Cluso99 $0004 = P8XBlade2 ' / $0001 = Cluso99 $0007 = CpuBlade7 ' ^^^ may be more valuable for something else?? _AuxIn = $7FDC ' 4 ' auxilary input rendezvous _AuxOut = $7FD8 ' 4 ' auxilary output rendezvous _StdIn = $7FD4 ' 4 ' standard input rendezvous _StdOut = $7FD0 ' 4 ' standard output rendezvous _CIDRegister = $7FC0 ' 16 ' \ CID (card identification register) _CSDRegister = $7FB0 ' 16 ' | CSD (card specification data register) _CIDcopyAddr = $7FAC ' 4 ' | address of CIDcopy _SDblockAddr = $7FA8 ' 4 ' | address of Block _SDsectorAddr = $7FA4 ' 4 ' | address of Sector _SDflags = $7FA3 ' 1 ' | (WPflag)<<4 | (NoCard) 0==OK (for later!!! _SDlockcogid = $7FA2 ' 1 ' | (LockID+1)<<4 | (CogID+1) _SDerror = $7FA1 ' 1 ' | error (returned from pasm driver) _SDcommand = $7FA0 ' 1 ' / command (set by app, cleared by pasm driver) _OSreserved = $7F90 ' 16 ' undefined _pBuffer_C = $7F80 ' 16 '| ' \ user buffers... _pBuffer_B = $7F40 ' 64 '| ' | (maybe serial in and serial out buffers?) _pBuffer_A = $7F00 ' 64 '| ' / (used to pass parameters between modules) _pBuffer = $7F00 ' 144 '^ ' / ...joins all 3 buffers A+B+CThat's fine for loading, but at run time you might be starting up code on another COG that needs to get the system configuration. If everything is built together at the same time that's known, but if the modules come from different places (some from disk, some from ROM, some from serial) then it would be nice if they could agree on a few basic things.
One of the use cases we're considering here is being able to run TAQOZ from a PASM program to invoke some basic functions (e.g. reading from disk). This'll save having to re-invent the wheel: some system functions could be written in Forth and then re-used in PASM, C, Spin, etc.