BeagleBone Black Networking (wifi and/or wired)

Tue Jun 11 08:19:21 UTC 2019

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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at 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.