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. Initial steps in this direction would make a good GSoC for the right (strong) student. Gedare > > > > Just a thought.. I'm still catching up! > > Thanks, > > Alan > > > > On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar <a...@rtems.org> wrote: > >> > >> On 2020-02-27 20:06 +0100, Christian Mauderer wrote: > >> > >>>> The only good way to handle this is to have it all in 1 giant repository > >>>> we work > >>>> with. Every other solution is a pain no matter how well thought out it > >>>> is. I > >>>> personally lean more on the service side of things that it should be > >>>> *our* > >>>> problem to maintain this and for users it should just work.> > >>>> The easiest way to handle this is to have the minimum version required > >>>> in the > >>>> commit message. Eg, when pushing to libbsd have: > >>>> > >>>> Minimum RTEMS: <hash> > >>>> > >>>> After that it's up to the user to ensure to keep up-to-date. The first > >>>> thing > >>>> most developers do is check the log. > >>> > >>> Sounds like a nice suggestion. But it needs quite a lot of discipline > >>> for the developers. So most likely a lot of errors will happen. Beneath > >>> that it's not far from what we do now: Suggest to use commits from the > >>> same date. > >> > >> There are two ways to look at it -- requiring discipline or simply doing > >> something we should already be doing. Because right now there is no way > >> to tell > >> other than updating to the latest and if you are trying to bisect an issue > >> this > >> because huge because you could feasibly jump into a comment that skips a > >> version. How would a user know which version of the library *or* RTEMS to > >> use? > >> > >> > >>> But maybe we should move that discussion. It's not FDT related anymore > >>> so no one will find it in this toppic. And I think for Chris the > >>> pressing matter is FDT just now because it blocks the release. > >> > >> Yes that's true. > >> > >>> The BSP groups that use bsps/shared/start/bsp-fdt.c are: > >>> > >>> - riscv/riscv > >>> - arm/imx > >>> - arm/beagle > >>> - arm/raspberrypi > >>> - arm/altera-cyclone-v > >>> - powerpc/qoriq > >>> > >>> For beagle and raspberry it should be definitely the FreeBSD FDT. > >>> > >>> For imx: I'm currently working on imx6 support in the imx BSP and that > >>> one will use a FreeBSD derived one too. Not sure about the original imx7 > >>> support in that BSP. > >>> > >>> For the other BSPs I don't have any idea which FDT has been used during > >>> development. > >> > >> > >> Okay that list is already compelling enough to have the split model of > >> having > >> source based files in-tree and binary outside. I think it makes sense to > >> have > >> it 'just work' for opensource boards like the beagle and rpi even if > >> that's the > >> only two that require it. > >> > >> > >> Amar. > >> _______________________________________________ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
