@Rayman said:
Also, I can send you one of these SimpleP2 boards with flash on different pins than uSD if you want...
Thanks for your kind offer, but I've got a lot on my plate now and I'd like to focus on the P2 Edge and/or P2 Eval boards for now.
I'm guessing it has to be something to do with allocating a lot of memory, but who knows.
Hmmm, maybe it's worth trying some different sizes for USER_MEMORY. Maybe it needs to be a lot bigger? Or maybe it's too big now and needs to be quite a bit smaller?
@Rayman said:
BTW: Does code compression even make sense if it's on Flash? Maybe best to just leave that off anyway?
It kind of makes sense because it lets you fit more into the 512K available in the address space, and also reduces the amount of data that needs to be read from flash (speeding things up). But it complicates some other things, since instructions are 2 byte aligned instead of 4 byte. I'm still on the fence with that one.
@Rayman, you mentioned earlier you felt it was slow when you configured your build to run MP with HIMEM=flash. Despite the slowdown would you say you feel MP is still quite usable interactively (ignoring the crash problem you encountered) or does it feel very sluggish to respond and would be a turn off for normal users. I'm interested in your general opinion on this.
@Rayman said:
Can this new execute from flash feature works with Eval board ?
That's how I've been testing it. It should work on any board with SPI flash. Note that using the SD card on the Eval board will be a big problem though, you'll have to disable that feature in micropython in order to try it on the Eval board.
Any chance littlefs could also allow concurrent flash access? Seems micropython needs some kind of mass storage. But, maybe there is another uSD adapter for eval type boards…
Think need to take a step back and retry from the start. Seems the regular loader also locks up pye.
So, perhaps not flash problem, but something else in new riscvp2...
@Rayman said:
Any chance littlefs could also allow concurrent flash access? Seems micropython needs some kind of mass storage. But, maybe there is another uSD adapter for eval type boards…
In theory it should be possible. I haven't looked at that yet though.
@Rayman said:
Think need to take a step back and retry from the start. Seems the regular loader also locks up pye.
So, perhaps not flash problem, but something else in new riscvp2...
Definitely worth trying to reduce the USER_MEMORY, perhaps quite drastically -- I seem to recall running into some strange issues when it overflowed.
@Rayman said:
Went back to version of riscvp2 from Jun 4 and pye works again.
That is interesting. Which git version is that? is it 927db502567525d91086e87f80459e5971b3b82f?
The biggest change was just shortly after that, at e8380089625c3e94fe23c93aabac3f0004af261d, it would be interesting if that's where it broke. Although looking at the code it should be safe (it added a second cache set for the flash). Actually that shouldn't affect the non-flash at all. Hmmm; maybe f2b392d2376a7e4116d39135a1da5eccf7c0e642 broke something, but that fixed a real bug (where the HUB memory cache could overflow while expanding).
Also, think I'm seeing that you added in a proper version of rdpin() and rqpin() to riscvp2, right?
Back in April I fixed the binary encoding for those (they were s formats like stores, but should have been i formats because they modify the result register). Looks like I forgot to add a definition for rqpin() to propeller2.h (it is in the JIT compiler though, just not exposed).
Some things about it that could be different, but guess that could work.
Main thing is three unused pins.
Probably would use one of those to be able to cycle power on uSD card.
Guess use other two for QUIIC (I2C) connector...
Also, some complain about series resistor, so probably remove that..
@Rayman ideally we'd get some code working that would allow sharing uSD and flash. Second best would be littlefs in flash, I guess. Not many people have the adapters.
Here's an updated loadp2 with much better flash support -- now it can program flash so that ELF files can be booted (use the -FLASH flag). Beware though that if you program an ELF file that uses the flash for high memory and then just download & run another ELF file with highmem code, the second one will overwrite the high portion of the flash (where the code is) and prevent the bootable one from working on the next boot.
It looks like the default loadp2 FIFO size was too small for Mac, causing downloads to be unreliable (thanks @"Stephen Moraco" for noticing this). Here's a version with a bigger FIFO, which seems much more stable.
@ersmith said:
It looks like the default loadp2 FIFO size was too small for Mac, causing downloads to be unreliable (thanks @"Stephen Moraco" for noticing this). Here's a version with a bigger FIFO, which seems much more stable.
Thanks for updating. I know the default used to work okay for P2-EVAL some time back but for me once the P2 Edge came out and I was using the new PropPlug I found I had to use a 8192 byte FIFO on both my Macs for more reliable uploads.
@Rayman said:
@ersmith Seems something wrong with latest riscvp2 files. It breaks PYE (same way that the HIMEM=flash way does), just hangs.
I don't know... I don't recall changing anything other than the HIMEM code.
Did notice this new message at the end of build:
warning: build/firmware.elf has a LOAD segment with RWX permissions
Does that mean anything to you?
Yes, it's a harmless warning that's generated by the new linker. On platforms with memory management we're not supposed to enable the W (write) and X (execute) bits at the same time, but obviously on the P2 that doesn't matter at all.
Actually the version that works already has HIMEM included (just doesn't work with micropython and pye for some reason).
So, must be something after that...
Was able to get Tensorflow Lite Micro to compile and generate a .bin file, but doesn't seem to work. At least, there's nothing in the terminal window..
Thinking it's because need to get the riscvp2.ld in there, but not exactly sure how.
Tried adding this last line to platform flags in mcu_riscv_makefile.inc, but maybe that's not right?
@Rayman said:
Was able to get Tensorflow Lite Micro to compile and generate a .bin file, but doesn't seem to work. At least, there's nothing in the terminal window..
Thinking it's because need to get the riscvp2.ld in there, but not exactly sure how.
Tried adding this last line to platform flags in mcu_riscv_makefile.inc, but maybe that's not right?
-march=rv64gc is definitely wrong, that's asking for a 64 bit RISC-V with double precision instructions, whereas we emulate a 32 bit integer RISC-V (-march=rv32imac-Zicsr).
Comments
BTW: Does code compression even make sense if it's on Flash? Maybe best to just leave that off anyway?
Thanks for your kind offer, but I've got a lot on my plate now and I'd like to focus on the P2 Edge and/or P2 Eval boards for now.
Hmmm, maybe it's worth trying some different sizes for USER_MEMORY. Maybe it needs to be a lot bigger? Or maybe it's too big now and needs to be quite a bit smaller?
It kind of makes sense because it lets you fit more into the 512K available in the address space, and also reduces the amount of data that needs to be read from flash (speeding things up). But it complicates some other things, since instructions are 2 byte aligned instead of 4 byte. I'm still on the fence with that one.
@Rayman, you mentioned earlier you felt it was slow when you configured your build to run MP with HIMEM=flash. Despite the slowdown would you say you feel MP is still quite usable interactively (ignoring the crash problem you encountered) or does it feel very sluggish to respond and would be a turn off for normal users. I'm interested in your general opinion on this.
I’m not sure now that it is actually slower … importing pye is about the same. That’s kind of the slowest thing I’ve found yet.
Can this new execute from flash feature works with Eval board ?
That's how I've been testing it. It should work on any board with SPI flash. Note that using the SD card on the Eval board will be a big problem though, you'll have to disable that feature in micropython in order to try it on the Eval board.
Any chance littlefs could also allow concurrent flash access? Seems micropython needs some kind of mass storage. But, maybe there is another uSD adapter for eval type boards…
Think need to take a step back and retry from the start. Seems the regular loader also locks up pye.
So, perhaps not flash problem, but something else in new riscvp2...
In theory it should be possible. I haven't looked at that yet though.
Definitely worth trying to reduce the USER_MEMORY, perhaps quite drastically -- I seem to recall running into some strange issues when it overflowed.
Reduced USER_MEMORY as much as about possible and still be able to load pye and it doesn't work. This is in plain, non-HIMEM, mode.
Went back to version of riscvp2 from Jun 4 and pye works again.
Also, seems don't need memset() at all...
Also, think I'm seeing that you added in a proper version of rdpin() and rqpin() to riscvp2, right?
That is interesting. Which git version is that? is it 927db502567525d91086e87f80459e5971b3b82f?
The biggest change was just shortly after that, at e8380089625c3e94fe23c93aabac3f0004af261d, it would be interesting if that's where it broke. Although looking at the code it should be safe (it added a second cache set for the flash). Actually that shouldn't affect the non-flash at all. Hmmm; maybe f2b392d2376a7e4116d39135a1da5eccf7c0e642 broke something, but that fixed a real bug (where the HUB memory cache could overflow while expanding).
Back in April I fixed the binary encoding for those (they were
sformats like stores, but should have beeniformats because they modify the result register). Looks like I forgot to add a definition for rqpin() to propeller2.h (it is in the JIT compiler though, just not exposed).@ersmith If you can get this run code from flash support working, think would need a uSD adapter for eval type boards.
I see they sell one: https://www.parallax.com/product/p2-microsd-add-on-board/
Some things about it that could be different, but guess that could work.
Main thing is three unused pins.
Probably would use one of those to be able to cycle power on uSD card.
Guess use other two for QUIIC (I2C) connector...
Also, some complain about series resistor, so probably remove that..
@Rayman ideally we'd get some code working that would allow sharing uSD and flash. Second best would be littlefs in flash, I guess. Not many people have the adapters.
Here's an updated loadp2 with much better flash support -- now it can program flash so that ELF files can be booted (use the
-FLASHflag). Beware though that if you program an ELF file that uses the flash for high memory and then just download & run another ELF file with highmem code, the second one will overwrite the high portion of the flash (where the code is) and prevent the bootable one from working on the next boot.It looks like the default loadp2 FIFO size was too small for Mac, causing downloads to be unreliable (thanks @"Stephen Moraco" for noticing this). Here's a version with a bigger FIFO, which seems much more stable.
I guess running unsigned binaries on newer Macs is getting harder and harder
. Here's a signed version of the tools.
Thanks for updating. I know the default used to work okay for P2-EVAL some time back but for me once the P2 Edge came out and I was using the new PropPlug I found I had to use a 8192 byte FIFO on both my Macs for more reliable uploads.
Going to attempt to move my RISCV P2 development from Ubuntu to Windows. Probably a bad idea, but I don't remember why anymore, so giving it a shot...
@ersmith I think you updated the link to xpack 13.2.0, but appears broke.
Guess going to try the one from here: https://sourceforge.net/projects/gcc-xpack/files/v13.2.0-2/
Seems a new version (14) is here: https://sourceforge.net/projects/gcc-xpack/
@ersmith Seems something wrong with latest riscvp2 files. It breaks PYE (same way that the HIMEM=flash way does), just hangs.
Did notice this new message at the end of build:
warning: build/firmware.elf has a LOAD segment with RWX permissions
Does that mean anything to you?
I don't know... I don't recall changing anything other than the HIMEM code.
Yes, it's a harmless warning that's generated by the new linker. On platforms with memory management we're not supposed to enable the W (write) and X (execute) bits at the same time, but obviously on the P2 that doesn't matter at all.
@ersmith Hmm... No other changes since June? Guess github should be able to show...
Did just post this micropython source code and the riscv folder here: https://www.rayslogic.com/Propeller2/upy/micropython.html
Actually the version that works already has HIMEM included (just doesn't work with micropython and pye for some reason).
So, must be something after that...
Did WinDiff on the files:
The riscvp2.ld file looks like it has been changed a lot. I'd guess it's something here that is the problem....
Think see the problem... With the new riscvp2, the "dec" size comes in at 508776.
I think you once said the limit is around 508kB.
Any idea why it's so much bigger now?
This is without VGA, USB, or the WiFi extras included...
Is there a way to reduce micropython free space and thereby make the dec smaller?
Is it a heap setting or something like that somewhere?
Wait a sec. Might be seeing it wrong...
Ok, binary size is about the same with working version. Must be something else...
dec was around 500kB, last I checked, need to look into that too...
Replacing asm.templ with the old version seems to have fixed the problem.
I'll double check that...
Yep, that is it. Taking the latest from github and replacing asm.templ with the old one makes pye work.
Just tried new version with memset in asm.templ renamed to memset_dont_use in two places.
This seems to work!
Was able to get Tensorflow Lite Micro to compile and generate a .bin file, but doesn't seem to work. At least, there's nothing in the terminal window..
Followed some directions from here:
https://github.com/tensorflow/tflite-micro/issues/311
And also here:
https://github.com/fabrizioaymone/riscv-tflite
Thinking it's because need to get the riscvp2.ld in there, but not exactly sure how.
Tried adding this last line to platform flags in mcu_riscv_makefile.inc, but maybe that's not right?
Also, to get it to compile, had to turn off the treat errors as warnings in the main makefile:
-march=rv64gcis definitely wrong, that's asking for a 64 bit RISC-V with double precision instructions, whereas we emulate a 32 bit integer RISC-V (-march=rv32imac-Zicsr).