hmm... Was that a packed/repeating string, no gaps ? - and every _Chk gave a _Ver ? ie you checked counts ?
The test sent 10 x "> Prop_Chk 0 0 0 0 " @ 115200 with a 3mS gap.
10 x "Prop_Ver F" responses were returned.
As the boot loader isn't a full duplex arrangement I wasn't expecting it to respond during the response message transmission.
Sorry I was a bit vague on that detail.
Ah, that explains why it worked - you allowed for > the Tx delay
I still think it's worth lowering that delay to ~1 char time, in order to speed up the total boot times. milliseconds that are easy to trim, are worth trimming.
Chip,
Is there any reason this code might fail if run from hubexec?
Are there any restrictions on the placement of the hexchrs table such as overflow when adding the "x" offset?
Presume limitation is hexchrs table + x[13:5] offset is 9-bit lost overflow. ie must be in 2KB page
Can the AUGS be used with ALTB following?
' runs in hubexec
' x=char, returns c=1 if hex & x=hex-nibble else c=0 & x=char
valid_hex altb x,##hexchrs ' check for hex (hexchrs in hub)
testb 0,x wc ' c=bit[x[4:0]] of hexchrs[x[13:5]]
if_nc ret ' if not hex, return c=0
testbn x,#6 wz ' hex, "0".."9"?
if_nz add x,#9 ' ..make low nibble $A..$F
_ret_ and x,#$F ' extract low nibble, return c=1
hexchrs long %00000000_00000000_00000000_00000000
long %00000011_11111111_00000000_00000000 '"0".."9"
long %00000000_00000000_00000000_01111110 '"A".."F"
long %00000000_00000000_00000000_01111110 '"a".."f"
long %00000000_00000000_00000000_00000000
long %00000000_00000000_00000000_00000000
long %00000000_00000000_00000000_00000000
long %00000000_00000000_00000000_00000000
Chip,
Is there any reason this code might fail if run from hubexec?
Are there any restrictions on the placement of the hexchrs table such as overflow when adding the "x" offset?
Presume limitation is hexchrs table + x[13:5] offset is 9-bit lost overflow. ie must be in 2KB page
Can the AUGS be used with ALTB following?
' runs in hubexec
' x=char, returns c=1 if hex & x=hex-nibble else c=0 & x=char
valid_hex altb x,##hexchrs ' check for hex (hexchrs in hub)
testb 0,x wc ' c=bit[x[4:0]] of hexchrs[x[13:5]]
if_nc ret ' if not hex, return c=0
testbn x,#6 wz ' hex, "0".."9"?
if_nz add x,#9 ' ..make low nibble $A..$F
_ret_ and x,#$F ' extract low nibble, return c=1
hexchrs long %00000000_00000000_00000000_00000000
long %00000011_11111111_00000000_00000000 '"0".."9"
long %00000000_00000000_00000000_01111110 '"A".."F"
long %00000000_00000000_00000000_01111110 '"a".."f"
long %00000000_00000000_00000000_00000000
long %00000000_00000000_00000000_00000000
long %00000000_00000000_00000000_00000000
long %00000000_00000000_00000000_00000000
That won't work. Those instructions you are using are establishing cog register addresses. To read hub memory, you would have to do a RDLONG.
Chip,
If/when you do a new BeMicroCV-A9 FPGA image, can you please swap the SD card pins...
P61 <--> P60 (CSn for SD to be on P60)
P59 <--> P58 (MOSI on P59 = DI on SD card)
Chip,
If/when you do a new BeMicroCV-A9 FPGA image, can you please swap the SD card pins...
P61 <--> P60 (CSn for SD to be on P60)
P59 <--> P58 (MOSI on P59 = DI on SD card)
To get the downloaded boot code to work (ie your code even before we attach ours to the end) we have to do this at the start of the code
DAT
''!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
''!! This coginit at address 00000 is only needed during testing !!
''!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
orgh 0
org 0
_why_ coginit #0,##_HUBROM
''!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
_HUBROM is where we start the compiled code eg $2_C000 instead of $F_C000.
To get the downloaded boot code to work (ie your code even before we attach ours to the end) we have to do this at the start of the code
DAT
''!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
''!! This coginit at address 00000 is only needed during testing !!
''!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
orgh 0
org 0
_why_ coginit #0,##_HUBROM
''!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
_HUBROM is where we start the compiled code eg $2_C000 instead of $F_C000.
Chip, we just need a SPI Flash preloader that works from P0..P2 and loads in 16kB so that we can test power-up and hub reset conditions etc. Cluso said he doesn't mind connecting a Flash chip. I know it is a bit awkward to load this Flash device initially but I was thinking of having an extra P1 as a programmer for it but really all I need to do is have 2 devices and swap between them so that before I load the new preboot FPGA image I can make a copy of the current serial loader in one chip so that after I load the new FPGA which doesn't have serial but does load the independent preboot SPI Flash, that I can select the chip with the stable serial ROM or the other one being tested.
This is the preboot Flash chip pinout so that cs and cs1 can be jumpered to swap the two chips around.
Peter
Will look shortly. We aware having a family day today, so s 1+ hr drive to my sons. May call on the way to discuss. Would you be happy if we did a pull-up test on P4 and then jump to your code, else continue on the boot code I sent you and Chip last night?
The fpga test rom will be very close to the final rom with the one exception that the very first thing it does is test for a pull-up on P2 (of the P2) and if it's there then load 16k directly from boot test flash on P0..P2 and replace the rom code and run it. This allows us to test power-up boot and being able to jump back into the normal serial boot by removing the P2 pull-up from where i can program the test boot flash from TAQOZ.
Chip,
I have a few thoughts why v133a is not working as expected.
The JMP/CALL addresses
How do you enforce a hub destination in pnut?
Are you mapping the Flash chip on the BeMicroCV-A9 board to pins P61-P59? Otherwise I cannot explain where the pull-up is coming from on P61.
I think the PREBOOT code of Peters needs to bit-bang the SPI port. I don't recall if this is so. There is SPI bit-banging code in my SD code. I also thing the Verilog needs to just use P61-58 to the pin headers (without SD and/or Flash). We can then add our own hardware. That way we know precisely what is on those pins.
I will not have time to mod PREBOOT until I get home in around 10 hours. Peter might do it in the meantime?? I agree we just need the simplest cleanest boot possible for testing as there is otherwise too many things in the path.
... Otherwise I cannot explain where the pull-up is coming from on P61.
Is that a pin that has not been pull-up tested before ?
Maybe there is a PCB issue, if not visible to a meter, or scope, maybe there is more cross talk on that pin to some CLK signal, which is enough to confuse things.
The tests do presume the pin floats/stays to a stable logic level during the test window.
If you scope P61 during the pull-up test, what does that look like ?
My v133a was dead too, and the trouble is you don't know what's wrong. Can we just assume that the P62,P63 serial port is always the serial port and drop into TAQOZ if nothing else boots? I can make the ^D in TAQOZ drop back in Cluso's debugger. Anyway, this is what I will code into my test version which will include the startup check for the preboot FLash too.
Yes, and I've figured out how to included the "external ROM" chip into the current pinout. Essentially the extra SPI Flash "ROM" shares the normal boot Flash clock and dq but uses P58 as its CS which needs to have a pullup. The pullup on P58 is then detected as the very first thing the standard mask ROM checks and if enabled, it will load 16kB from the Flash ROM into hub ROM and run that in place of the mask ROM. The mask ROM always gets copied into hub ROM on power-up and reset but this check effectively replaces the hub ROM before any other checks on serial or normal SPI Flash or SD can take place.
The advantage of doing it this way is that not only can we properly test our new boot ROM code at power-up (which at the moment we can't unless we PNut that in serially into the FPGA ROM version), but we can also do this at any time in final silicon, effectively making our own custom boot ROM if we like.
BTW, using an external boot ROM precludes 4-pin SPI Flash, only 3-pin will work. The SFDO data out from a 4-pin SPI Flash was suggested by Cluso as an option.
Peter,
I haven't looked at the circuit for the BeMicroCV-A9's spi flash.
IMHO it would be better to put this on P3..P0 in verilog presuming it's in 4 pin mode on the circuit as I don't think you can make 4 pin work as 3 pin in verilog.
We really don't want any connections to P61..P58 for our testing because Chip is connection all these pins internally in verilog where we cannot get to. SD has pullups on all pins except CLK and CS (the CS is in the SD card though). This means DI & DO pins too!!! This messes with our booting and we really want to get the hardware working with what we know to be externally connected to P61..P58. That way, we can change the pullups ourselves.
I think there are two issues with the 133a code. There is a pullup on CS/P61. I don't know where it is coming from ATM, but its there! So the boot code is presuming that there is a SPI Flash part connected. I also think that possibly the jmp/call is perhaps jumping to cog instead of hub when we give enter <esc>/ctl-B/ctl-D.
Your comment
BTW, using an external boot ROM precludes 4-pin SPI Flash, only 3-pin will work. The SFDO data out from a 4-pin SPI Flash was suggested by Cluso as an option.
Do you mean the current fpga boot code(s) only support 3pin mode? Otherwise, could you explain please?
My v133a was dead too, and the trouble is you don't know what's wrong.
Yes. I had hoped that at least we could get to the monitor or TAQOZ. But that didn't work out
Can we just assume that the P62,P63 serial port is always the serial port and drop into TAQOZ if nothing else boots?
Yes, I think we should presume that P62-63 is always the serial port. Since Chip doesn't want an option to disable serial booting, it makes even more sense.
However, how do you want Chip's serial to pass control to TAQOZ automatically? By entering "> " followed by <esc> or other ctl-T ???
I can make the ^D in TAQOZ drop back in Cluso's debugger. Anyway, this is what I will code into my test version which will include the startup check for the preboot FLash too.
Sure. But please remove the ascii terminal control codes from TAQOZ if you haven't done this already. I think both of us should allow switching between the two.
And yes, I think we should just use the autobaud serial found by Chip's serial too.
@Cluso99, I intend to test this properly and I have external SD for this purpose so I don't want the CVA9's microSD mapped at all, just raw. I have external SPI Flash connected to P59..P61 and also an the boot ROM SPI Flash with cs on P58. We really need to test final configuration as close as possible. I'm modifying Chip's code now to have the SPI CS as a variable so I can use the same code.
All we want for SPI Flash are 3 pins but you mentioned including a test for 4-pin although I really think that is unnecessary as there is no advantage for 4-pin connection.
Once I have made these changes it means we could have an FPGA image for the CVA9 that has all our boot code in it but still allows us to override that boot code with an extra SPI Flash. We both would have to have an external SD for this final test.
BTW, using an external boot ROM precludes 4-pin SPI Flash, only 3-pin will work. The SFDO data out from a 4-pin SPI Flash was suggested by Cluso as an option.
Do you mean fitting a second flash chip (external BOOT ROM), then forces users to a 3-pin connection , but a not-fitted-external-ROM allows a 4 pin connection ?
Does all of this still allow users to cleanly run QUAD SPI connected parts, and OctalSPI connected parts ?
BTW, using an external boot ROM precludes 4-pin SPI Flash, only 3-pin will work. The SFDO data out from a 4-pin SPI Flash was suggested by Cluso as an option.
Do you mean fitting a second flash chip (external BOOT ROM), then forces users to a 3-pin connection , but a not-fitted-external-ROM allows a 4 pin connection ?
Does all of this still allow users to cleanly run QUAD SPI connected parts, and OctalSPI connected parts ?
Chip has already stated his position in this matter. If I wanted to run OctalSPI then I can, but that doesn't mean that the boot Flash and the OctalSPI application Flash need be the same chip. There is no advantage trying to use Octal/Quad for booting but it certainly does compromise the minimum boot pins required for something is very unlikely to be used, but if it is, then as mentioned, use separate pins.
The option of being able to replace the hub boot with an external SPI Flash also means that if we need any further tweaking on the PE versions of the silicon, that we can then do so.
@Cluso99, I intend to test this properly and I have external SD for this purpose so I don't want the CVA9's microSD mapped at all, just raw. I have external SPI Flash connected to P59..P61 and also an the boot ROM SPI Flash with cs on P58. We really need to test final configuration as close as possible. I'm modifying Chip's code now to have the SPI CS as a variable so I can use the same code.
All we want for SPI Flash are 3 pins but you mentioned including a test for 4-pin although I really think that is unnecessary as there is no advantage for 4-pin connection.
Once I have made these changes it means we could have an FPGA image for the CVA9 that has all our boot code in it but still allows us to override that boot code with an extra SPI Flash. We both would have to have an external SD for this final test.
Totally agree we don't want the SD configured to the P58-61 pins as the pullups are possibly causing problems. Are you also saying you don't want the on-board SPI Flash mapped to P58-61 either? If so, then I totally agree. We need to know there is nothing being mapped to these pins - we will connect our own parts to these pins.
If the final ROM does not support 4pin SPI Flash, then for anyone wanting quad/octal SPI Flash, they will need to provide two flash chips. This is because to implement 3pin SPI Flash, a resistor between DI and DO is required. It doesn't matter to me, but there are others that seem to be demanding quad spi be available.
I am also concerned that sometime in the future, 3pin SPI may not be supported as chips get faster. We also know that there is latency in the P2's I/O pins. I am not sure how this latency might impact switching between input and output on the same pin.
Therefore, IMHO, 4pin SPI Flash needs to be supported, and 3pin should be optional. But I showed how we can have both, and automatically decide.
Comments
Ah, that explains why it worked - you allowed for > the Tx delay
I still think it's worth lowering that delay to ~1 char time, in order to speed up the total boot times. milliseconds that are easy to trim, are worth trimming.
Is there any reason this code might fail if run from hubexec?
Are there any restrictions on the placement of the hexchrs table such as overflow when adding the "x" offset?
Presume limitation is hexchrs table + x[13:5] offset is 9-bit lost overflow. ie must be in 2KB page
Can the AUGS be used with ALTB following?
' runs in hubexec ' x=char, returns c=1 if hex & x=hex-nibble else c=0 & x=char valid_hex altb x,##hexchrs ' check for hex (hexchrs in hub) testb 0,x wc ' c=bit[x[4:0]] of hexchrs[x[13:5]] if_nc ret ' if not hex, return c=0 testbn x,#6 wz ' hex, "0".."9"? if_nz add x,#9 ' ..make low nibble $A..$F _ret_ and x,#$F ' extract low nibble, return c=1 hexchrs long %00000000_00000000_00000000_00000000 long %00000011_11111111_00000000_00000000 '"0".."9" long %00000000_00000000_00000000_01111110 '"A".."F" long %00000000_00000000_00000000_01111110 '"a".."f" long %00000000_00000000_00000000_00000000 long %00000000_00000000_00000000_00000000 long %00000000_00000000_00000000_00000000 long %00000000_00000000_00000000_00000000]https://forums.parallax.com/discussion/comment/1436552/#Comment_1436552
That won't work. Those instructions you are using are establishing cog register addresses. To read hub memory, you would have to do a RDLONG.
If/when you do a new BeMicroCV-A9 FPGA image, can you please swap the SD card pins...
P61 <--> P60 (CSn for SD to be on P60)
P59 <--> P58 (MOSI on P59 = DI on SD card)
I will do that.
When might you have time to do a new BeMicroCV-A9 code with a new ROM image?
Peter is asking for a test version too. Perhaps we can combine them both with a pullup on another pin to select the difference.
I can start it this morning.
I can set a pull-up on P60, but it cannot be controllable. It would always be on. Is that okay?
Thanks, but no we don't want any internal pullups/pulldowns on P58-61. The board already has unnwanted pullups.
How long does it take to run? And can you do other work while its running?
If it doesn't take much of your actual time I'll knock up the code now (without Peters request but it has TAQOZ as of a week ago)
I presume the reason we have to do a coginit #0,#_HUBROM at Cog $0 is because the loader is doing something?
I have SD booting and the monitor and Peters TAQOZ in the code. Just changing the few bits now.
Could you elaborate a little more? I don't really understand what you're asking.
_HUBROM is where we start the compiled code eg $2_C000 instead of $F_C000.
BTW I have emailed you.
Okay. I'll be on this in about a half hour.
I am off to bed shortly. Post any questions here and I'll check overnight.
This is the preboot Flash chip pinout so that cs and cs1 can be jumpered to swap the two chips around.
This will be a very good test of power-up booting since the preloader does nothing else and couldn't care less about serial or jumpers itself.
I've attached a file of a prebooter that is based on your code and may work.
Will look shortly. We aware having a family day today, so s 1+ hr drive to my sons. May call on the way to discuss. Would you be happy if we did a pull-up test on P4 and then jump to your code, else continue on the boot code I sent you and Chip last night?
I have a few thoughts why v133a is not working as expected.
The JMP/CALL addresses
How do you enforce a hub destination in pnut?
Are you mapping the Flash chip on the BeMicroCV-A9 board to pins P61-P59? Otherwise I cannot explain where the pull-up is coming from on P61.
I think the PREBOOT code of Peters needs to bit-bang the SPI port. I don't recall if this is so. There is SPI bit-banging code in my SD code. I also thing the Verilog needs to just use P61-58 to the pin headers (without SD and/or Flash). We can then add our own hardware. That way we know precisely what is on those pins.
I will not have time to mod PREBOOT until I get home in around 10 hours. Peter might do it in the meantime?? I agree we just need the simplest cleanest boot possible for testing as there is otherwise too many things in the path.
Maybe there is a PCB issue, if not visible to a meter, or scope, maybe there is more cross talk on that pin to some CLK signal, which is enough to confuse things.
The tests do presume the pin floats/stays to a stable logic level during the test window.
If you scope P61 during the pull-up test, what does that look like ?
That should be done anyways. If all fails run TAQOZ.
Enjoy
Mike
The advantage of doing it this way is that not only can we properly test our new boot ROM code at power-up (which at the moment we can't unless we PNut that in serially into the FPGA ROM version), but we can also do this at any time in final silicon, effectively making our own custom boot ROM if we like.
BTW, using an external boot ROM precludes 4-pin SPI Flash, only 3-pin will work. The SFDO data out from a 4-pin SPI Flash was suggested by Cluso as an option.
I haven't looked at the circuit for the BeMicroCV-A9's spi flash.
IMHO it would be better to put this on P3..P0 in verilog presuming it's in 4 pin mode on the circuit as I don't think you can make 4 pin work as 3 pin in verilog.
We really don't want any connections to P61..P58 for our testing because Chip is connection all these pins internally in verilog where we cannot get to. SD has pullups on all pins except CLK and CS (the CS is in the SD card though). This means DI & DO pins too!!! This messes with our booting and we really want to get the hardware working with what we know to be externally connected to P61..P58. That way, we can change the pullups ourselves.
I think there are two issues with the 133a code. There is a pullup on CS/P61. I don't know where it is coming from ATM, but its there! So the boot code is presuming that there is a SPI Flash part connected. I also think that possibly the jmp/call is perhaps jumping to cog instead of hub when we give enter <esc>/ctl-B/ctl-D.
Your comment
BTW, using an external boot ROM precludes 4-pin SPI Flash, only 3-pin will work. The SFDO data out from a 4-pin SPI Flash was suggested by Cluso as an option.
Do you mean the current fpga boot code(s) only support 3pin mode? Otherwise, could you explain please?
However, how do you want Chip's serial to pass control to TAQOZ automatically? By entering "> " followed by <esc> or other ctl-T ??? Sure. But please remove the ascii terminal control codes from TAQOZ if you haven't done this already. I think both of us should allow switching between the two.
And yes, I think we should just use the autobaud serial found by Chip's serial too.
I will call you tonight and I'm home tomorrow.
All we want for SPI Flash are 3 pins but you mentioned including a test for 4-pin although I really think that is unnecessary as there is no advantage for 4-pin connection.
Once I have made these changes it means we could have an FPGA image for the CVA9 that has all our boot code in it but still allows us to override that boot code with an extra SPI Flash. We both would have to have an external SD for this final test.
Does all of this still allow users to cleanly run QUAD SPI connected parts, and OctalSPI connected parts ?
Chip has already stated his position in this matter. If I wanted to run OctalSPI then I can, but that doesn't mean that the boot Flash and the OctalSPI application Flash need be the same chip. There is no advantage trying to use Octal/Quad for booting but it certainly does compromise the minimum boot pins required for something is very unlikely to be used, but if it is, then as mentioned, use separate pins.
The option of being able to replace the hub boot with an external SPI Flash also means that if we need any further tweaking on the PE versions of the silicon, that we can then do so.
If the final ROM does not support 4pin SPI Flash, then for anyone wanting quad/octal SPI Flash, they will need to provide two flash chips. This is because to implement 3pin SPI Flash, a resistor between DI and DO is required. It doesn't matter to me, but there are others that seem to be demanding quad spi be available.
I am also concerned that sometime in the future, 3pin SPI may not be supported as chips get faster. We also know that there is latency in the P2's I/O pins. I am not sure how this latency might impact switching between input and output on the same pin.
Therefore, IMHO, 4pin SPI Flash needs to be supported, and 3pin should be optional. But I showed how we can have both, and automatically decide.