Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 137 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1134135137139140160

Comments

  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    jmg wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-05 00:24
    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
    
  • From my experience with AUGx it cannot preceed a ALTx instruction.
    ]https://forums.parallax.com/discussion/comment/1436552/#Comment_1436552
  • cgraceycgracey Posts: 14,131
    edited 2018-05-05 02:05
    Cluso99 wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-05 03:21
    cgracey wrote: »
    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.
    Of course not :( Silly me - need more coffee
  • Cluso99Cluso99 Posts: 18,066
    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)
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    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)


    I will do that.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-05 14:28
    Chip,
    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.
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    Chip,
    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?
  • Cluso99Cluso99 Posts: 18,066
    Chip,
    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)
  • cgraceycgracey Posts: 14,131
    So, have you had any luck using the ROM loader that I set up?
  • Cluso99Cluso99 Posts: 18,066
    No. I managed without it, although I did have a few issues before I realised I wasn't clearing down the interrupts and smartpins.

    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.
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    I presume the reason we have to do a coginit #0,#_HUBROM at Cog $0 is because the loader is doing something?

    Could you elaborate a little more? I don't really understand what you're asking.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-05 15:33
    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.

    BTW I have emailed you.
  • cgraceycgracey Posts: 14,131
    Cluso99 wrote: »
    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.

    BTW I have emailed you.

    Okay. I'll be on this in about a half hour.
  • Cluso99Cluso99 Posts: 18,066
    Thanks Chip ;)
    I am off to bed shortly. Post any questions here and I'll check overnight.
  • 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.
    	spi_cs1		=	3		'pin SPI memory select
    	spi_cs		=	2		'pin SPI memory select
    	spi_ck		=	1		'pin SPI memory clock
    	spi_dq		=	0		'pin SPI memory data I/O
    

    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • Cluso99Cluso99 Posts: 18,066
    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.
  • jmgjmg Posts: 15,140
    Cluso99 wrote: »
    ... 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.
  • ... and drop into TAQOZ if nothing else boots?...

    That should be done anyways. If all fails run TAQOZ.

    Enjoy

    Mike
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-07 03:21
    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.
    PIN	SPI FLASH	SD CARD	ROM FLASH
    63	RXD		
    62	TXD		
    61	SFCS		SDCK	
    60	SFCK		SDCS	ROMCK
    59	SFDQ		SDDI	ROMDQ
    58	SFDO*		SDDO 	ROMCS
    

    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-07 04:12
    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?
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-07 04:22
    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.

    I will call you tonight and I'm home tomorrow.
  • @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.
  • jmgjmg Posts: 15,140
    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 ?


  • jmg wrote: »
    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.


  • Cluso99Cluso99 Posts: 18,066
    @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.
Sign In or Register to comment.