Sorry about delay in getting back to this. I have been focused on getting the release into something close to what we want for RC1.
On 28/2/20 9:48 pm, Christian Mauderer wrote: > Hello Gedare and Chris, > > On 27/02/2020 23:14, 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. > > I think for Boards that normally run a Linux it is a sane approach to > just replace the Linux Kernel with a RTEMS binary and otherwise keep the > boot process with for example U-Boot. Everything else is a lot of extra > effort to implement and not necessary in a lot of situations. Is there documentation about that shows this process for an existing board? I get what you are saying and it make prefect sense and it would be no issue for me to do this however there are a number of steps involved and there is a certain amount of assumed knowledge here. How do we establish a framework or template that lets are capture this so it is useful and usable to our users? > >>> >>> 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. >>> > > One BSP where it is a disadvantage to statically link is Raspberry Pi. > With the recent work you currently can use the same binary for RPi2 and > 3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W. Great example and a good point. > I'm not against the possibility to link the FDT. But we should be open > to use both methods. OK >>> 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. > > Note the licensing issues if you use FreeBSD or Linux FDTs: They are > GPL. If you statically link them you will infect other code too. Ouch, that is a blocker to linking to the image. In light of this maybe any effort to link it is not worth it. I wonder what you do with a board that needs an FDT but has no media to hold one? > Although for BSPs where no FDT exists it might is a good idea to write > your own FDT and license it with a RTEMS compatible license. For BSPs > like BBB it's not a good idea if you ask me. It's a lot of work. Yes I agree. >>> 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. > > Again: It opens licensing issues for our users! > Understood. I had not considered this before now. >>> >>> 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. > > If Chris sees it as a blocker for the release, GSoC might is not the > right frame. It would need too much time and the result is not > guaranteed to be OK. The concern I have is how you take an experienced user and given then just .... https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2003/ ... then ask them to run an exe on a BBB or RPi to run? > Maybe we should add an intermediate solution and create a GSoC project > for improvement? It leaves RTEMS 5 with a gap. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel