Shop OBEX P1 Docs P2 Docs Learn Events
TAQOZ - Tachyon Forth for the P2 BOOT ROM - Page 14 — Parallax Forums

TAQOZ - Tachyon Forth for the P2 BOOT ROM

1111214161738

Comments

  • jmgjmg Posts: 15,140
    These secondary bootloaders annoy me in that they are an extra layer that needs to be added when all we need to know at boot is what it has for a clock. So I propose that both the Flash and the SD have configuration parameters that are set by the user so that when they save a file they can also describe their system that the boot loader can use. The loader wants to know if there is an oscillator or a crystal, the frequency of that crystal, the desired runtime frequency after booting, and perhaps the baud rate of any terminal that may be connected.
    It may also need to know the stabilize delay. Maybe the header can simply store the 32b Osc Config copy, which includes the XI settings, and PLL values, plus the delay ?
    Keeps the ROM simpler.

  • Cluso99Cluso99 Posts: 18,066
    edited 2018-11-04 03:49
    Chip,
    Is this how the xtal circuit works...

    clockfreq = crystal / dddddd * mmmmmmmmmm / pppp

    where pppp is 1=15, 2=0, 4=2...30=14 (eg divide by 1 means pppp=%1111, divide by 4 means pppp=%0001)

    Put differently, the pppp divider divides the result of the xtal divided by dddddd and multiplied by mmmmmmmmmm
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    Chip,
    Is this how the xtal circuit works...

    clockfreq = crystal / dddddd * mmmmmmmmmm / pppp

    where pppp is 1=15, 2=0, 4=2...30=14 (eg divide by 1 means pppp=%1111, divide by 4 means pppp=%0001)

    Put differently, the pppp divider divides the result of the xtal divided by dddddd and multiplied by mmmmmmmmmm

    That's right. And try to keep the VCO over 50MHz.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-11-04 10:14
    Crystal Parameters for HUBSET

    This should work. Just fill in the values and the values will be calculated for you...
    CON
    _XTALFREQ       = 12_000_000                                    ' crystal frequency
    _XDIV           = 12                                            ' crystal divider to give 1MHz
    _XMUL           = 180                                           ' crystal / div * mul
    _XDIVP          = 1                                             ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
    _XOSC           = %01                                   'OSC    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    _XSEL           = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
    _XPPPP          = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
    _CLOCKFREQ      = _XTALFREQ / _XDIV * _XMUL / _XDIVP                            
    _SETFREQ        = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
    _ENAFREQ        = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator
    
    DAT
    '+-------[ Set Xtal ]----------------------------------------------------------+ 
                    hubset  #0                              ' set 20MHz+ mode
                    hubset  ##_SETFREQ                      ' setup oscillator
                    waitx   ##20_000_000/100                ' ~10ms
                    hubset  ##_ENAFREQ                      ' enable oscillator
    '+-----------------------------------------------------------------------------+
    
    Oops. Fixed this _SETFREQ = 1<<24 +.. was 1<<25
  • cgraceycgracey Posts: 14,133
    It seems to me that the goal of the initial booter in ROM should be ONLY to load in enough program data from either a Flash or SD card to execute a program that sets the clock mode and loads in the rest of the data to launch the application. We can't cover every SPI memory (flash?) possibility in ROM and exploit their special features. It's futile to try to have the ROM cover unknowns. Same goes for SD card support. Just have common-base approaches to loading in some code and let the code handle the specifics for the bigger job. As they say, reliability is inversely proportional to complexity. Simple is best.
  • And a configuration file is a better known then a safe guess
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    Crystal Parameters for HUBSET

    This should work. Just fill in the values and the values will be calculated for you...
    CON
    _XTALFREQ       = 12_000_000                                    ' crystal frequency
    _XDIV           = 12                                            ' crystal divider to give 1MHz
    _XMUL           = 180                                           ' crystal / div * mul
    _XDIVP          = 1                                             ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30)
    _XOSC           = %01                                   'OSC    ' %00=OFF, %01=OSC, %10=15pF, %11=30pF
    _XSEL           = %11                                   'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms)
    _XPPPP          = ((_XDIVP>>1) + 15) & $F                       ' 1->15, 2->0, 4->1, 6->2...30->14
    _CLOCKFREQ      = _XTALFREQ / _XDIV * _XMUL / _XDIVP                            
    _SETFREQ        = 1<<25 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2  ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00  ' setup  oscillator
    _ENAFREQ        = _SETFREQ + _XSEL                                             ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss  ' enable oscillator
    
    DAT
    '+-------[ Set Xtal ]----------------------------------------------------------+ 
                    hubset  #0                              ' set 20MHz+ mode
                    hubset  ##_SETFREQ                      ' setup oscillator
                    waitx   ##20_000_000/100                ' ~10ms
                    hubset  ##_ENAFREQ                      ' enable oscillator
    '+-----------------------------------------------------------------------------+
    

    Looks good. Nice way to cover the _XPPPP cases.
  • cgraceycgracey Posts: 14,133
    Tools will install appropriate loaders. The ROM doesn't need to second-guess the future. Just cover the most basic.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    That's right. And try to keep the VCO over 50MHz.
    .. and below ? MHz ?

    There should also be a rule for PFD frequency Min/Max mentioned ? (PFD = Xtal / DDDDDD = VCO / MMMMMMMMMM)

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Tools will install appropriate loaders. The ROM doesn't need to second-guess the future. Just cover the most basic.

    Yes.
    The ROM already uses smart pin modes for UART, so it should be able to be acceptably fast, using the Smart Pin SPI modes + RCFAST ?
  • Cluso99Cluso99 Posts: 18,066
    So this should give 50MHz minimum and 400MHz maximum?

    _XMUL = 180 ' crystal / div * mul
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    That's right. And try to keep the VCO over 50MHz.
    .. and below ? MHz ?

    There should also be a rule for PFD frequency Min/Max mentioned ? (PFD = Xtal / DDDDDD = VCO / MMMMMMMMMM)

    Ah, sorry. 180MHz max, unless you are overclocking, in which case the sky is the limit and you'd use %1111 for the post-divider which means divide-by-1. The first thing to fail is the 10-bit VCO divider (acts as a multiplier) at ~408MHz (don't know how high the VCO actually goes). Fortunately, the core logic isn't being held up by the PLL, because it seems to fail at 360MHz.
  • Cluso99Cluso99 Posts: 18,066
    Here is the ROM MBR/VOL signature test code
    '+-----------------------------------------------------------------------------+
    '+ Validate MBR/VOL CSUM $080-$17F="Prop". If valid, copy to Cog & Run         +
    '+-----------------------------------------------------------------------------+
    _validateCSUM   mov     bufad,            #$17C         ' check long at $17C
                    rdlong  reply,            bufad         '
                    cmp     reply,            ##_csum   wz  ' ="Prop"?
            if_e    jmp     #@_success80                    ' y: go load it
                    cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
            if_ne   RET                                     ' return "NZ" = not found
    '               ----------------------------------------
                    mov     bufad,            #$174         ' get sector start
                    rdlong  dat_begin,        bufad         '
                    mov     bufad,            #$178         ' get length(bytes)
                    rdlong  _sectors,         bufad         ' simulate file found
    '                                                       ' fall thru to _readFILE
    

    Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
    +$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
    +$174 = the sector start
    +$178 = the length(bytes)
    +$17C = "ProP" signature
  • cgraceycgracey Posts: 14,133
    Cluso99 wrote: »
    Here is the ROM MBR/VOL signature test code
    '+-----------------------------------------------------------------------------+
    '+ Validate MBR/VOL CSUM $080-$17F="Prop". If valid, copy to Cog & Run         +
    '+-----------------------------------------------------------------------------+
    _validateCSUM   mov     bufad,            #$17C         ' check long at $17C
                    rdlong  reply,            bufad         '
                    cmp     reply,            ##_csum   wz  ' ="Prop"?
            if_e    jmp     #@_success80                    ' y: go load it
                    cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
            if_ne   RET                                     ' return "NZ" = not found
    '               ----------------------------------------
                    mov     bufad,            #$174         ' get sector start
                    rdlong  dat_begin,        bufad         '
                    mov     bufad,            #$178         ' get length(bytes)
                    rdlong  _sectors,         bufad         ' simulate file found
    '                                                       ' fall thru to _readFILE
    

    Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
    +$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
    +$174 = the sector start
    +$178 = the length(bytes)
    +$17C = "ProP" signature

    So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Cluso99 wrote: »
    Here is the ROM MBR/VOL signature test code
    [code]
    ...
    Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
    +$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
    +$174 = the sector start
    +$178 = the length(bytes)
    +$17C = "ProP" signature

    So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?

    + Some delay may, or may not, be needed - depends on the external clock source ?

    If you just loaded a small booter, why not have that code set the clock it wants, then it can also manage the delays ?
  • Cluso99Cluso99 Posts: 18,066
    cgracey wrote: »
    Cluso99 wrote: »
    Here is the ROM MBR/VOL signature test code
    '+-----------------------------------------------------------------------------+
    '+ Validate MBR/VOL CSUM $080-$17F="Prop". If valid, copy to Cog & Run         +
    '+-----------------------------------------------------------------------------+
    _validateCSUM   mov     bufad,            #$17C         ' check long at $17C
                    rdlong  reply,            bufad         '
                    cmp     reply,            ##_csum   wz  ' ="Prop"?
            if_e    jmp     #@_success80                    ' y: go load it
                    cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
            if_ne   RET                                     ' return "NZ" = not found
    '               ----------------------------------------
                    mov     bufad,            #$174         ' get sector start
                    rdlong  dat_begin,        bufad         '
                    mov     bufad,            #$178         ' get length(bytes)
                    rdlong  _sectors,         bufad         ' simulate file found
    '                                                       ' fall thru to _readFILE
    

    Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
    +$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
    +$174 = the sector start
    +$178 = the length(bytes)
    +$17C = "ProP" signature

    So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?

    I would set the clock according to the long setting at MBR/VOL offset $170 (AND off the bottom 2 ss bits), delay 10ms at 30MHz (being max rcfast), then redo with ss set accordingly, then load the data/file at the new clock frequency from sector specified by $174 for length at $178.

    Maybe this is just too much?

    Currently we can load/run an MBR/VOL minimum first stage booter, or load/run from a pointer+length in MBR/VOL, or load/run a FAT32 file "_BOOT_P2.BIX" or "_BOOT_P2.BIY". This FAT32 file can be a small first stage booter, or the real thing. These are all done at RCFAST. The first stage loader can switch xtal.
  • jmgjmg Posts: 15,140
    edited 2018-11-04 05:50
    Cluso99 wrote: »
    Maybe this is just too much?
    How much time is saved here ?

    Is the same header applicable to FLASH boot ?

    I guess to make this flexible/transparent, that 'gear change' could be optional ?
    +$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
    ie using those spare 7 bits to signal ignore or apply

  • cgraceycgracey Posts: 14,133
    edited 2018-11-04 06:45
    Cluso99 wrote: »
    cgracey wrote: »
    Cluso99 wrote: »
    Here is the ROM MBR/VOL signature test code
    '+-----------------------------------------------------------------------------+
    '+ Validate MBR/VOL CSUM $080-$17F="Prop". If valid, copy to Cog & Run         +
    '+-----------------------------------------------------------------------------+
    _validateCSUM   mov     bufad,            #$17C         ' check long at $17C
                    rdlong  reply,            bufad         '
                    cmp     reply,            ##_csum   wz  ' ="Prop"?
            if_e    jmp     #@_success80                    ' y: go load it
                    cmp     reply,            ##_csum2  wz  ' ="ProP"? sector/size?
            if_ne   RET                                     ' return "NZ" = not found
    '               ----------------------------------------
                    mov     bufad,            #$174         ' get sector start
                    rdlong  dat_begin,        bufad         '
                    mov     bufad,            #$178         ' get length(bytes)
                    rdlong  _sectors,         bufad         ' simulate file found
    '                                                       ' fall thru to _readFILE
    

    Provided we can find a few more longs in the Boot ROM, what if the signature was "Prop" then
    +$170 = the hubset crystal setting ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss
    +$174 = the sector start
    +$178 = the length(bytes)
    +$17C = "ProP" signature

    So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?

    I would set the clock according to the long setting at MBR/VOL offset $170 (AND off the bottom 2 ss bits), delay 10ms at 30MHz (being max rcfast), then redo with ss set accordingly, then load the data/file at the new clock frequency from sector specified by $174 for length at $178.

    Maybe this is just too much?

    Currently we can load/run an MBR/VOL minimum first stage booter, or load/run from a pointer+length in MBR/VOL, or load/run a FAT32 file "_BOOT_P2.BIX" or "_BOOT_P2.BIY". This FAT32 file can be a small first stage booter, or the real thing. These are all done at RCFAST. The first stage loader can switch xtal.

    I don't know if it's too much. Perhaps SD card know-how is stable enough that this could get around needing a 2nd-stage loader. If the process is deterministic and not likely needing to change, then I guess reading some clock constants and setting the clock accordingly, then loading the file is doing what the 2nd-stage loader would have done, anyway, without requiring it to be there. That's the thinking behind this, right? It wouldn't preclude anyone from making a 2nd-stage loader, would it? Maybe it's just fine to do that. I know that SPI flash chips vary too widely to be able to take such a singular approach.
  • jmgjmg Posts: 15,140
    edited 2018-11-04 07:27
    cgracey wrote: »
    I don't know if it's too much. Perhaps SD card know-how is stable enough that this could get around needing a 2nd-stage loader. If the process is deterministic and not likely needing to change, then I guess reading some clock constants and setting the clock accordingly, then loading the file is doing what the 2nd-stage loader would have done, anyway, without requiring it to be there. That's the thinking behind this, right? It wouldn't preclude anyone from making a 2nd-stage loader, would it? Maybe it's just fine to do that. I know that SPI flash chips vary too widely to be able to take such a singular approach.

    If the Clock setting param is made optional (using the spare bits to say skip, or as a simple checksum of the lower bits, whose error says skip ?) then it becomes invisible, and any second stage loads as before.
    It could be useful to have the same param rule on FLASH, to allow faster boot-loading from flash ?
  • With test boards hopefully coming out soon, is there a basic getting started document for TAQOS?


    Thanks,


    C.W.
  • Just go to page 1 of this thread. BTW, it's spelled TAQOZ.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-12-04 15:13
    This is a photo of my VGA monitor and PS/2 keyboard setup which is running stand-alone although the serial port is still plugged into the PC but otherwise the Forth console is using VGA and PS/2. When it first starts up it displays the "PARALLAX P2 TAQOZ PC" message and then attempts to mount the SD card and report the name etc. Then it switches to a black on white text format and displays a short listing of the FAT32 directory. In this case I decide to load and compile C2PROG.FTH which has all the programmer and debugging words for the Busy Bee 8051 micro I'm testing. Then I run a simple Fibonacci benchmark, change the pen color to red, set the graphics to use from 400,400 to draw a filled in panel for 100 wide and 60 high before returning the pen back to black.

    After this .SF lists the idents of the SPI Flash chip and then I dump some hub RAM. All from the PS/2 keyboard. If I view a BMP file I find it easier to get the console to use 8 or 10 lines at the bottom of the screen for text with 10 TERM so that it only scrolls text in that region.

    P2PC.jpg

    Here I add a bit more in a crude Q&d way as I define FLAG which simply draws a vertical red/green/blue flag as specified.
    P2PC1.jpg
  • nice
  • Cluso99Cluso99 Posts: 18,066
    Looking good Peter, as usual :smiley:
  • Wow Peter! It looks beautiful, simple and clean!
  • Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.
  • kwinnkwinn Posts: 8,697
    rogloh wrote: »
    Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.

    Looks OK to me, like it is just the result of the line of text being longer than the terminal screen can display so it wraps it around to the next line. Could you be mistaking the reflection on the bezel for part of the video image?
  • kwinn wrote: »
    rogloh wrote: »
    Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.

    Looks OK to me, like it is just the result of the line of text being longer than the terminal screen can display so it wraps it around to the next line. Could you be mistaking the reflection on the bezel for part of the video image?

    I see it too. The very first column of pixels, not of text. It's only on the two lines with an E and an N at the very end.
  • kwinnkwinn Posts: 8,697
    kwinn wrote: »
    rogloh wrote: »
    Something seems slightly weird Peter with your video driver. I noticed that the pixels at the end of the line wrap back to the start of the line, see the letter E and N on the right edge from the word "PANEL", and also the pixels on the left edge in your picture above. I think you just need to clear the last pixel at the end of the scanline as it is being replicated on the next scanline, or something like that. Maybe it is off by a whole pixel somewhere.

    Looks OK to me, like it is just the result of the line of text being longer than the terminal screen can display so it wraps it around to the next line. Could you be mistaking the reflection on the bezel for part of the video image?

    I see it too. The very first column of pixels, not of text. It's only on the two lines with an E and an N at the very end.

    My what sharp eyes you have. With reading glasses on and the laptop screen a couple of inches from my eyes I can finally see it.
  • I see what has happened with the pixels on the screen, it looks like my line wrap is off by one pixel but since my left margin is set to 6 pixels it was also easy just to change that to 5 pixels so that the last character fits.
Sign In or Register to comment.