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.
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.
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.
'+-----------------------------------------------------------------------------+
'+ 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
'+-----------------------------------------------------------------------------+
'+ 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?
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 ?
'+-----------------------------------------------------------------------------+
'+ 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 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
'+-----------------------------------------------------------------------------+
'+ 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.
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 ?
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.
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.
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.
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?
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.
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.
Comments
Keeps the ROM simpler.
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.
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<<25Looks good. Nice way to cover the _XPPPP cases.
There should also be a rule for PFD frequency Min/Max mentioned ? (PFD = Xtal / DDDDDD = VCO / MMMMMMMMMM)
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 ?
_XMUL = 180 ' crystal / div * mul
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.
'+-----------------------------------------------------------------------------+ '+ 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 _readFILEProvided 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 ?
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.
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
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 ?
Thanks,
C.W.
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.
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.
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.