On 11/06/2019 01:27, Chris Johns wrote: > On 9/6/19 6:00 pm, Christian Mauderer wrote: >> On 09/06/2019 04:24, Chris Johns wrote: >>> On 8/6/19 1:45 am, Christian Mauderer wrote: >>>> Note that basically all device tree files that I have found yet are forked >>>> from the Linux ones. >>> >>> Yes, I understand this is the case. >>> >>>> They are all GPL. >>> >>> We need to work with these files and respect the license they are under. I >>> think >>> GPL DTS is OK if these files are not linked into an executable. I am not >>> sure >>> where you stand in relation to the GPL license if you link a GPL dtb into an >>> executable. An overlay we create under a suitable license should be fine. >> >> Normally the DTB isn't linked in but loaded by some bootloader from a >> file system so I agree that it shouldn't affect the license of the blob. >> >>> >>>> I think it was Sichen Zhao during 2017 GSoC who wanted to add some to the >>>> RTEMS repository and it has been rejected due to the license. >>> >>> I remember and I still think the position discussed is fine. >>> >>>> I don't really object to adding them somewhere. >>> >>> What do we host and maintain? Do we need to host any of these files or >>> should we >>> have a tool to collect and/or generate the blobs we need. >> >> Most likely for most device trees it would be best to just refer to some >> external source. For example the Linux tree or the one in FreeBSD (which >> is a fork of the one from Linux) or some extracted tree. >> >> We maybe have some exceptions with custom dts files or we can provide >> some small overlays in case we need something special. > > Yes I think this is the best approach. > >> >>> >>>> But we should think exactly about where we want that stuff. >>> >>> Having a blob as a file in a system theoretically lets someone update it. >>> The >>> `dtc` compiler can generate the dts source from a blob so a user can >>> recover the >>> source, make a change, generate a blob, then return it back into a system if >>> they wish too. >> >> Yes and if it is compiled with -@ option of the dtc it can even be >> extended with overlays. But due to the GPL we should also provide a >> matching source archive if we provide binaries. > > Of course. If the RSB builds a DTB we will have downloaded and made available > the source for the user to manage. They also know it is valid. > >>> >>> What about building the FDT blobs we need with the RSB? I know this will >>> work on >>> FreeBSD and I suspect Linux, MacOS has some issues with clang's cpp. >> >> I think there are more and more BSPs that can use the FDT (especially >> ones that use libbsd) so it would be a good thing if they can be build >> by RSB. > > I agree however we have some rough edges we need to document and/or clean up. > > For example running libbsd with a beaglebone booted without a device tree > crashes with a NULL pointer access when libbsd checks the magic value in the > DTB > header (I could not quickly find how libbsd is passed the DTB pointer from the > BSP). If you provide a DTB but use `mkimage` with the RTEMS output format (`-O > rtems`) libbsd crashes because the RTEMS format image loading in u-boot does > not > handle device trees. We need to use the Linux format which is not an obvious > thing to do. As a result you need to have a very precise set up or you get a > low > level crash. >
I'm not entirely sure but I think that the Linux format should be the default now. I think the RTEMS format is more or less a legacy one. I did a grep in the rtems-docs and all three mkimage calls show a "-O linux". >> But please also note that we shouldn't see RSB as the only source for >> DTBs. > > Agreed, it is a way for us to capture and provide all the source in a board. > >> It's not uncommon that there is already a DTB on a board that is >> just used by our BSP. > > Yes and this is also a weakness because I fele not enough people build or > check > the source is what they have as a binary image and it is being maintained. > > For example with an upstream master u-boot a beaglebone built with the latest > RTEMS compiler does not work, the SD card access is suspect so I wonder if > something low level has been optimized differently. Using a gcc 6 something > works. Building a Zynq gives you a warning that the board will be removed from > u-boot in April or May this year unless something in the config is fixed. > Xilinx > maintains github repos for u-boot and points users to them. Finally I cannot > find any PicoZed support upstream or in the Xilinx repos however Petalinux > support is provided for the board. I cannot see how the 1G of RAM on a PicoZed > can be initialised without low level support in the first stage loader. > > If we can help by placing some focus on parts that need some effort then I > think > that is a good thing. > >> Either because it's some evaluation board with a >> matching one programmed somewhere and loaded by the original U-Boot or >> for some FPGA based BSPs the DTB can be generated by the FPGA tools. > > Using FDT to support FPGA development is something I do and it is really good. > > Chris > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
