I think the only way to make it fully safe is Debug would have to know to hold its horses while the PLL is in flux. It would need an early warning prior to passing the new frequency.
Or Debug takes over the job of clkset().
Hmm, certainly more complications than I first envisioned. In reality though, clkset() gets used when there's no other action.
Historically, if our software receives a low flag score (and medium to low severity) and/or is only flagged by lesser-known antivirus systems, it's actually turned out to be completely clean. There were a few false-positives we found a couple years ago and reported to the larger-known AV systems and they confirmed they were false and issued updates back then, but at this point that doesn't seem to be happening here and we're not concerned about these two that are reported.
It's still slightly possible yours was infected on it's way down to your computer, or once on your computer. The best way to check that I know of is to compare SHA256 results on the exe. I think the SHA256 result is included near the top of that VirusTotal page for your comparison against your local copy.
Historically, if our software receives a low flag score (and medium to low severity) and/or is only flagged by lesser-known antivirus systems, it's actually turned out to be completely clean. There were a few false-positives we found a couple years ago and reported to the larger-known AV systems and they confirmed they were false and issued updates back then, but at this point that doesn't seem to be happening here and we're not concerned about these two that are reported.
It's still slightly possible yours was infected on it's way down to your computer, or once on your computer. The best way to check that I know of is to compare SHA256 results on the exe. I think the SHA256 result is included near the top of that VirusTotal page for your comparison against your local copy.
This is not infection, this is a "reputation filter" - I cannot write what I think about it as it will be censored by the forum software.
It's funny in a way. I've not ever felt the need for such tools over the Internet. For example, emails, outside of M$ auto-running rubbish, were never an issue. Same goes for CDs. It was always the auto-run that got everyone in trouble. In the days of bootable floppy discs on the other hand, they surely needed such scanners.
Yeah, antivirus, esp. these days, is mostly useful to stop stupidity. If you know what you're doing (i.e. not running random Smile off shady websites), you don't need it. If you have a file you're suspicious of, you can use the vastly more powerful online scanners.
I made DEBUG adapt to ClkFreq changes. You just have to keep P63 updated with the current ClkFreq value:
DIRH #63
WXPIN ClkFreq,#63
DIRL #63
P63 now gets configured as a long repository when debug is enabled and it stores the ClkFreq value for use within debug interrupts. In Spin2, CLKFREQ(ClkMode, ClkFreq) handles this automatically when in debug mode.
I posted the new PNut version at the top of this thread and also updated the P2_PNut_Public repository here:
There is a new crank.bat file in the repository which builds everything from the command line in a few seconds. Way better than before. This is all thanks to Tom Mornini, who helped me last week with git and streamlining my workflow.
Here is a Spin2 program that switches frequency while the debugger is running:
'
' This program demonstrates how the debugger/DEBUG baud rate remains stable
' after switching clock frequencies via CLKSET(ClkMode, ClkFreq).
'
' Use Ctrl-F10 to compile, download, and start the debugger. Once in the
' debugger, right-click on "Go" or press <Enter> to rapidly single-step.
' Move the cursor off the debugger window and watch the clock frequency
' change at the bottom of the window as the code executes.
'
' Arbitrary ClkMode values can be generated by setting _clkfreq to any
' frequency and then using Ctrl-L to compile and view the listing.
'
CON
_clkfreq = 100_000_000 'start at 100 MHz
debug_main 'single-step through main code
PUB go()
repeat 'repeatedly swich frequency
clkset($01000EFB, 300_000_000) 'switch to 300 MHz
clkset($0100099B, 10_000_000) 'switch to 10 MHz
Hmm, still unhappy about the hidden code inserted into pure ASM programs - maybe just compile ASMCLK to a bunch of NOPs when debug is enabled (since debugger sets clock anyways), that should solve the stepping problem.
@Wuerfel_21 said:
Hmm, still unhappy about the hidden code inserted into pure ASM programs - maybe just compile ASMCLK to a bunch of NOPs when debug is enabled (since debugger sets clock anyways), that should solve the stepping problem.
It only prepends the clock_setter program if you've selected some XTAL/PLL mode or RCSLOW. If you specify nothing, you will be running RCFAST and clock_setter won't be prepended. You can then do the clock setup in your own code. How do you feel about that?
Also, what the clock_setter does is move your app down to $00000 and then "COGINIT #0,#$00000". It only has to move your app down 64 bytes in position to get it to $00000. It does it using "SETQ2 #$1FF + RD/WRLONG". It's fast.
It's more about there being any hidden preload code at all - that's what bugs me. In an ASM program it should put exactly what you write into the file, not a single bit more.
@Wuerfel_21 said:
It's more about there being any hidden preload code at all - that's what bugs me. In an ASM program it should put exactly what you write into the file, not a single bit more.
Then don't specify any clock settings and you'll start in RCFAST without the 64-byte clock_setter being prepended. That's as natural as you can get.
I have to agree with Ada that adding code to assembly programs seems kind of sketchy. Couldn't there be a new assembler directive or constant to add the clock setting automatically, so existing programs don't change? Couldn't we re-purpose ASMCLK somehow? As it stands right now I don't think I want to change flexspin to do this new thing.
That won't work in PropTool though and is still less than ideal because now I'd have to do that every time I want to change it (or worse, I have to explain to someone else how to do that).
Sorry if I missed something, but whatever happened to just storing the current CLKFREQ and CLKMODE at fixed locations in hubram, as was done on the P1?
I think you guys are making this much scarier than it actually is.
All that happens is a 16-long program is placed before your entire PASM app. It sets up the clock by executing a few HUBSET instructions, then moves your entire PASM app down to $00000, then does a COGINIT #0,#$0000. Your PASM app then runs, none the wiser, but with the clock conveniently pre-configured.
This whole process adds maybe 12 milliseconds to your app starting. 10 ms is spent allowing the XTAL/PLL to stabilize. After that, 2 ms is enough time to move your huge app into position and execute it.
@Electrodude said:
Sorry if I missed something, but whatever happened to just storing the current CLKFREQ and CLKMODE at fixed locations in hubram, as was done on the P1?
That would complicate simple PASM programs. It would be horrible to impose a universal stricture like that. I think we are lucky that P63 could be repurposed as a way to hold the clock frequency for debugging, since it doesn't make any mandate on hub memory.
@cgracey said:
I think you guys are making this much scarier than it actually is.
All that happens is a 16-long program is placed before your entire PASM app. It sets up the clock by executing a few HUBSET instructions, then moves your entire PASM app down to $00000, then does a COGINIT #0,#$0000. Your PASM app then runs, none the wiser, but with the clock conveniently pre-configured.
This whole process adds maybe 12 milliseconds to your app starting. 10 ms is spent allowing the XTAL/PLL to stabilize. After that, 2 ms is enough time to move your huge app into position and execute it.
Sometimes people want to create a binary that gets loaded and run from another address than 0 (e.g. for overlays). Sometimes they want finer control over the clock setting, or to have it done later. Generally speaking I think the assembler should just output what the user gives it, without adding more stuff.
@Electrodude said:
Sorry if I missed something, but whatever happened to just storing the current CLKFREQ and CLKMODE at fixed locations in hubram, as was done on the P1?
We were talking about PASM only programs. The fixed locations in hubram are for high level languages (and are different between the official Spin2 interpreter and all the other high level languages, but that's another can of worms).
How about an assembler directive that goes inside an orgh region in a DAT section that tells the debugger where to put this information?
If debug mode is off, it just turns into wasted memory. If debug is on, but this directive is missing and you don't want to require it for debug, then you can fall back to the trick with the 16-long prefix and the long repository smartpin.
@cgracey said:
I think you guys are making this much scarier than it actually is.
All that happens is a 16-long program is placed before your entire PASM app. It sets up the clock by executing a few HUBSET instructions, then moves your entire PASM app down to $00000, then does a COGINIT #0,#$0000. Your PASM app then runs, none the wiser, but with the clock conveniently pre-configured.
This whole process adds maybe 12 milliseconds to your app starting. 10 ms is spent allowing the XTAL/PLL to stabilize. After that, 2 ms is enough time to move your huge app into position and execute it.
That's sounding tolerable.
For the case ersmith mentions, I presume you meant the 16 long program temporarily shifts the user asm image up 16 longs, and then that is moved down 16 longs, and run ?
If the user asm appears to be identical in size and location, that's ok to me.
The risk I can see here is someone who forgets to set clocks the same as Debug and everything runs ok in debug, then when they do a ship-image, things are not quite the same.
@jmg said:
The risk I can see here is someone who forgets to set clocks the same as Debug and everything runs ok in debug, then when they do a ship-image, things are not quite the same.
It's something to manage as a developer. RCFAST is the default power-up state but Debug kind of needs a known clock frequency. RCFAST ain't that.
RCFAST maybe temperature stable but isn't that well defined to have a preset known frequency. It's partly why the ROM downloader waits for special serial preamble to measure the baud timing.
pity the debug tx/rx can't just work on a fixed baud "debug_baud", regardless of what the program baud is doing. ie. this means it occasionally re-calibrates itself with the current clkfreq and/or incomming debug rx (or does so deterministically if there's a register or event that debug might be able to consume)
Comments
Overkill I suspect. Can't really make it completely safe because other cogs could be using debug too.
Err, blocking IRQs is sensible still.
I think the only way to make it fully safe is Debug would have to know to hold its horses while the PLL is in flux. It would need an early warning prior to passing the new frequency.
Or Debug takes over the job of
clkset().Hmm, certainly more complications than I first envisioned. In reality though,
clkset()gets used when there's no other action.Yes, other cogs might be doing something. I don't think it can be made totally fail-safe.
It only triggered 2/62 (and both are not widely used antivirus systems to my knowledge) on VirusTotal: https://www.virustotal.com/gui/file/64b51efb1e03a6c0ff52c10888f3aeb1cdca130663c505aa8ee87f75a7368ec5?nocache=1
Historically, if our software receives a low flag score (and medium to low severity) and/or is only flagged by lesser-known antivirus systems, it's actually turned out to be completely clean. There were a few false-positives we found a couple years ago and reported to the larger-known AV systems and they confirmed they were false and issued updates back then, but at this point that doesn't seem to be happening here and we're not concerned about these two that are reported.
It's still slightly possible yours was infected on it's way down to your computer, or once on your computer. The best way to check that I know of is to compare SHA256 results on the exe. I think the SHA256 result is included near the top of that VirusTotal page for your comparison against your local copy.
This is not infection, this is a "reputation filter" - I cannot write what I think about it as it will be censored by the forum software.
Certainly lowers my opinion of virus scanner software in general.
Sign of the times; too many bad actors up to no good. If only we could get them to create truly beneficial things with their talents...
It's funny in a way. I've not ever felt the need for such tools over the Internet. For example, emails, outside of M$ auto-running rubbish, were never an issue. Same goes for CDs. It was always the auto-run that got everyone in trouble. In the days of bootable floppy discs on the other hand, they surely needed such scanners.
Yeah, antivirus, esp. these days, is mostly useful to stop stupidity. If you know what you're doing (i.e. not running random Smile off shady websites), you don't need it. If you have a file you're suspicious of, you can use the vastly more powerful online scanners.
I made DEBUG adapt to ClkFreq changes. You just have to keep P63 updated with the current ClkFreq value:
P63 now gets configured as a long repository when debug is enabled and it stores the ClkFreq value for use within debug interrupts. In Spin2, CLKFREQ(ClkMode, ClkFreq) handles this automatically when in debug mode.
I posted the new PNut version at the top of this thread and also updated the P2_PNut_Public repository here:
https://github.com/parallaxinc/P2_PNut_Public
There is a new crank.bat file in the repository which builds everything from the command line in a few seconds. Way better than before. This is all thanks to Tom Mornini, who helped me last week with git and streamlining my workflow.
Here is a Spin2 program that switches frequency while the debugger is running:
' ' This program demonstrates how the debugger/DEBUG baud rate remains stable ' after switching clock frequencies via CLKSET(ClkMode, ClkFreq). ' ' Use Ctrl-F10 to compile, download, and start the debugger. Once in the ' debugger, right-click on "Go" or press <Enter> to rapidly single-step. ' Move the cursor off the debugger window and watch the clock frequency ' change at the bottom of the window as the code executes. ' ' Arbitrary ClkMode values can be generated by setting _clkfreq to any ' frequency and then using Ctrl-L to compile and view the listing. ' CON _clkfreq = 100_000_000 'start at 100 MHz debug_main 'single-step through main code PUB go() repeat 'repeatedly swich frequency clkset($01000EFB, 300_000_000) 'switch to 300 MHz clkset($0100099B, 10_000_000) 'switch to 10 MHzHmm, still unhappy about the hidden code inserted into pure ASM programs - maybe just compile ASMCLK to a bunch of NOPs when debug is enabled (since debugger sets clock anyways), that should solve the stepping problem.
It only prepends the clock_setter program if you've selected some XTAL/PLL mode or RCSLOW. If you specify nothing, you will be running RCFAST and clock_setter won't be prepended. You can then do the clock setup in your own code. How do you feel about that?
Also, what the clock_setter does is move your app down to $00000 and then "COGINIT #0,#$00000". It only has to move your app down 64 bytes in position to get it to $00000. It does it using "SETQ2 #$1FF + RD/WRLONG". It's fast.
But then I'd need to add/remove the definitions when I toggle debug. IMO the way it is/was is good.
If your own clock setup code doesn't change the frequency from what clock_setter establishes, I think you'll never notice anything.
It's more about there being any hidden preload code at all - that's what bugs me. In an ASM program it should put exactly what you write into the file, not a single bit more.
Then don't specify any clock settings and you'll start in RCFAST without the 64-byte clock_setter being prepended. That's as natural as you can get.
But then I don't get auto-computed clkmode.
You can set _clkfreq to any frequency and do a Ctrl-L to see the resulting clkmode value. Then, just use that in your code.
I have to agree with Ada that adding code to assembly programs seems kind of sketchy. Couldn't there be a new assembler directive or constant to add the clock setting automatically, so existing programs don't change? Couldn't we re-purpose ASMCLK somehow? As it stands right now I don't think I want to change flexspin to do this new thing.
(deleted)
That won't work in PropTool though and is still less than ideal because now I'd have to do that every time I want to change it (or worse, I have to explain to someone else how to do that).
Sorry if I missed something, but whatever happened to just storing the current CLKFREQ and CLKMODE at fixed locations in hubram, as was done on the P1?
I think you guys are making this much scarier than it actually is.
All that happens is a 16-long program is placed before your entire PASM app. It sets up the clock by executing a few HUBSET instructions, then moves your entire PASM app down to $00000, then does a COGINIT #0,#$0000. Your PASM app then runs, none the wiser, but with the clock conveniently pre-configured.
This whole process adds maybe 12 milliseconds to your app starting. 10 ms is spent allowing the XTAL/PLL to stabilize. After that, 2 ms is enough time to move your huge app into position and execute it.
That would complicate simple PASM programs. It would be horrible to impose a universal stricture like that. I think we are lucky that P63 could be repurposed as a way to hold the clock frequency for debugging, since it doesn't make any mandate on hub memory.
Sometimes people want to create a binary that gets loaded and run from another address than 0 (e.g. for overlays). Sometimes they want finer control over the clock setting, or to have it done later. Generally speaking I think the assembler should just output what the user gives it, without adding more stuff.
We were talking about PASM only programs. The fixed locations in hubram are for high level languages (and are different between the official Spin2 interpreter and all the other high level languages, but that's another can of worms).
How about an assembler directive that goes inside an
orghregion in a DAT section that tells the debugger where to put this information?If debug mode is off, it just turns into wasted memory. If debug is on, but this directive is missing and you don't want to require it for debug, then you can fall back to the trick with the 16-long prefix and the long repository smartpin.
That's sounding tolerable.
For the case ersmith mentions, I presume you meant the 16 long program temporarily shifts the user asm image up 16 longs, and then that is moved down 16 longs, and run ?
If the user asm appears to be identical in size and location, that's ok to me.
The risk I can see here is someone who forgets to set clocks the same as Debug and everything runs ok in debug, then when they do a ship-image, things are not quite the same.
It's something to manage as a developer. RCFAST is the default power-up state but Debug kind of needs a known clock frequency. RCFAST ain't that.
RCFAST maybe temperature stable but isn't that well defined to have a preset known frequency. It's partly why the ROM downloader waits for special serial preamble to measure the baud timing.
pity the debug tx/rx can't just work on a fixed baud "debug_baud", regardless of what the program baud is doing. ie. this means it occasionally re-calibrates itself with the current clkfreq and/or incomming debug rx (or does so deterministically if there's a register or event that debug might be able to consume)