Hi Robert, This is an amazing news! Thank you for doing it and for willing to include it on NuttX mainling.
Normally only common code on NuttX needs to follow the C89 standard because some microcontrollers don't have newer compiler. So, that said, inside arch/ and boards/ you are king, you can use any new feature supported by your CPU's compiler. You just need to follow to Coding Style and respect the INVIOLABLES.md Also should use tools/checkpatch.sh to check your patch/files before submitting the PR. BR, Alan On 6/14/21, Robert Lipe <robertl...@gmail.com> wrote: > 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... >
