> > 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? > > Yes, we have an issue to merge 64bit and 32bit common arch code here: https://github.com/apache/incubator-nuttx/issues/2593 And even a draft PR: https://github.com/apache/incubator-nuttx/pull/2822
> 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. > > We have an issue track device tree here: https://github.com/apache/incubator-nuttx/issues/1020 Even a GSoC proposal: https://docs.google.com/document/d/1yVnF_oATKEnfOvMbk6fCNmJqfjlyGmNtvntLycsMDA0/edit
