Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

[Chris Johns]

On 9/6/19 4:29 pm, Vijay Kumar Banerjee wrote:
> On Sun, Jun 9, 2019 at 6:22 AM Chris Johns  > wrote:
> On 8/6/19 5:58 pm, Christian Mauderer wrote:
> > - Ursprüngliche Mail -
> >> Von: "Oyake, Amalaye (386M)"  >
> >> An: "Chris Johns" mailto:chr...@rtems.org>>, "Vijay
> Kumar Banerjee"  >, "Christian Mauderer"
> >>  >
> >> CC: "RTEMS Users" mailto:users@rtems.org>>
> >> Gesendet: Samstag, 8. Juni 2019 04:57:02
> >> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or 
> wired)
> >
> >> Device Tree overays are a method used to update the Device Tree. Given 
> a
> device
> >> tree that describes all the devices, let's say you add a new SPI 
> device, you
> >> can update the device tree with a (blob) device tree overlay.
> >>
> >> I should ask (without Googling), What is the Device Tree Overlay 
> mechanism in
> >> RTEMS?
> >
> >
> > Hello Amalaye,
> >
> > as far as I know, the device tree overlay mechanism in RTEMS is not
> implemented. There is the prototype of fdt_overlay_apply() in libfdt.h but
> there is no implementation. So there are two methods:
> >
> > 1. Applying the overlay on a build machine. Vijay did that during his 
> tests.
> 
> How do you do this?
> 
> I used `fdtoverlay` from libfdt on linux host. 

Could cpukit/dtc/libfd in RTEMS be updated to support this code? I see freebsd's
kernel has the code.

> 
> > 2. Use the U-Boot mechanism to apply overlays before booting RTEMS. That
> should most likely work too. But I didn't test it yet.
> 
> OK
> 
> >> On 6/7/19, 6:17 PM, "users on behalf of Chris Johns"
> mailto:users-boun...@rtems.org> on
> >> behalf of chr...@rtems.org > wrote:
> >>
> >>    On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
> >>    >
> >>    > I would like to add that in two projects of this year( I2C and
> PRU-ICSS drivers)
> >>    > we
> >>    > are using our own device tree overlays that make our drivers work.
> Where to add
> >>    > the device
> >>    > tree related stuff seems like an important question.
> >>   
> >>    What are device tree overlays?
> >
> > Like Oyake already said: They are some small pices of device trees that
> are just added to the base tree in it's binary form. Linux (and most 
> likely
> FreeBSD too) supports that even after boot. If you add an overlay it
> re-parses the device tree, updates GPIO settings and loads new drivers. 
> The
> alternative is to let the boot loader apply them during boot.
> 
> What is needed to do this? Maybe I can add it to rtems-boot-image as a 
> way to
> handle this at the u-boot version.
> 
> I have also tried to automate it by adding it in uEnv.txt as a script, it 
> worked
> nicely to apply
> the overlay on the blob, I haven't tested it with any app though, but the
> overlay applied
> successfully. Here's what the test uEnv.txt looks like. 
> ```
> setenv bootdelay 5
> uenvcmd=run overlay_cmd boot
> overlay_cmd=fatload mmc 0 0x8080 rtems-app.img; fatload mmc 0 0x8800
> am335x-boneblack.dtb; fatload mmc 0 0x8810 am335x-rtems.dtbo; fdt addr
> 0x8800; fdt resize 0x1000; fdt apply 0x8810;
> boot=bootm 0x8080 - 0x8800;
> ```
> 
> You can add something like this to the uEnv.txt in SD card image. In the above
> script
> the am335x-boneblack.dtb is the one from linux and am335x-rtems.dtbo is 
> generated
> with dtc from the overlay written by me.

Ah I see. I think this could be added to rtems-boot-image. There is something
attractive about building the fdt at run time on the board from the needed 
pieces.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

[Vijay Kumar Banerjee]

On Sun, Jun 9, 2019 at 6:22 AM Chris Johns  wrote:

>
>
> On 8/6/19 5:58 pm, Christian Mauderer wrote:
> > - Ursprüngliche Mail -
> >> Von: "Oyake, Amalaye (386M)" 
> >> An: "Chris Johns" , "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com>, "Christian Mauderer"
> >> 
> >> CC: "RTEMS Users" 
> >> Gesendet: Samstag, 8. Juni 2019 04:57:02
> >> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or
> wired)
> >
> >> Device Tree overays are a method used to update the Device Tree. Given
> a device
> >> tree that describes all the devices, let's say you add a new SPI
> device, you
> >> can update the device tree with a (blob) device tree overlay.
> >>
> >> I should ask (without Googling), What is the Device Tree Overlay
> mechanism in
> >> RTEMS?
> >
> >
> > Hello Amalaye,
> >
> > as far as I know, the device tree overlay mechanism in RTEMS is not
> implemented. There is the prototype of fdt_overlay_apply() in libfdt.h but
> there is no implementation. So there are two methods:
> >
> > 1. Applying the overlay on a build machine. Vijay did that during his
> tests.
>
> How do you do this?
>
> I used `fdtoverlay` from libfdt on linux host.

> > 2. Use the U-Boot mechanism to apply overlays before booting RTEMS. That
> should most likely work too. But I didn't test it yet.
>
> OK
>
> >> On 6/7/19, 6:17 PM, "users on behalf of Chris Johns" <
> users-boun...@rtems.org on
> >> behalf of chr...@rtems.org> wrote:
> >>
> >>On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
> >>>
> >>> I would like to add that in two projects of this year( I2C and
> PRU-ICSS drivers)
> >>> we
> >>> are using our own device tree overlays that make our drivers work.
> Where to add
> >>> the device
> >>> tree related stuff seems like an important question.
> >>
> >>What are device tree overlays?
> >
> > Like Oyake already said: They are some small pices of device trees that
> are just added to the base tree in it's binary form. Linux (and most likely
> FreeBSD too) supports that even after boot. If you add an overlay it
> re-parses the device tree, updates GPIO settings and loads new drivers. The
> alternative is to let the boot loader apply them during boot.
>
> What is needed to do this? Maybe I can add it to rtems-boot-image as a way
> to
> handle this at the u-boot version.
>
> I have also tried to automate it by adding it in uEnv.txt as a script, it
worked nicely to apply
the overlay on the blob, I haven't tested it with any app though, but the
overlay applied
successfully. Here's what the test uEnv.txt looks like.
```
setenv bootdelay 5
uenvcmd=run overlay_cmd boot
overlay_cmd=fatload mmc 0 0x8080 rtems-app.img; fatload mmc 0
0x8800 am335x-boneblack.dtb; fatload mmc 0 0x8810
am335x-rtems.dtbo; fdt addr 0x8800; fdt resize 0x1000; fdt apply
0x8810;
boot=bootm 0x8080 - 0x8800;
```

You can add something like this to the uEnv.txt in SD card image. In the
above script
the am335x-boneblack.dtb is the one from linux and am335x-rtems.dtbo is
generated
with dtc from the overlay written by me.

> A practical example would be adding a I2C device like a DS1338 RTC to the
> extension connector of the Beagle:
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts
>
> I see the need for this.
>
> > I suggested them for Vijays GSoC project to be able to add an I2C
> adaption layer so that libbsd uses the RTEMS i2c drivers. That's necessary
> so that RTEMS applications can still use the RTEMS i2c interface but at the
> same time the FreeBSD drivers (in that case for some chip related to HDMI)
> can use the BSD interface.
>
> OK.
>
> Chris
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: BeagleBone Black Networking (wifi and/or wired)

[Chris Johns]

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.

> 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.

> 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.

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.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

[Chris Johns]

On 8/6/19 5:58 pm, Christian Mauderer wrote:
> - Ursprüngliche Mail -
>> Von: "Oyake, Amalaye (386M)" 
>> An: "Chris Johns" , "Vijay Kumar Banerjee" 
>> , "Christian Mauderer"
>> 
>> CC: "RTEMS Users" 
>> Gesendet: Samstag, 8. Juni 2019 04:57:02
>> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)
> 
>> Device Tree overays are a method used to update the Device Tree. Given a 
>> device
>> tree that describes all the devices, let's say you add a new SPI device, you
>> can update the device tree with a (blob) device tree overlay.
>>
>> I should ask (without Googling), What is the Device Tree Overlay mechanism in
>> RTEMS?
> 
> 
> Hello Amalaye,
> 
> as far as I know, the device tree overlay mechanism in RTEMS is not 
> implemented. There is the prototype of fdt_overlay_apply() in libfdt.h but 
> there is no implementation. So there are two methods:
> 
> 1. Applying the overlay on a build machine. Vijay did that during his tests.

How do you do this?

> 2. Use the U-Boot mechanism to apply overlays before booting RTEMS. That 
> should most likely work too. But I didn't test it yet.

OK

>> On 6/7/19, 6:17 PM, "users on behalf of Chris Johns" 
>> > behalf of chr...@rtems.org> wrote:
>>
>>On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
>>> 
>>> I would like to add that in two projects of this year( I2C and PRU-ICSS 
>> drivers)
>>> we
>>> are using our own device tree overlays that make our drivers work. 
>> Where to add
>>> the device
>>> tree related stuff seems like an important question.
>>
>>What are device tree overlays?
> 
> Like Oyake already said: They are some small pices of device trees that are 
> just added to the base tree in it's binary form. Linux (and most likely 
> FreeBSD too) supports that even after boot. If you add an overlay it 
> re-parses the device tree, updates GPIO settings and loads new drivers. The 
> alternative is to let the boot loader apply them during boot.

What is needed to do this? Maybe I can add it to rtems-boot-image as a way to
handle this at the u-boot version.

> A practical example would be adding a I2C device like a DS1338 RTC to the 
> extension connector of the Beagle: 
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts

I see the need for this.

> I suggested them for Vijays GSoC project to be able to add an I2C adaption 
> layer so that libbsd uses the RTEMS i2c drivers. That's necessary so that 
> RTEMS applications can still use the RTEMS i2c interface but at the same time 
> the FreeBSD drivers (in that case for some chip related to HDMI) can use the 
> BSD interface.

OK.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: gdb-8.2.1 build failed on macos 10.11.6

[Chris Johns]

On 9/6/19 2:11 am, Juan Rafael García Blanco wrote:
> Thank you for answering.

My pleasure.

> Sorry, I think I did not make myself clear. I mean that it is not possible to 
> build the RTEMS 5 tools for SPARC in macos 10.11.6.

My understanding is you are not able to build a SPARC gdb on MacOS. We need to
figure out why. I do not see this error.

> The latest Xcode version available for 10.11.6 includes LLVM 7.3.0, which 
> cannot build gdb. 

The Macbook Pro I am writing this email on and use with RTEMS has:

huia:rtems chris$ uname -a
Darwin huia 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019;
root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64
huia:rtems chris$ cc -v
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

> It fails with the error in the previous email.

I do not see the error. I have uploaded the full build log to:

https://ftp.rtems.org/pub/rtems/people/chrisj/rsb/builds/arm-powerpc-sparc.txt.xz

Please download it and take a close look at the file you are seeing fail to see
what the compiler command line is and how it compares to yours.

> For successfully building the toolset it is required to manually modify 
> darwin.py, I think, because I did not find any other way to override the path 
> to the C/C++ compiler.

What compiler have you installed?
Where did the package come from?

It is important I understand if there are any other packages installed. These
packages can effect things.

> Thus, at least for macos 10.11.6 with latest Xcode available for that 
> version, i.e., LLVM 7.3.0, it would be necessary to install another C/C++ 
> compiler to properly build gdb.

I do not agree this is the case. I have a successfully built tool chain and I am
using it on a regular basis.

> I do not know if there is many people using macos 10.11.6 these days,

I am and have been since 2011. I have a Mac Mini which is used to build the
tools on a regular based to check we are ok. I have a MacBook I am using on a
regular based to work on the Beaglebone Black BSP. I have been building and
working through testing of that BSP. I have raised a number of bug reports with
Apple over the years and they have been responsive fixing them.

I do not install and any packages from Macport and Homebrew.

> so maybe it is just enough to have these messages posted in the mailing list 
> so that someone looking for help with this error can find some related info. 
> Or maybe it would be a good idea to place this info in a known issues wiki or 
> something.

Please do not do this. Your build issue has not yet been resolved.
> Hope it is clear now :)

No it is not clear. :)

If you could please let me know what packages from Macports (assuming you have)
that are installed, it would help. I would like to understand what is happening
and to help fix your build issue.

There are packages that can effect how gdb is built. This can happen if the
configure process in gdb sees a library it may decide to use and termcap and
related libs can cause issues. These interactions can be tricky and what happens
may not be obvious.

Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: gdb-8.2.1 build failed on macos 10.11.6

[Juan Rafael García Blanco]

Thank you for answering.

Sorry, I think I did not make myself clear. I mean that it is not possible to 
build the RTEMS 5 tools for SPARC in macos 10.11.6. The latest Xcode version 
available for 10.11.6 includes LLVM 7.3.0, which cannot build gdb. It fails 
with the error in the previous email. For successfully building the toolset it 
is required to manually modify darwin.py, I think, because I did not find any 
other way to override the path to the C/C++ compiler.

Thus, at least for macos 10.11.6 with latest Xcode available for that version, 
i.e., LLVM 7.3.0, it would be necessary to install another C/C++ compiler to 
properly build gdb.

I do not know if there is many people using macos 10.11.6 these days, so maybe 
it is just enough to have these messages posted in the mailing list so that 
someone looking for help with this error can find some related info. Or maybe 
it would be a good idea to place this info in a known issues wiki or something.

Hope it is clear now :)

Thank you,
Juan.

> On 22 Apr 2019, at 04:16, Chris Johns  wrote:
> 
> On 20/4/19 3:58 am, Juan Rafael García Blanco wrote:
>> Hi,
>> 
>> I have found an error while trying to build the RTEMS 5 toolset with RSB. 
>> The build process stops during compilation of gdb with the following error 
>> message:
>> 
>> ../../gdb-8.2.1/gdb/tui/tui-hooks.c:208:36: error: default initialization of 
>> an object of const type 'const gdb::observers::token' without a 
>> user-provided default constructor
>> static const gdb::observers::token tui_observers_token;
>>   ^
>>  {}
>> 1 error generated.
> 
> I have just built am ARM tool chain for RTEMS 5 using the RSB master on the
> latest MacOS (10.14.4 (18E226)) with the latest Xcode (Version 10.2.1
> (10E1001)). I did not see an error. I am currently building a sparc tool chain
> and gdb has built without error.
> 
> My machine is only MacOS and Xcode.
> 
>> The selected compiler is /usr/bin/cc (BTW, I have not found a way to tell 
>> RSB to use a different host compiler), 
> 
> You can customise what happens for Macos here:
> 
> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/darwin.py
> 
> I am assuming you have some Macport packages installed because you have
> referenced a Macport ticket. Is this true?
> 
>> which in my case is:
>> 
>> Apple LLVM version 8.0.0 (clang-800.0.42.1)
>> Target: x86_64-apple-darwin15.6.0
>> 
>> I think this same problem has also been found in the macports project [0].
>> 
>> I see the __cc variable is overridden for darwin hosts version 13 and above. 
>> I’m running darwin 15.6.0, which apparently supports Xcode 8.2.1. This 
>> version includes both /usr/bin/cc, which is a link to /usr/bin/clang; and 
>> /usr/bin/gcc. 
> 
> This is what I have.
> 
>> They might have been installed as part of the so-called Xcode’s command line 
>> tools… 
> 
> They should be.
> 
>> In any case, both cc and gcc seem to be based on LLVM 8; thus, I think we 
>> can say there is no compiler suitable for building gdb in Xcode 8.2.1, which 
>> is the latest version available for darwin 15.6.0.
> 
> I have:
> 
> $ which cc
> /usr/bin/cc
> $ cc --version
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.5.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> $ ls -las /usr/bin/cc
> 0 lrwxr-xr-x  1 root  wheel  5 27 Sep  2018 /usr/bin/cc -> clang
> mohua:rtems chris$ ls -las /usr/bin/gcc
> 16 -rwxr-xr-x  1 root  wheel  18288 21 Mar 17:08 /usr/bin/gcc
> $ /usr/bin/gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
> Apple LLVM version 10.0.1 (clang-1001.0.46.4)
> Target: x86_64-apple-darwin18.5.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> These are the Xcode tools.
> 
>> I’m willing to help fixing this, but I do not know what would be the proper 
>> way to handle this. I guess RSB should warn the user and require GCC or 
>> another version of LLVM.
> 
> If there is a Macports package installed a library maybe changing how gdb is
> built and as a result it exposes some code that needs to be fixed?
> 
> My configure command line for gdb is:
> 
> ../gdb-8.2.1/configure --build=x86_64-apple-darwin18.5.0
> --host=x86_64-apple-darwin18.5.0 --target=arm-rtems5 --verbose --disable-nls
> --disable-gas --disable-binutils --disable-ld --disable-gold --disable-gprof
> --without-included-gettext --disable-win32-registry --disable-werror
> --enable-sim --without-zlib --with-expat --with-guile=no
> --with-python=/usr/bin/python --prefix=/opt/work/rtems/5
> --bindir=/opt/work/rtems/5/bin --exec-prefix=/opt/work/rtems/5
> --includedir=/

Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

