Hi. I've been part of open source since the 80's, including at the development tools and OS levels, but I'm new to Nuttx. My hobby of late has centered around the RISC-V SoCs and I see that Nuttx has good coverage on the large microcontroller class devices like BL602 and K210 and is just now getting more representative RV64GC hardware.
The good news is I come bearing gifts. I have one of the prerelease BeagleV Starlight boards that features the Startech Five JH7100 core that I'm using for live development. I have it booting NuttX and running threaded prime numbers <https://twitter.com/robertlipe/status/1401822687517892610>. I plan to finish cleaning up the port and submitting it in the next few days. It cribs a lot from the C906 work. Hand-waving some, it looks like the new MPFS port is also similar at a block-diagram level. There is a lot more I'd like to land, such as networking, GPIO, a video driver someday (The 7110 later this year will have a GPU; 7100 does not.) and SMP. Here again, 7110 will have 4 cores at 1.5Ghz; 7100 has a mere two cores at 1Ghz. USB and SMP are also good areas to explore. I'd hope to make rapid progress on these by "just" enabling base infrastructure, but partnering with an experienced hand on all of this would be welcome. I'm also quite willing/happy to get it to some base level of functionality and then moving to another SoC and/or OS to spread the love. *What acceptance criteria do you have to start landing patches? *I'm familiar with the Nuttx Porting Guide (it was helpful!) but *do you have suggested ordering and test cases/suites* for bringing up PROTECTED, bootstrapping a filesystem, SMP, and other configurations that require substantial configuration and, likely, code help? There is at least one more RISC-V part of this basic class (breadboard/Mini-ITX class systems that could be a desktop on par with a Pi 3 or so) that's similar that we should see this year. It's raining RISC-V <https://www.robertlipe.com/a-wealth-of-upcoming-risc-v-options/>! At the low end the ESP32-C3 should probably look a lot like BL602 or ESP8266 class devices and we expect BL702/704 to start landing in developer hardware soon-ish. To do most of that work well, this class of RISC-V cores really needs DeviceTree. I see that an implementation was started over a year ago and coasted to a halt, seemingly due to internal resistance. There's a LOT of duplication within arch/risc-v and where there is divergence, it's not always clear it's intentional or if it's just missed merges. It's an area where weak symbols (don't call a function if it wasn't linked....) and C++ virtual overrides could really clean things up. I get you don't want that "new" 90's style of programming for the 8051 port, but inside arch/risc-v would it still be forbidden to try to refactor away that forest of #ifdefs and Make.conf trickery away with more common code? Lots of that #define TIMER0BASE style of code can be discovered from DeviceTree. Zephyr <https://docs.zephyrproject.org/1.14.0/guides/dts/index.html> is one of many OSes using Device Tree. Linux and FreeBSD are also using it. Having CONFIG_SMP_NCPUS as a compile-time constant doesn't even work for the two known BeagleV Starlight boards. *Is there a library we can use with a suitable license* so that we're not starting from scratch (not a great use of volunteer resources) and move a DeviceTree implementation forward? (I'm not an expert on DT; I just want to NOT implement #defines and KCofnig files for all this new hardware.). Honestly, I won't put up a huge fight on this one and I won't carry a cross far for it. If you like your #defines, you can keep your #defines. :-) I can copy/edit/save pretty fast and maybe your users know precisely what hardware they're deploying to. At the very least, let's proceed to* land the core BeagleV Starlight JH-7100 *(with prep for 7110) patches as appropriate. Thanx and good to "meet" everyone! RJL P.S. Late in the day, especially, I ramble. Sorry. I've tried to cherry-pick to bold...
