RP2040 Runs Linux Through RISC-V Emulation
hackaday.com
hackaday.com
It uses 230 1k entries for the cache, https://github.com/tvlad1234/pico-rv32ima/blob/main/pico-rv3...
It looks like it also writes 1k during each block flush. This will definitely put some pressure on the wear leveling algo on the sdcard. :) I am a big fan of this sdcard hack, I wonder what the illogical conclusion is? SDMD RAID?
While it might not make it faster, adding 64Mbit of PSRAM to the other SPI port would make the sdcard live longer.
https://www.sramsun.com/list-354-1.html https://www.issi.com/us/product-cellular-ram.shtml
The Dmitry comments here, https://hackaday.com/2023/03/19/rp2040-runs-linux-through-ri... and has much better boot numbers for a later project.
https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi...
Previous discussions https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
MDRAID was AFAIK originally developed and tested using floppy drives, as the developer at the time couldn't afford a PC beefy enough to have multiple hard disks. RAID from SD cards would be the closest modern equivalent to a return to the project's roots.
(And (µ)SD RAID has been done many times for hobby projects, it gives you stupid data densities on a tiny power/volume budget… at least until the cards start dying from all the abuse. C'est la vie.)
Here’s one with 13 USB floppy drives
https://github.com/tvlad1234/pico-rv32ima/blob/main/pico-rv3...
Almost 3x, without cooling...!
It means they probably tried to do too little in each clock cycle. Some multi-cycle operations could have been made single cycle...
Or, they designed the part for one silicon process, but ended up changing path and manufacturing on a different one late in the design process.
Either way, the outcome is the users will be paying more per part than they needed to.
Clock signals on big motherboards are great RF radiators and hard to shield. But on a SoC, they aren't much of an issue.
There are very few embedded applications where you need more computation power than a RP2040 can offer without being limited by RAM or flash. Sure, they could have tried pushing it even harder, but why bother when it is already enough?
To be fair to them, I think it was a fairly inexperienced design team making their first silicon, in relatively low volumes (10's of millions). They weren't an established player trying to make a 1 billion+ production run super competitive product where fractions of a cent matter.
Anything over 200mhz and the SPI flash doesn't work anymore either. It can be pretty hard to fit all working memory and code into the 256KB.
The chip was designed to replace Arduino boards, many of which run below 50mhz, and only process 8bits at a time. 133mhz, 32bit dual core is a sizable jump in performance already.
https://github.com/pimoroni/picosystem (see the note next to the no_overclock compile flag)
https://www.trustedparts.com/en/part/winbond/W25Q16JVSSIQ%20...
The flash chip they are using is only rated to 133mhz, so they are setting the SPI clock divider.
in hardware.cpp
#ifndef NO_OVERCLOCK
// dividing the clock by two ensures we keep the spi transfer to
// around 62.5mhz as per the st7789 datasheet when overclocking
sm_config_set_clkdiv_int_frac(&c, 2, 1);
#endif