TAQOZ - Tachyon Forth for the P2 BOOT ROM

18910111214»

Comments

  • 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: 14,161
    edited November 4 Vote Up0Vote Down
    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
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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: 14,161
    edited November 4 Vote Up0Vote Down
    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
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    P2 SHORTFORM DATASHEET +++++ TAQOZ documentation
    Brisbane, Australia
  • 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.
  • Tools will install appropriate loaders. The ROM doesn't need to second-guess the future. Just cover the most basic.
  • 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)

  • 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 ?
  • So this should give 50MHz minimum and 400MHz maximum?

    _XMUL = 180 ' crystal / div * mul
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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.
  • 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
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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?
  • cgracey wrote: »
    Cluso99 wrote: »
    Here is the ROM MBR/VOL signature test 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 [/quote] So, you would set the clock as requested by the data, then turn control over to the small booter that was just loaded?[/quote] + 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 ? [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 ?
  • 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 12,425
    edited November 4 Vote Up0Vote Down
    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: 10,128
    edited November 4 Vote Up0Vote Down
    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: 12,425
    edited November 4 Vote Up0Vote Down
    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 ?
Sign In or Register to comment.