On 28/2/20 9:14 am, Gedare Bloom wrote: > On Thu, Feb 27, 2020 at 3:01 PM Chris Johns <chr...@rtems.org> wrote: >> >> On 28/2/20 7:23 am, Alan Cudmore wrote: >>> I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a >>> device tree based initialization for all of its BSPs. >>> For example, here is the top level device tree source for the Adafruit >>> Trinket M0, which is a very small Atmel Cortex M0 based board: >>> https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts >>> >>> The rest of the device tree source for common processors and devices are >>> here: >>> https://github.com/zephyrproject-rtos/zephyr/tree/master/dts >>> >>> To me, it looks like they have to develop (or port) and maintain >>> device trees for each board and device that is supported. >>> >>> Does that look like a model that RTEMS could use? I'm not sure I >>> understand everything that deploying such a model implies, or if it >>> just makes more sense to use the existing FreeBSD or linux device >>> trees. >> >> This is where I was heading in my thinking but I am not sure. I am settling >> on >> having a dts tree in rtems.git and we may just have to manually manage the >> files. I am not sure there are enough files to warrant a system like libbsd >> and >> FreeBSD at this point in time. That may change with the new build system and >> python being available however until then manual is fine. Let me explain ... >> >> I have been looking beyond the internal development aspects and to how we use >> FDT blobs and I am wondering if the approach we have with the shared FDT BSP >> support is the right fit for RTEMS and a statically linked executable. >> >> I believe currently we need a suitable bootloader, ie u-boot, to load a blob. >> This is the Linux way of doing things and this may be the right approach for >> Linux but I am not so sure it is for us. It means you need u-boot and a >> suitable >> file system plus you have a lot more items to configuration manage in >> production >> systems and a lot more complexity for self upgrading. >> >> Why do we have a bootloader load the FDT files when we statically link >> everything else? >> >> Why not link them into the executable and register them? It s easy to do. >> >> The flow on from doing this has some real advantages. FDT files that are >> linked >> into an executable can then live in the rtems.git repo. If you move branches >> when testing or in production you do not need to manage and match suitable >> FDT >> blobs. >> >> I am not advocating this is the only solution. I can see for some BSPs this >> will >> not work and u-boot loading is the only or best solution. I however believe >> for >> DTS that is open and available we should avoid the whole mess of needing to >> build and manage them on boot media separately to the executable. >> >> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit >> our >> users and simply linking the blobs into the executable would solve this. >> >> I am confronted by this now. I have a BBB with FDT blobs for libbsd master >> and >> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my >> test >> set up open, pop the SD card and then update it. This seems unnecessary and >> avoidable to me. >> >> This also looks like a blocker for CI testing. >> >> Chris >> > Hi Chris, > > I'm 100% with you. I will also go a step further and advocate that > source-based DTS -> dtc -> FDT in static images seems beneficial to > users. I don't know if we could get any input from users to justify > that, but I can see advantages for pre-qual and license compliance > that go beyond the technical advantages that you discuss above.
Thanks and yes what I raised was a small part of the problem space. > Initial steps in this direction would make a good GSoC for the right > (strong) student. This is a good idea. I am not sure how much work is needed or how to define the work. I think the RTEMS side of things should not be hard but I am not sure about the interface to libbsd and what is required here. I would help mentor this project if is suitable for GSoC. If this goes ahead we can start to populate a dts tree in RTEMS and that would mean a release could be made. One issue this raises is the libbds master vs 5-freebsd-12 branch. I am not sure what happens here and which dts is placed in the rtems.git repo. Maybe placing 5-freebsd-12 dts in rtems.git is done up to the release of RTEMS 5 then we update rtems.git master to match libbsd's master? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel