Beaglebone help needed

Thu Mar 7 06:18:47 UTC 2019

Am 06.03.19 um 21:17 schrieb Sarvesh Patkar:
> Thank you for the responses!
> 
> Chris,
> 
> I was using Ben's repository and not git.rtems.org
> <http://git.rtems.org>. I will test it with
> https://git.rtems.org/rtems-source-builder/ some time later today to see
> if it works.
> 
> 
> Christian, 
> 
> I didn't know the documentation is outdated. 

Like I said: I have to update it some when.

> 
> I would like to understand what part of Beaglebone black BSP has not
> been implemented. The list on the ticket mentioned
> 
> PRU - programmable realtime units, interesting realtime applications
> I2C
> ADC
> Framebuffer
> USB
> Ethernet
> GPIO
> CAN
> MMC (internal flash & sdcard)   

>From the list on the bottom of the ticket, the following are still open:

    PRU - programmable realtime units, interesting realtime applications
    ADC
    Framebuffer
    GPIO
    CAN
    USB OTG (like CDC ethernet or CDC mass storage - not sure about the
original beagle board but would be great on the beagle bone black)

Note that already at least one other student is planning a BBB project.
Of course you can apply to the same. But be aware that we won't have two
projects with the same target. If you are working on different parts of
BBB, that's OK.

What I told the other student:

- The Framebuffer could be a decent package. (He asked about that on the
mailing list already.)

- I have no idea what to do with the PRUs. So if you are interested in
them, try to bring some ideas.

- All other packages are most likely quite small. But a combination of
these could be a package too.

- If you want to add some other Beagle variant, we would have to have a
look at how much work to expect and if it is enough for a project.

> 
> From the repository https://git.rtems.org/rtems/tree/bsps/arm/beagle, it
> seems the i2c, spi, uart, gpio, pwm are implemented. I am not sure if I
> am looking at the right place. So, it would be great if you could let me
> know, where to look, to understand the BSP better.
> 
> I understand why we don't need the tools to build the application. I
> will try your way with the scripts from the Gitlab repository and try to
> build a sample application. 

You don't have to use the scripts. But of course you can. Basically the
scripts just call RSB and the commands for building RTEMS and libbsd,
build the same tools that originally have been build by Bens RSB branch,
build a U-Boot and generate a SD-Card image that works without a U-Boot
on the board too. So much more than the minimum requirement.

> 
> You mentioned a Wifi example, but there is an ethernet chip on board and
> no Wifi chip. Is there a reason why an external Wifi chip is used and
> not the ethernet chip? Also, are all networking applications for RTEMS
> going to use the rtems-libbsd going forward? 

Some parts of WiFi have been a GSoC project that I mentored in 2017.
Therefore I needed a test platform. The student back then added (benath
some other stuff) wpa_supplicant and a driver for a RTL8188 based stick.

The WiFi sample has grown to a more universal one. Since Christmas it
includes Ethernet too.

Best regards

Christian

