AJMP mov PTRAos ' jump to address on top of the data stack
jmp #DROP
I would expect
AJMP mov PTRA,tos ' jump to address on top of the data stack
jmp #DROP
Yes, I started to update TAQOZ late last night and started out by converting the dictionary to a combined count and attribute byte. That entailed removing all the ,t attributes and somehow that overflowed into the ,tos part as well. I will need to make other changes and test with latest images as well. Do you have a board to test on?
The prompt can be revectored to a user routine and as for the actual prompt string itself it is normally programmable except for the # which signifies the number base so it could be $ or even %. Seeing that TAQOZ is designed to live in ROM we want to be certain from the prompt which shell they are in, whether it be the boot loader, debugger, TAQOZ or even a user app that may even default to #. But nothing is hard and fast and that is why there is a user programmable vector there for the prompt called "prompt". Normally this vector is zero so the default code is executed instead but a simple ' <myprompt> prompt W! will change it.
I note however that even the number base is a little redundant which in traditional Forths specified the default radix for inputting and printing numbers. Tachyon mainly defaults to decimal and by convention hex numbers are entered with the $ prefix and binary numbers by %. It was always too confusing if 100 was 100 or 256 and now you have to enter hex as $100. There doesn't seem to be any real need to handle anything other than that really and as for printing numbers it is mainly decimal numbers that need special formatting and the hex and binary numbers have their own print routines for printing bytes, words, longs etc.
Since there seem to be a timeframe of two weeks to finish the boot rom - how far are you there with integrating bootloader, Clusos99's sd mbr boot and TAQOZ?
Has anybody tested this yet?
It would be a shame if TAQOZ does not make it to the boot rom...
The thing I'm worried about is SD card timing at silicon speeds etc. I might have to have it try at full speed and if it fails even though it detects a card, I could have it slow down on a second attempt. The other thing I'm worried about is testing a version mapped as boot ROM. I'm thinking maybe for testing I need to have a bootloader in SPI Flash (I wish I didn't have worry about complicated boot signatures) that then loaded TAQOZ etc into the boot ROM area and ran it as if it were the boot ROM.Hopefully I will get to test some suitable methods over the next few days.
Do we really need TAQOZ (and SD booting) in two weeks? Can we not start with a simpler bootstrap for the initial test chip, then include the bells and whistles for the final chip? Put another way, is there any part of TAQOZ (or SD boot) that must be tested with a test chip prior to going to production?
Do we really need TAQOZ (and SD booting) in two weeks? Can we not start with a simpler bootstrap for the initial test chip, then include the bells and whistles for the final chip? Put another way, is there any part of TAQOZ (or SD boot) that must be tested with a test chip prior to going to production?
There is a small but finite chance the 'test chip' is the 'final chip'
An important part of the testing then needs to be the boot sequencing, and boot decision tree.
Code later in the decision path, is less critical than code earlier.
Problems may lurk in reboot from self-reset for example. Looking at some of the larger memory parts, the reset recovery times are quite variable.
Re boot-Rom fine print....
I did find this part is stocked
MX25L25635FMI-10G FLASH 256MBIT 104MHZ 16SOP
That has similar timing and commands to the Octaflash part, and the 16SOP part has a separate RESET# pin, allowing hardware reset to be tested. (in SPI and QuadSPI modes)
Reset Recovery time (During instruction decoding) 40 us
Reset Recovery time (for read operation) 35 us
Reset Recovery time (for program operation) 310 us
Reset Recovery time (for SE4KB operation) 12 ms
Reset Recovery time (for BE64K/BE32KB operation) 25 ms
Reset Recovery time (for Chip Erase operation) 100 ms
Reset Recovery time (for WRSR operation) 40 ms
some choices to be made there around reset-exit coverage.
Safe reset-during-Chip-erase needs 100ms, but that's a long time to add to any boot time.
Safe reset during program is 310us, and during read/command is 40us, which are more tolerable boot-time area.
The way that TAQOZ is setup it works fine when loaded at the start of memory and the 16-bit codes are either cog/lut addresses or hub addresses or codes for 9-bit literals and branches etc. But when it is in boot ROM it executes from the top 16k at $FC000 so I'm trying to figure out how to adapt it and test it properly. When we first proposed putting it into boot ROM it was going to be loaded at the start of memory but now the boot ROM is loaded and mapped into the top of RAM so that it can be used alongside user code, rather than in place of it. There are so many many features of the P2 that I have yet to play with and explore that I feel would be of great benefit to the boot ROM. However we need to be practical and try and get it right the first time.
In regards to testing and booting I'm thinking it would be good to have an SD bootloader in SPI in the meantime, and since Cluso99's is standalone I'm wondering if it could be written either in 1k or with a secondary loader? This would help a little in booting TAQOZ from SD for testing at least. I guess I could write a secondary loader to load TAQOZ from SPI as well, so I will look at that too. Chip's SPI loader is only good for test programs.
Now one of the features I'd like to add to TAQOZ is SPLAT or something similar so that we can capture and see the activity on all the I/O in logic analyzer format. The P2 allows for much faster buffering to hub so sample rates should be much higher than P1 so that it may even be possible to sample SD I/O activity although high-speed smartpin modes will need to be slowed down to monitor.
In the meantime I still need to whittle down the code and dictionary to fit into 12 to 14k.
In regards to testing and booting I'm thinking it would be good to have an SD bootloader in SPI in the meantime, and since Cluso99's is standalone I'm wondering if it could be written either in 1k or with a secondary loader? This would help a little in booting TAQOZ from SD for testing at least. I guess I could write a secondary loader to load TAQOZ from SPI as well, so I will look at that too. Chip's SPI loader is only good for test programs.
What is the current basic UART/SPI BOOT size, pin map (Quad/Octal PCB design compatible?), and URL ?
I can find an older thread Prop2 ROM code, but code given there looks well out of date ? (Version 0.1 07/16/2016)
Chip posted an improved SPI preamble here but that's still quite old, at Sept 29 2016.
I've posted a more recent suggestion (30 Mar 2018) to fine tune the SPI preamble waiting details here , based on more recent large FLASH data and their Reset Recovery behaviour.
Discussion and analysis around Quad/Oct modes, is not because BOOT itself will use Quad/Oct, but because BOOT preamble needs to work, in cases of user running in Quad/Oct mode, at the instant any Reset occurs.
tI am just a bystander here, since I am FPGA-less and have to wait for the final boards to buy.
But I am really curious about the cost to change the content of the boot-rom if something goes wrong. Does it require a complete new mask-set or is it 'comparable' cheap to just replace the serial rom content, technically?
For me, serial and flash boot would be OK, but being able to boot from SD-Card is a very useful option.
I still find it funny that TAQOZ will end up in rom and SPIN2 will not, but I somehow like the idea itself as long as @Peter allows a way to run TAQOZ in co-existence with other (Basic,C, Spin, Pasm) code.
That would be the best of all worlds. Microcode Snippets in Forth, called by other HLLs via hubexec and a standard mailbox in rom.
One would not need to program in Forth, just calling words and getting the result back.
I see TAQOZ as a build in scriptable engine, either standalone as scriptable IO-extender for other MCUs/CPUs or used inside of a P2 project in C or Spin the same way.
Sure build in TAQOZ will need a COG (or two?) but if called via rom-fixed mailbox it might be quite easy to integrate with spin, C, Basic and Pasm.
When I boot my P2 serial or from flash I need a way to start TAQOZ in rom, because I would like to integrate it.
But currently TAQOZ starts last, if nothing else is found.
One way would be if TAQOZ could start another Program at address 0 and just uses 'high' memory while hiding itself from the other program ...
But I am really curious about the cost to change the content of the boot-rom if something goes wrong. Does it require a complete new mask-set or is it 'comparable' cheap to just replace the serial rom content, technically?
It is not the sort of change likely to happen on its own.
Revisions could naturally be included when a new spin of the part is dictated by some other, more serious issue.
So long as at least some boot-path works, it is quite cheap to just patch externally after that.
For me, serial and flash boot would be OK, but being able to boot from SD-Card is a very useful option.
I still find it funny that TAQOZ will end up in rom and SPIN2 will not, but I somehow like the idea itself as long as @Peter allows a way to run TAQOZ in co-existence with other (Basic,C, Spin, Pasm) code.
Spin2 is not stable enough, and Parallax probably want to be wary of tagging anything too Language specific in P2. Many languages will be used.
Better to call it A ROM Toolbox, to help bringing up initial board designs.
Makes it clear it is there to assist, and not the only path or choice intended.
I think the idea behind including TAQOZ is to have a language that can be used to interact with the P2 that resides entirely in the P2 chip. Any Spin2 interpreter would just be the runtime for a Spin2 compiler that would have to run on a PC. The idea here is to have a self-hosted language that can be used to interact with the P2 and any hardware attached to it without having to involve tools other than a terminal emulator running on a PC. Also, TAQOZ is interactive. Spin2 is not.
I need to get onto finalizing a few things but here is what "I see" are the most important things it needs to do in terms of functionality first, fancy features follow:
1 - Interactive "high level monitor" tool that works even if nothing else does except the P2 chip itself, maybe not even the crystal.
--- includes smart pin mode support and tools necessary for checking and exercising hardware
Liken this to UEFI which states " UEFI can support remote diagnostics and repair of computers, even with no operating system installed", which is a role that TAQOZ fills but is more like Open Firmware.
2 - SD FAT32 booting for auto/manual loading user binaries or TAQOZ VM source
--- also manipulate and view files etc (includes SPI Flash)
3 - SPLAT Logic Analyser functions
--- useful if it can even capture while user code is running
3 - User runtime routines with standard parameter passing
--- includes SD/FAT32, I2C, SPI, Serial, ADC/DAC etc.
Some features that might be useful are:
* POST style blink or beep for when things are really really bad and not even serial is working.
The first and second item on the list are all that we wanted it to do in the first place. For the moment I've got to redo TAQOZ to run from upper memory since the threaded code addresses are normally in the first 64kB range.
I need to get onto finalizing a few things but here is what "I see" are the most important things it needs to do in terms of functionality first, fancy features follow:
1 - Interactive "high level monitor" tool that works even if nothing else does except the P2 chip itself, maybe not even the crystal.
--- includes smart pin mode support and tools necessary for checking and exercising hardware
Liken this to UEFI which states " UEFI can support remote diagnostics and repair of computers, even with no operating system installed", which is a role that TAQOZ fills but is more like Open Firmware.
I like the phrasing of that, and I see that as an important sales feature of the 'toolbox ROM'.
Volume users will like board bring-up scripts and even assembly houses could be given something ..... no customer install code needed !
Some features that might be useful are:
* POST style blink or beep for when things are really really bad and not even serial is working.
That could be done with a LED on the Tx pin just by pulsing it at human viewable rate.
Is there still a one-pin Boot mode ?
You can send Serial data, even if receive appears to have failed (so have no AutoBAUD) - if you limit to 0xff and 0xfe & many stop bits, those can be very clock tolerant.
What is the expected RCFAST spread ?
Some features that might be useful are:
* POST style blink or beep for when things are really really bad and not even serial is working.
That could be done with a LED on the Tx pin just by pulsing it at human viewable rate.
Yes, good idea since usually it is available off board too but the blinks could actually be serial messages, even if they are sent off blindly. That way an LED will blink and a terminal or even a scope can pick up the error codes and also more verbose messages.
EDIT:
Even on RCFAST the baud rate can be refined if a terminal sends a character if it to calibrate by. I prefer CR since it has two single width lows (start and bit1), a 2-bit high and a 4-bit low and that pattern is easily detected and a calibration and response can probably be had on the first CR.
I assume that in 2. , 3. and the second 3. 'user' is either a ' user binary or TAQOZ VM source' right?
So loading a user binary could either replace the whole RAM and ending TAQOZ or coexist with the already running TAQOZ VM, calling user runtime routines?
We would need some top of ram pointer so when the TAQOZ directory grows down from the top loaded user binaries would know how much memory they have left.
Something anyways useful for different versions of the P2 or FPGAs. End of memory pointer.
Yes, good idea since usually it is available off board too but the blinks could actually be serial messages, even if they are sent off blindly. That way an LED will blink and a terminal or even a scope can pick up the error codes and also more verbose messages.
EDIT:
Even on RCFAST the baud rate can be refined if a terminal sends a character if it to calibrate by. I prefer CR since it has two single width lows (start and bit1), a 2-bit high and a 4-bit low and that pattern is easily detected and a calibration and response can probably be had on the first CR.
There may be no RX appearing, in which case RCFAST runs with whatever spread it delivers - but you can still encode information, with wide Osc spreads, you just can't use all 8 data bits per byte.
Chip did quite a bit of work on Autobaud up to high bit rates, which matters more for download, but testing scripts might get quite long, so supporting multi-megabaud levels would be useful.
1)
- first the booter loads code from HUB rom into the COG ram and lut, initializes xoroshiro and sets up a base64 table in the lut too.
- then checks for pull up on spi_cs (Pin 61). if there is one it attempts to load $100 longs from flash to HUB ram at address 0 and verify if loaded OK.
- as far as I understand this runs in HUBexec mode, jumping into COCexec for checking the pull-ups and doing the SPI transfer.
- from now on everything seems to run in LUTexec mode inside the COG.
2)
- if verified OK loads the user program loaded from Flash to 0-2047 to the HUB into the first $100 longs of the COG.
- if pull up on spi_ck (Pin 60) start it there in COGexec mode at COG address 0.
- this can load and run a 2048 bytes long program, probably a second stage loader from Flash in COGexec at COG address 0, bypassing the serial loader.
3)
- if not started yet (no Flash, not verified or no pull ups at Pin 61 and Pin 60)
- starts a small command interpreter reading serial data with auto baud from rx_pin (Pin 63).
- this serial interpreter has a also a auto-timeout, when no serial command found and program from Flash loaded and verified OK it gets started.
- the serial time out seems to be 60 seconds, I am not sure if this time out is also 60 seconds if verified program from Flash is found. Could be shorter?
- this can load and run a 2048 bytes long program, probably a second stage loader from Flash in COGexec at COG address 0, but can be bypassed by the serial loader.
4)
- the serial loader/interpreter understands 4 commands all commands support a device-id so multiple P2 can use the same serial connection.
- both load commands end with a terminus char either '~' or '?'.
- '~' will restart the COG in HUBexec at HUB address 0.
- '?' will wait for another command. Why is that, for what?
- Prop_Txt ... txt load ... will load BASE64 encoded data into the HUB from address 0 to end of data
- Prop_Hex ... hex load ... will load HEX encoded data into the HUB from address 0 to end of data
- Prop_Clk ... clock setup ... will set clock speed and restart serial
- Prop_Chk ... check device ... will return version string of P2.
5)
- if no commands found and nothing can be started from Flash the Propeller shuts down after 60 seconds.
Comments:
Where in this chain of events should @Cluso99's SD booter be located? Or the TAQOZ start? Like Flash boot there should be a shortcut via pull up to bypass the serial loader to avoid waiting for a serial timeout before SD boot or TAQOZ starts. And like with the Flash boot there should be a way to allow the serial loader to bypass SD and TAQOZ start if needed.
I think the serial loader could be improved by allowing to set a start address in the data block to load. Like the device-id it could be 0 for a normal load, but one could set a start address if needed.
Since when ending with '?' a Prop_Txt and a Prop_Hex execute the next command one could load different areas of the HUB ram per command, say
load this to $400 till end of command and end that command with '?',
load this to $2000 till end of command and end that command with '?' and
load this to $0 till end of command end that command with '~'
and start it there.
One could then load different areas of the HUB with data/code without the need to load a complete 512KB image. But without specifying the start address for blocks this does not work.
And to load something into the rom area with the serial loader one has currently to send a quite large image coded in HEX or BASE64.
a Prop_Run command with HUB start address would be nice also and not to heavy to program. It would allow to load a binary into HUB from 0 to whatever but start at address x not 0.
Maybe some Prop_Taq to start TAQOZ after serial loading? Could be done with Prop_Run and fixed ROM address?
I think the serial loader could be improved by allowing to set a start address in the data block to load. Like the device-id it could be 0 for a normal load, but one could set a start address if needed.
It is common for loaders to have the general form including Address,ByteCount and DataBlock
Intel hex has done that since Adam was a boy...
In serial streaming ones, often they also have a header-tag, so that exact alignment is less important. I think that has been suggested for simpler SD loaders to.
Comments
Yes, I started to update TAQOZ late last night and started out by converting the dictionary to a combined count and attribute byte. That entailed removing all the ,t attributes and somehow that overflowed into the ,tos part as well. I will need to make other changes and test with latest images as well. Do you have a board to test on?
yes - I have a DE0-Nano still in original package (from Ebay one day - could not resist)
but I don't even find the time to do my P1 projects
and setting up the FPGA environment plus learning curve is too much now
so every now and then curiosity takes over I just have a look at your codes ...
Could it be just #?
The prompt can be revectored to a user routine and as for the actual prompt string itself it is normally programmable except for the # which signifies the number base so it could be $ or even %. Seeing that TAQOZ is designed to live in ROM we want to be certain from the prompt which shell they are in, whether it be the boot loader, debugger, TAQOZ or even a user app that may even default to #. But nothing is hard and fast and that is why there is a user programmable vector there for the prompt called "prompt". Normally this vector is zero so the default code is executed instead but a simple ' <myprompt> prompt W! will change it.
I note however that even the number base is a little redundant which in traditional Forths specified the default radix for inputting and printing numbers. Tachyon mainly defaults to decimal and by convention hex numbers are entered with the $ prefix and binary numbers by %. It was always too confusing if 100 was 100 or 256 and now you have to enter hex as $100. There doesn't seem to be any real need to handle anything other than that really and as for printing numbers it is mainly decimal numbers that need special formatting and the hex and binary numbers have their own print routines for printing bytes, words, longs etc.
Has anybody tested this yet?
It would be a shame if TAQOZ does not make it to the boot rom...
just curious,
Mike
The next thing I need to do is get new FPGA images out. We need everyone who can, to try them out. There should be no surprises.
After that, it's a rush for the software.
I don't want you guys to feel pressured to come up with anything if the timeframe is too short.
What I have will suffice for a ROM. It is serial and SPI flash, only.
There is a small but finite chance the 'test chip' is the 'final chip'
An important part of the testing then needs to be the boot sequencing, and boot decision tree.
Code later in the decision path, is less critical than code earlier.
Problems may lurk in reboot from self-reset for example. Looking at some of the larger memory parts, the reset recovery times are quite variable.
I did find this part is stocked
MX25L25635FMI-10G FLASH 256MBIT 104MHZ 16SOP
That has similar timing and commands to the Octaflash part, and the 16SOP part has a separate RESET# pin, allowing hardware reset to be tested. (in SPI and QuadSPI modes)
Note especially
Table 13. Reset Timing-(Power On)
Table 14. Reset Timing-(Other Operation)
some choices to be made there around reset-exit coverage.
Safe reset-during-Chip-erase needs 100ms, but that's a long time to add to any boot time.
Safe reset during program is 310us, and during read/command is 40us, which are more tolerable boot-time area.
Useful docs
http://www.macronix.com/Lists/ApplicationNote/Attachments/1892/AN0200V1_MGRT_MX25L25635E_25735E to MX25L25635F_25735F.pdf
https://media.digikey.com/pdf/Data Sheets/Macronix/MX25L25635F.pdf
Reset-assist devices look like
74LVC123 monostable - ~ 20c
N76E003 MCU ~ 25c
The way that TAQOZ is setup it works fine when loaded at the start of memory and the 16-bit codes are either cog/lut addresses or hub addresses or codes for 9-bit literals and branches etc. But when it is in boot ROM it executes from the top 16k at $FC000 so I'm trying to figure out how to adapt it and test it properly. When we first proposed putting it into boot ROM it was going to be loaded at the start of memory but now the boot ROM is loaded and mapped into the top of RAM so that it can be used alongside user code, rather than in place of it. There are so many many features of the P2 that I have yet to play with and explore that I feel would be of great benefit to the boot ROM. However we need to be practical and try and get it right the first time.
In regards to testing and booting I'm thinking it would be good to have an SD bootloader in SPI in the meantime, and since Cluso99's is standalone I'm wondering if it could be written either in 1k or with a secondary loader? This would help a little in booting TAQOZ from SD for testing at least. I guess I could write a secondary loader to load TAQOZ from SPI as well, so I will look at that too. Chip's SPI loader is only good for test programs.
Now one of the features I'd like to add to TAQOZ is SPLAT or something similar so that we can capture and see the activity on all the I/O in logic analyzer format. The P2 allows for much faster buffering to hub so sample rates should be much higher than P1 so that it may even be possible to sample SD I/O activity although high-speed smartpin modes will need to be slowed down to monitor.
In the meantime I still need to whittle down the code and dictionary to fit into 12 to 14k.
What is the current basic UART/SPI BOOT size, pin map (Quad/Octal PCB design compatible?), and URL ?
I can find an older thread Prop2 ROM code, but code given there looks well out of date ? (Version 0.1 07/16/2016)
Chip posted an improved SPI preamble here but that's still quite old, at Sept 29 2016.
I've posted a more recent suggestion (30 Mar 2018) to fine tune the SPI preamble waiting details here , based on more recent large FLASH data and their Reset Recovery behaviour.
Discussion and analysis around Quad/Oct modes, is not because BOOT itself will use Quad/Oct, but because BOOT preamble needs to work, in cases of user running in Quad/Oct mode, at the instant any Reset occurs.
But I am really curious about the cost to change the content of the boot-rom if something goes wrong. Does it require a complete new mask-set or is it 'comparable' cheap to just replace the serial rom content, technically?
For me, serial and flash boot would be OK, but being able to boot from SD-Card is a very useful option.
I still find it funny that TAQOZ will end up in rom and SPIN2 will not, but I somehow like the idea itself as long as @Peter allows a way to run TAQOZ in co-existence with other (Basic,C, Spin, Pasm) code.
That would be the best of all worlds. Microcode Snippets in Forth, called by other HLLs via hubexec and a standard mailbox in rom.
One would not need to program in Forth, just calling words and getting the result back.
I see TAQOZ as a build in scriptable engine, either standalone as scriptable IO-extender for other MCUs/CPUs or used inside of a P2 project in C or Spin the same way.
Sure build in TAQOZ will need a COG (or two?) but if called via rom-fixed mailbox it might be quite easy to integrate with spin, C, Basic and Pasm.
When I boot my P2 serial or from flash I need a way to start TAQOZ in rom, because I would like to integrate it.
But currently TAQOZ starts last, if nothing else is found.
One way would be if TAQOZ could start another Program at address 0 and just uses 'high' memory while hiding itself from the other program ...
any thoughts?
Mike
It is not the sort of change likely to happen on its own.
Revisions could naturally be included when a new spin of the part is dictated by some other, more serious issue.
So long as at least some boot-path works, it is quite cheap to just patch externally after that.
Spin2 is not stable enough, and Parallax probably want to be wary of tagging anything too Language specific in P2. Many languages will be used.
Better to call it A ROM Toolbox, to help bringing up initial board designs.
Makes it clear it is there to assist, and not the only path or choice intended.
1 - Interactive "high level monitor" tool that works even if nothing else does except the P2 chip itself, maybe not even the crystal.
--- includes smart pin mode support and tools necessary for checking and exercising hardware
Liken this to UEFI which states " UEFI can support remote diagnostics and repair of computers, even with no operating system installed", which is a role that TAQOZ fills but is more like Open Firmware.
2 - SD FAT32 booting for auto/manual loading user binaries or TAQOZ VM source
--- also manipulate and view files etc (includes SPI Flash)
3 - SPLAT Logic Analyser functions
--- useful if it can even capture while user code is running
3 - User runtime routines with standard parameter passing
--- includes SD/FAT32, I2C, SPI, Serial, ADC/DAC etc.
Some features that might be useful are:
* POST style blink or beep for when things are really really bad and not even serial is working.
The first and second item on the list are all that we wanted it to do in the first place. For the moment I've got to redo TAQOZ to run from upper memory since the threaded code addresses are normally in the first 64kB range.
Volume users will like board bring-up scripts and even assembly houses could be given something ..... no customer install code needed !
Does that change of area it runs from make it larger/slower ?
Is there still a one-pin Boot mode ?
You can send Serial data, even if receive appears to have failed (so have no AutoBAUD) - if you limit to 0xff and 0xfe & many stop bits, those can be very clock tolerant.
What is the expected RCFAST spread ?
Yes, good idea since usually it is available off board too but the blinks could actually be serial messages, even if they are sent off blindly. That way an LED will blink and a terminal or even a scope can pick up the error codes and also more verbose messages.
EDIT:
Even on RCFAST the baud rate can be refined if a terminal sends a character if it to calibrate by. I prefer CR since it has two single width lows (start and bit1), a 2-bit high and a 4-bit low and that pattern is easily detected and a calibration and response can probably be had on the first CR.
I assume that in 2. , 3. and the second 3. 'user' is either a ' user binary or TAQOZ VM source' right?
So loading a user binary could either replace the whole RAM and ending TAQOZ or coexist with the already running TAQOZ VM, calling user runtime routines?
We would need some top of ram pointer so when the TAQOZ directory grows down from the top loaded user binaries would know how much memory they have left.
Something anyways useful for different versions of the P2 or FPGAs. End of memory pointer.
Mike
Yup, see my note above.
There may be no RX appearing, in which case RCFAST runs with whatever spread it delivers - but you can still encode information, with wide Osc spreads, you just can't use all 8 data bits per byte.
Chip did quite a bit of work on Autobaud up to high bit rates, which matters more for download, but testing scripts might get quite long, so supporting multi-megabaud levels would be useful.
I have the utterly uncool feeling that
-Chips code is independent
-Clusso99 code is independent
-TAQOZ code is independent
and the rom is due in 10 days.
Mike
thanks @evanh
I shut up and read...
Mike
OK, lets summarize:
1)
- first the booter loads code from HUB rom into the COG ram and lut, initializes xoroshiro and sets up a base64 table in the lut too.
- then checks for pull up on spi_cs (Pin 61). if there is one it attempts to load $100 longs from flash to HUB ram at address 0 and verify if loaded OK.
- as far as I understand this runs in HUBexec mode, jumping into COCexec for checking the pull-ups and doing the SPI transfer.
- from now on everything seems to run in LUTexec mode inside the COG.
2)
- if verified OK loads the user program loaded from Flash to 0-2047 to the HUB into the first $100 longs of the COG.
- if pull up on spi_ck (Pin 60) start it there in COGexec mode at COG address 0.
- this can load and run a 2048 bytes long program, probably a second stage loader from Flash in COGexec at COG address 0, bypassing the serial loader.
3)
- if not started yet (no Flash, not verified or no pull ups at Pin 61 and Pin 60)
- starts a small command interpreter reading serial data with auto baud from rx_pin (Pin 63).
- this serial interpreter has a also a auto-timeout, when no serial command found and program from Flash loaded and verified OK it gets started.
- the serial time out seems to be 60 seconds, I am not sure if this time out is also 60 seconds if verified program from Flash is found. Could be shorter?
- this can load and run a 2048 bytes long program, probably a second stage loader from Flash in COGexec at COG address 0, but can be bypassed by the serial loader.
4)
- the serial loader/interpreter understands 4 commands all commands support a device-id so multiple P2 can use the same serial connection.
- both load commands end with a terminus char either '~' or '?'.
- '~' will restart the COG in HUBexec at HUB address 0.
- '?' will wait for another command. Why is that, for what?
- Prop_Txt ... txt load ... will load BASE64 encoded data into the HUB from address 0 to end of data
- Prop_Hex ... hex load ... will load HEX encoded data into the HUB from address 0 to end of data
- Prop_Clk ... clock setup ... will set clock speed and restart serial
- Prop_Chk ... check device ... will return version string of P2.
5)
- if no commands found and nothing can be started from Flash the Propeller shuts down after 60 seconds.
Comments:
Where in this chain of events should @Cluso99's SD booter be located? Or the TAQOZ start? Like Flash boot there should be a shortcut via pull up to bypass the serial loader to avoid waiting for a serial timeout before SD boot or TAQOZ starts. And like with the Flash boot there should be a way to allow the serial loader to bypass SD and TAQOZ start if needed.
I think the serial loader could be improved by allowing to set a start address in the data block to load. Like the device-id it could be 0 for a normal load, but one could set a start address if needed.
Since when ending with '?' a Prop_Txt and a Prop_Hex execute the next command one could load different areas of the HUB ram per command, say
load this to $400 till end of command and end that command with '?',
load this to $2000 till end of command and end that command with '?' and
load this to $0 till end of command end that command with '~'
and start it there.
One could then load different areas of the HUB with data/code without the need to load a complete 512KB image. But without specifying the start address for blocks this does not work.
And to load something into the rom area with the serial loader one has currently to send a quite large image coded in HEX or BASE64.
a Prop_Run command with HUB start address would be nice also and not to heavy to program. It would allow to load a binary into HUB from 0 to whatever but start at address x not 0.
Maybe some Prop_Taq to start TAQOZ after serial loading? Could be done with Prop_Run and fixed ROM address?
Enjoy!
Mike
Intel hex has done that since Adam was a boy...
In serial streaming ones, often they also have a header-tag, so that exact alignment is less important. I think that has been suggested for simpler SD loaders to.