@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.
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.