@Rayman said:
@ersmith Been wondering about something... In your Github readme files you seem to be doing things as if logged into root. I seem to have to preface a lot of things with "sudo". Do you really run as logged into root all the time? Or, is there something I'm missing?
No, I never log in as root. I just make sure that my regular user owns any files (like the /opt/riscv directory) that I need to modify.
Ok, figured out the clock. Was blundering that badly, but more importantly see that need to manually remove the lower two bits of clock mode because the code first sets it that way as this is without the PLL, then it adds 3 to that and hubsets it again to turn on the PLL. Think good now.
@ersmith Just out of curiosity... Since this is actually GCC going on here, does that mean that the GDB debugger might work?
Guess that would mean disconnecting the serial output or opening up a different serial output?
@ersmith Hard to imagine, but I think there's a bug in propeller2.h
//RJA thinks this is wrong: #define _waitus(u) _waitx((u)/(_clockfreq()/1000000))
#define _waitus(u) _waitx((u)*(_clockfreq()/1000000))
Also, added a _waitms() using same way.
Was trying to use csr for this but must be doing something wrong...
millis_write_csr
' wait pb milliseconds
rdlong temp, #$14 ' get frequency
qdiv temp, ##1000
getqx temp ' now have freq/1000 in temp
'qmul pb, temp
'getqx pb
mul pb, temp
waitx pb
ret
@Rayman said:
@ersmith Just out of curiosity... Since this is actually GCC going on here, does that mean that the GDB debugger might work?
Guess that would mean disconnecting the serial output or opening up a different serial output?
We'd have to implement a gdb debug stub on the P2 side. There probably is something already for RISC-V, but it may rely on instructions and/or hardware features that aren't implemented yet.
//RJA thinks this is wrong: #define _waitus(u) _waitx((u)/(_clockfreq()/1000000))
#define _waitus(u) _waitx((u)*(_clockfreq()/1000000))
Whoops, good catch! I'll check in the fix.
Also, added a _waitms() using same way.
Was trying to use csr for this but must be doing something wrong...
Changing from qmul to mul probably won't work, because frequency/1000 will exceed 16 bits if you're running at more than 65 MHz.
@Rayman said:
The other issue with waitms is breaking the uart if using rep that would stop the interrupt. That's be a concern, right?
I can't remember if rep in HUB stops interrupts, but it might be safer to use a djnz loop instead.
BTW I've updated the riscvp2 repo a bit to reflect the new xpack 13.2.0-2 compiler. I've also made it easier to change clock frequency: just edit the _clkfreq definition at the top of riscvptrace_p2.spin2. The default is now 252 MHz, which should be nicer for HDMI work (the default 160 MHz dated back to when we were first getting boards and the official Parallax line was that 180 MHz was the maximum frequency).
Do you really need to explicitly specify libgcc.a? I think the compiler should find it for you. But yeah, that one or rv32imc should be fine -- the latter ought to be a little bit smaller.
@Rayman said:
the "c" is for compressed, right? Does that mean smaller but slower because needs to be decompressed?
Smaller but not really any slower (it means some instructions are encoded in 16 bits instead of 32 bits). I guess decoding the 16 bit instructions is slightly more complicated and so may be slightly slower, but they all get compiled to the same P2 code.
Comments
Ok, that didn't work out... P2 instantly reboots when hello.elf is loaded... Hmm...
No, I never log in as root. I just make sure that my regular user owns any files (like the /opt/riscv directory) that I need to modify.
I've always wondered what is common practice with editing files in non-/home directories too. Looks like the answer is "it depends".
Ok, figured out the clock. Was blundering that badly, but more importantly see that need to manually remove the lower two bits of clock mode because the code first sets it that way as this is without the PLL, then it adds 3 to that and hubsets it again to turn on the PLL. Think good now.
@ersmith looks like spin2cpp doesn't know about getsec() either.
But, think can work around that...
Or, maybe not, can't do inline assembly either...
@ersmith Just out of curiosity... Since this is actually GCC going on here, does that mean that the GDB debugger might work?
Guess that would mean disconnecting the serial output or opening up a different serial output?
@ersmith Hard to imagine, but I think there's a bug in propeller2.h
Also, added a _waitms() using same way.
Was trying to use csr for this but must be doing something wrong...
millis_write_csr ' wait pb milliseconds rdlong temp, #$14 ' get frequency qdiv temp, ##1000 getqx temp ' now have freq/1000 in temp 'qmul pb, temp 'getqx pb mul pb, temp waitx pb retWe'd have to implement a gdb debug stub on the P2 side. There probably is something already for RISC-V, but it may rely on instructions and/or hardware features that aren't implemented yet.
Whoops, good catch! I'll check in the fix.
Changing from qmul to mul probably won't work, because frequency/1000 will exceed 16 bits if you're running at more than 65 MHz.
The other issue with waitms is breaking the uart if using rep that would stop the interrupt. That's be a concern, right?
The concept might work if the rep wrapped an addct, pollse, conditional jump, waitct sequence.
That way the timing should remain constant and the uart driver will not be starved of interrupts for the full delay period.
I can't remember if rep in HUB stops interrupts, but it might be safer to use a djnz loop instead.
BTW I've updated the riscvp2 repo a bit to reflect the new xpack 13.2.0-2 compiler. I've also made it easier to change clock frequency: just edit the _clkfreq definition at the top of riscvptrace_p2.spin2. The default is now 252 MHz, which should be nicer for HDMI work (the default 160 MHz dated back to when we were first getting boards and the official Parallax line was that 180 MHz was the maximum frequency).
Thanks @ersmith sounds great!
I suppose in the context of micropython around 250 MHz is good for future hdmi output. Glad easier to change though…
@ersmith Think asked this before, but had to pick a folder for libgcc.a...
Does this look right?
Seems to work...
RV32_GCCLIB=/opt/riscv/lib/gcc/riscv-none-elf/13.2.0/rv32ima/ilp32/libgcc.aDo you really need to explicitly specify libgcc.a? I think the compiler should find it for you. But yeah, that one or
rv32imcshould be fine -- the latter ought to be a little bit smaller.the "c" is for compressed, right? Does that mean smaller but slower because needs to be decompressed?
Smaller but not really any slower (it means some instructions are encoded in 16 bits instead of 32 bits). I guess decoding the 16 bit instructions is slightly more complicated and so may be slightly slower, but they all get compiled to the same P2 code.