> 
> Thank you for the help.
> 
> Regards,
> Sarvesh
> 
> On Wed, Mar 6, 2019 at 8:52 AM Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>> wrote:
> 
>     Am 06.03.19 um 12:11 schrieb Chris Johns:
>     > On 6/3/19 6:07 pm, Sarvesh Patkar wrote:
>     >> Hey everyone,
>     >>
>     >> I went through the quick start guide and could build the Hello
>     World for the
>     >> sparc/erc32 target.
>     >>
>     >> I would like to contribute to RTEMS in adding functionality and
>     maybe, writing
>     >> BSPs for some development boards that I have. I started with
>     Beaglebone Black.
>     >
>     > Welcome and this sounds great.
> 
>     Note that the Beagle Bone Black is already quite well supported (except
>     for the outdated documentation). Of course there is always room to
>     improvement.
> 
>     >
>     >> There are a few questions that I have as follows.
>     >>
>     >>  1. There is a build set called beagle.bset that is defined in
>     Ben Gras's Github
>     >>     repository
>     (https://github.com/bengras/rtems-source-builder/tree/beagle),
>     >>     that hasn't been merged into the main rtems-source-builder
>     git repository.
>     >>     Is there a way to know if that will happen?
>     >
>     > It could be if it is updated so it can be merged to master.
> 
>     The build set compiles some additional tools and libraries. The tools
>     are useful but not necessary to create bootable images. Most likely Ben
>     used the libraries for some project.
> 
>     Please note that I write the following without detailed tests from some
>     notes / scripts. So there might could be typos or some problems with the
>     order.
> 
>     For a BBB with an up to date U-Boot (newer than about 2017) on your
>     Beagle you don't have to use these tools. The U-Boot that is provided by
>     the official BBB images now looks for a uEnv.txt on your SD and executes
>     that if it is available.
> 
>     You can build the toolchain and system the normal way like any other
>     RTEMS tool chain (like you did for erc32) from master. Beneath that you
>     need a mkimage from U-Boot. Any recent version should do. As soon as you
>     have your executable you need the following steps:
> 
>     ----
>     arm-rtems5-objcopy app.exe -O binary app.bin
> 
>     gzip -9 app.bin
> 
>     mkimage -A arm -O linux -T kernel -a 0x80000000 -e 0x80000000 -n RTEMS
>     -d app.bin.gz rtems-app.img
>     ----
> 
>     You can then copy the rtems-app.img to the root directory of a
>     FAT-formatted SD card. Put a uEnv.txt with the following content beneath
>     it (the line with boot=... and the following are one - my mail client
>     just breaks it):
> 
>     ----
>     setenv bootdelay 5
>     uenvcmd=run boot
>     boot=fatload mmc 0 0x80800000 rtems-app.img ; fatload mmc 0 0x88000000
>     am335x-boneblack.dtb ; bootm 0x80800000 - 0x88000000
>     ----
> 
>     The last file that you need is a device tree file
>     (am335x-boneblack.dtb). The simplest way to get that is to copy it from
>     a Linux or FreeBSD image for the BBB. Copy it together with the other
>     files to the root of the disk.
> 
>     A disk that is prepared in that way should boot the RTEMS application if
>     you put it in your BBB.
> 
>     Like I said: I mostly wrote that down from head / scripts. I should
>     update the README of the Beagle BSP sometimes but I haven't managed to
>     bring myself to do it yet.
> 
>     In the last two years, I have used some hacked together scripts to build
>     a development environment that I used to test GSoC code. Basically it
>     builds the same tools that Bens repo would build. It isn't integrated as
>     nicely into RSB but it worked for me. The repo isn't totally up to date
>     (last updated to RTEMS master on last Chrismas) but it should still
>     work. If it helps you, you can find the scripts here:
> 
>         https://gitlab.com/c-mauderer/rtems-bbb
> 
>     There is also a WiFi-Sample application in the repo that uses quite a
>     lot of the hardware.
> 
>     Best regards
> 
>     Christian
> 
>     >
>     >>  2. The instructions given in the blog link mentioned on the
>     >>     ticket https://devel.rtems.org/ticket/2891 do not seem to
>     work because the
>     >>     link for fetching the mpc library is broken/wrong. (I
>     corrected the link
>     >>     locally and the sb-set-builder seems to go beyond that error)
>     I think this
>     >>     change was made already in all branches in the official
>     repository but not
>     >>     Ben's. I see another error while running sb-set-builder
>     during compilation
>     >>     of ubsan.c (gcc-6.3.0) as follows. Is there a patch for this
>     that I can
>     >>     apply to fix my local clone of the rsb ?
>     >
>     > Are you using the master version of the RSB from git.rtems.org
>     <http://git.rtems.org>?
>     >
>     > Chris
>     >
>     >>
>     >> ../../gcc-6.3.0/gcc/ubsan.c: In function 'bool
>     ubsan_use_new_style_p(location_t)':
>     >> ../../gcc-6.3.0/gcc/ubsan.c:1474:23: error: ISO C++ forbids
>     comparison between
>     >> pointer and integer [-fpermissive]
>     >>        || xloc.file == '\0' || xloc.file[0] == '\xff'
>     >>
>     >> Any help in this matter is highly appreciated. If not the
>     Beaglebone black, I
>     >> have some ARM Cortex-M boards that I would like to work towards.
>     >>
>     >> Thank you for the help.
>     >>
>     >> Regards,
>     >> Sarvesh
>     >>
>     >> _______________________________________________
>     >> users mailing list
>     >> users at rtems.org <mailto:users at rtems.org>
>     >> http://lists.rtems.org/mailman/listinfo/users
>     >>
>     > _______________________________________________
>     > users mailing list
>     > users at rtems.org <mailto:users at rtems.org>
>     > http://lists.rtems.org/mailman/listinfo/users
>     >
> 
> 
> _______________________________________________
> 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.