[Christian Mauderer]

- Ursprüngliche Mail -
> Von: "Oyake, Amalaye (386M)" 
> An: "Chris Johns" , "Vijay Kumar Banerjee" 
> , "Christian Mauderer"
> 
> CC: "RTEMS Users" 
> Gesendet: Samstag, 8. Juni 2019 04:57:02
> Betreff: Re: [EXTERNAL] Re: BeagleBone Black Networking (wifi and/or wired)

> Device Tree overays are a method used to update the Device Tree. Given a 
> device
> tree that describes all the devices, let's say you add a new SPI device, you
> can update the device tree with a (blob) device tree overlay.
> 
> I should ask (without Googling), What is the Device Tree Overlay mechanism in
> RTEMS?


Hello Amalaye,

as far as I know, the device tree overlay mechanism in RTEMS is not 
implemented. There is the prototype of fdt_overlay_apply() in libfdt.h but 
there is no implementation. So there are two methods:

1. Applying the overlay on a build machine. Vijay did that during his tests.

2. Use the U-Boot mechanism to apply overlays before booting RTEMS. That should 
most likely work too. But I didn't test it yet.


> 
> Regards,
> --
> * Amalaye Oyake, NASA / Jet Propulsion Laboratory.  */\  *
> * Jet Propulsion Laboratory, Pasadena   *||  *
> * CA/||\ *
> *^^***
> 
> 
>On 6/7/19, 6:17 PM, "users on behalf of Chris Johns" on
>behalf of chr...@rtems.org> wrote:
> 
>On 8/6/19 1:53 am, Vijay Kumar Banerjee wrote:
>> 
>> I would like to add that in two projects of this year( I2C and PRU-ICSS 
> drivers)
>> we
>> are using our own device tree overlays that make our drivers work. Where 
> to add
>> the device
>> tree related stuff seems like an important question.
>
>What are device tree overlays?

Like Oyake already said: They are some small pices of device trees that are 
just added to the base tree in it's binary form. Linux (and most likely FreeBSD 
too) supports that even after boot. If you add an overlay it re-parses the 
device tree, updates GPIO settings and loads new drivers. The alternative is to 
let the boot loader apply them during boot.

A practical example would be adding a I2C device like a DS1338 RTC to the 
extension connector of the Beagle: 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-I2C2-RTC-DS1338.dts

I suggested them for Vijays GSoC project to be able to add an I2C adaption 
layer so that libbsd uses the RTEMS i2c drivers. That's necessary so that RTEMS 
applications can still use the RTEMS i2c interface but at the same time the 
FreeBSD drivers (in that case for some chip related to HDMI) can use the BSD 
interface.

Best regards

Christian

>
>Chris

-- 

embedded brains GmbH
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