My P123 board seems to work like before after the update.
Took me a moment to figure out Prop_Chk 0 0 0 0...
Had to read instructions to remember that you have to put in a leading space.
Had to set baud to 115200
I'm also seeing that paste in PST doesn't work right.
Does PNut now use this text serial mode to load code?
Seems to load just as fast as before...
Yes, PNut.exe uses this. It's all there is now. It's much easier to code for than what we had before, especially from high-level languages.
So with the new FPGA image we should be able to adapt one of the P1 loaders to load a binary, correct? Is there a spec on the serial loader protocol? Is it similar to the P1 serial protocol? This will allow us to assemble code and load it independent from PNut, and will allow development on non-Windows platforms.
So with the new FPGA image we should be able to adapt one of the P1 loaders to load a binary, correct? Is there a spec on the serial loader protocol? Is it similar to the P1 serial protocol? This will allow us to assemble code and load it independent from PNut, and will allow development on non-Windows platforms.
At the end of the Google doc file, I detailed the whole protocol. It's very simple.
So with the new FPGA image we should be able to adapt one of the P1 loaders to load a binary, correct? Is there a spec on the serial loader protocol? Is it similar to the P1 serial protocol? This will allow us to assemble code and load it independent from PNut, and will allow development on non-Windows platforms.
At the end of the Google doc file, I detailed the whole protocol. It's very simple.
Great! Thanks. It looks like it's time for me to dust off the DE2-115 and try out the latest FPGA image.
I'm a bit confused on the change of the LUT sharing events from SETRDL/SETWRL to the SETSE* selectable-event paradigm. It must be a senior moment, but I'm not getting how a 9-bit LUT location plugs into the new syntax:
The other selectable-event setups make sense to me, and I can see that bits 3..2 of the above set the LUT event mode, but for some reason I'm hung up interpreting the "AA" part
In p2v10a, to set up a write event from the other cog to this cogs' LUT was:
SETLUT #1 ' Allow other cog to write this LUT
SETWRL ##%1_000000000 | LUT_ADDR
I'm a bit confused on the change of the LUT sharing events from SETRDL/SETWRL to the SETSE* selectable-event paradigm. It must be a senior moment, but I'm not getting how a 9-bit LUT location plugs into the new syntax:
The other selectable-event setups make sense to me, and I can see that bits 3..2 of the above set the LUT event mode, but for some reason I'm hung up interpreting the "AA" part
In p2v10a, to set up a write event from the other cog to this cogs' LUT was:
SETLUT #1 ' Allow other cog to write this LUT
SETWRL ##%1_000000000 | LUT_ADDR
What would the equivalent syntax be using SETSE1?
Thanks!
You can select $1FC..$1FF for the LUT read or write address event sensitivity. That's what the AA is about.
I've always wanted to be able to call a subroutine and pass a parameter in the same instruction.
We now have two instructions that do this:
CALLP0 D/#,S/#
CALLP1 D/#,S/#
These instructions write D/# to either register $000 (CALLP0) or $001 (CALLP1) and call to S/#.
D/# is a register or a constant.
S/# is a register or a constant 9-bit relative address. So, if you are using a constant address, it must be within -$100 to +$FF instructions.
These new instructions change this...
MOV 0,#parameter
CALL #subroutine
...to this...
CALLP0 #parameter,#subroutine
I made room for these instructions by replacing SETPAE/SETPAN/SETPBE/SETPBN with SETPEQ/SETPNE, where the C flag now selects the INA/INB port, instead of the instruction.
These instructions are going to get the whole boot ROM back under 2KB. I made the last location of the ROM read first, so that the value can be DECOD'd to a 2^n byte count. This way, the whole 16KB ROM doesn't need to be loaded on reset. Only what is required gets loaded from ROM into hub, saving some milliseconds. In the future, the idea is that we can make the boot ROM up to 16KB, but never load more than is necessary after a reset.
These instructions are going to get the whole boot ROM back under 2KB. I made the last location of the ROM read first, so that the value can be DECOD'd to a 2^n byte count. This way, the whole 16KB ROM doesn't need to be loaded on reset. Only what is required gets loaded from ROM into hub, saving some milliseconds. In the future, the idea is that we can make the boot ROM up to 16KB, but never load more than is necessary after a reset.
Sounds great.
The ROM is 16k Bytes or Bits ?
Does the Boot code load into a COG, or simply stream into HUB and exec from there, meaning there is less of a hard boundary at 2KB.
I'm guessing ROM is Reset-read only, and you cannot read-later ?
These instructions are going to get the whole boot ROM back under 2KB. I made the last location of the ROM read first, so that the value can be DECOD'd to a 2^n byte count. This way, the whole 16KB ROM doesn't need to be loaded on reset. Only what is required gets loaded from ROM into hub, saving some milliseconds. In the future, the idea is that we can make the boot ROM up to 16KB, but never load more than is necessary after a reset.
Sounds great.
The ROM is 16k Bytes or Bits ?
Does the Boot code load into a COG, or simply stream into HUB and exec from there, meaning there is less of a hard boundary at 2KB.
I'm guessing ROM is Reset-read only, and you cannot read-later ?
The ROM is 16K bytes. It gets streamed right into the hub, so that it can be executed. How much gets streamed into the hub is ROM-data-dependent. We will synthesize the whole 16KB ROM, but only load 2KB or 4KB, for now. Maybe someday P63 and P62 could be a USB pair with complete interface in ROM boot code, along with a fancy boot tree.
The ROM can be read later, but it's prone to byte-skips if other cogs are doing the requisite 'CLKSET #0 WC' which reads the next byte of ROM into cog register $000.
The ROM can be read later, but it's prone to byte-skips if other cogs are doing the requisite 'CLKSET #0 WC' which reads the next byte of ROM into cog register $000.
I've been wondering about this. If you have a multi-stage boot, how would you be able to make use of the ROM authentication/encryption code from your first stage code for loading the next stage? I'm assuming the second-stage key would have to be embedded in the first-stage loader?
Nice board, & impressive tooling to match PLCC68.
However, I'd worry a little about the long term supply of PLCC68 - we just dropped PLCC44 sockets, because their price climbed, and availability got more difficult on the brand we had approved.
P2 builds do not yet target Xilinx flows, but the P1V has been rebuilt on Xilinx - you could take those builds, and check/tweak
so they run on configum, & report back in a P1V thread ?
The ROM can be read later, but it's prone to byte-skips if other cogs are doing the requisite 'CLKSET #0 WC' which reads the next byte of ROM into cog register $000.
I've been wondering about this. If you have a multi-stage boot, how would you be able to make use of the ROM authentication/encryption code from your first stage code for loading the next stage? I'm assuming the second-stage key would have to be embedded in the first-stage loader?
The 2nd-stage booter, loaded from flash or serial, is $F8 instructions long, and loads into LUT $100.. $1F7. It is JMP'd to, with the 1st-stage loader still in other parts of the cog, along with the fuses.
Very nice board.
However, IIRC the P1V will require the SLX25 as the SLX16 has only 14K LUTs. The 25K LUT Cyclone IV only fits P2 with 1 cog.
So I am unsure how this helps the P1V or P2 ???
PS You should start a new thread in Propeller 1 as that may be more useful to others. The Propeller 2 is a very specific thread with fewer readers.
Tomorrow, I will post a little program which programs a SPI flash with a blinker program, so you can see the SPI booter function in action.
Nice milestone.
Where is the info on the half-duplex serial handshakes/tokens, and the timings for turnaround.
I'll update my rough One-Pin Serial example, so it is P2-compliant.
- found it in docs.google link in #1..
Tomorrow, I will post a little program which programs a SPI flash with a blinker program, so you can see the SPI booter function in action.
Nice milestone.
Where is the info on the half-duplex serial handshakes/tokens, and the timings for turnaround.
I'll update my rough One-Pin Serial example, so it is P2-compliant.
- found it in docs.google link in #1..
It's in the Google doc, at the end. You just put a "-" between the command word and the first hex value. The booter waits 10ms, in any case, before responding serially.
Comments
Yes, PNut.exe uses this. It's all there is now. It's much easier to code for than what we had before, especially from high-level languages.
Paste is broken in PST. Jeff is going to fix it.
At the end of the Google doc file, I detailed the whole protocol. It's very simple.
%000_00_11AA = odd/even companion cog writes LUT address %1111111AA
The other selectable-event setups make sense to me, and I can see that bits 3..2 of the above set the LUT event mode, but for some reason I'm hung up interpreting the "AA" part
In p2v10a, to set up a write event from the other cog to this cogs' LUT was:
SETLUT #1 ' Allow other cog to write this LUT
SETWRL ##%1_000000000 | LUT_ADDR
What would the equivalent syntax be using SETSE1?
Thanks!
Here's what I found with the bit mask instructions
Version 11b on Nano-bare working Ok now.
Thanks
You can select $1FC..$1FF for the LUT read or write address event sensitivity. That's what the AA is about.
Thanks, Chip!
In the terminal:
C:\Users\Public\p2\P2v11>C:\Users\Public\p2\P2v11\PX.exe C:\Users\Public\p2\P2v11\Prop123_A9_Prop2_v11.rbf /P/4
returns "file /P/4 Not Found"
I assume that this is related to the change in the boot loader?
In the terminal:
C:\Users\Public\p2\P2v11>C:\Users\Public\p2\P2v11\PX.exe C:\Users\Public\p2\P2v11\Prop123_A9_Prop2_v11.rbf /4
Works fine.
But I then flip the PGM/Run switch to RUN and cycle power, wait for the red 0 LED to light, and then PNUT doesn't find the P2.
What am I doing wrong?
sorry.
P2v11!!! love it. Updating my code was really a pleasure.
setedg/waitedg have changed to setse1(2 or 3)/waitse1
the compiler throws the expected error for the old instruction, setedg, but misses waitedg
It thinks WAITEDG is a label now, as it has no operands.
We now have two instructions that do this:
CALLP0 D/#,S/#
CALLP1 D/#,S/#
These instructions write D/# to either register $000 (CALLP0) or $001 (CALLP1) and call to S/#.
D/# is a register or a constant.
S/# is a register or a constant 9-bit relative address. So, if you are using a constant address, it must be within -$100 to +$FF instructions.
These new instructions change this...
MOV 0,#parameter
CALL #subroutine
...to this...
CALLP0 #parameter,#subroutine
I made room for these instructions by replacing SETPAE/SETPAN/SETPBE/SETPBN with SETPEQ/SETPNE, where the C flag now selects the INA/INB port, instead of the instruction.
These instructions are going to get the whole boot ROM back under 2KB. I made the last location of the ROM read first, so that the value can be DECOD'd to a 2^n byte count. This way, the whole 16KB ROM doesn't need to be loaded on reset. Only what is required gets loaded from ROM into hub, saving some milliseconds. In the future, the idea is that we can make the boot ROM up to 16KB, but never load more than is necessary after a reset.
Sounds great.
The ROM is 16k Bytes or Bits ?
Does the Boot code load into a COG, or simply stream into HUB and exec from there, meaning there is less of a hard boundary at 2KB.
I'm guessing ROM is Reset-read only, and you cannot read-later ?
The ROM is 16K bytes. It gets streamed right into the hub, so that it can be executed. How much gets streamed into the hub is ROM-data-dependent. We will synthesize the whole 16KB ROM, but only load 2KB or 4KB, for now. Maybe someday P63 and P62 could be a USB pair with complete interface in ROM boot code, along with a fancy boot tree.
The ROM can be read later, but it's prone to byte-skips if other cogs are doing the requisite 'CLKSET #0 WC' which reads the next byte of ROM into cog register $000.
I've been wondering about this. If you have a multi-stage boot, how would you be able to make use of the ROM authentication/encryption code from your first stage code for loading the next stage? I'm assuming the second-stage key would have to be embedded in the first-stage loader?
https://www.tindie.com/products/KnivD/configum-fpga-module/
Nice board, & impressive tooling to match PLCC68.
However, I'd worry a little about the long term supply of PLCC68 - we just dropped PLCC44 sockets, because their price climbed, and availability got more difficult on the brand we had approved.
P2 builds do not yet target Xilinx flows, but the P1V has been rebuilt on Xilinx - you could take those builds, and check/tweak
so they run on configum, & report back in a P1V thread ?
Some P1V users, may like the PLCC68 form factor.
Another recent Xilinx-PCB, with a similar price to your link is this one (DIP48 form factor, FT2232H included)
http://store.digilentinc.com/cmod-a7-breadboardable-artix-7-fpga-module/
The spec's are very thin on configum, can you do a simple resource table, similar to Digilent's ?
The 2nd-stage booter, loaded from flash or serial, is $F8 instructions long, and loads into LUT $100.. $1F7. It is JMP'd to, with the 1st-stage loader still in other parts of the cog, along with the fuses.
However, IIRC the P1V will require the SLX25 as the SLX16 has only 14K LUTs. The 25K LUT Cyclone IV only fits P2 with 1 cog.
So I am unsure how this helps the P1V or P2 ???
PS You should start a new thread in Propeller 1 as that may be more useful to others. The Propeller 2 is a very specific thread with fewer readers.
Tomorrow, I will post a little program which programs a SPI flash with a blinker program, so you can see the SPI booter function in action.
Where is the info on the half-duplex serial handshakes/tokens, and the timings for turnaround.
I'll update my rough One-Pin Serial example, so it is P2-compliant.
- found it in docs.google link in #1..
It's in the Google doc, at the end. You just put a "-" between the command word and the first hex value. The booter waits 10ms, in any case, before responding serially.