BeagleBone Black Networking (wifi and/or wired)

[Chris Johns]

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.

> 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