Beaglebone help needed
Christian Mauderer
christian.mauderer at embedded-brains.de
Thu Mar 7 10:03:20 UTC 2019
Am 07.03.19 um 09:52 schrieb Sarvesh Patkar:
> Hey Chris and Christian,
>
> Thank you for the prompt responses.
>
> I think there is no update needed to the rtems-source-builder at this
> time for beaglebone. After understanding what Christian told me, I
> realized that I just needed to use the rtems-arm build set. Then, I
> followed this
> README https://git.rtems.org/rtems/tree/bsps/arm/beagle/README from the
> master branch of rtems and ran the ticker sample on the beaglebone.
>
> For now, I think I will stick to figuring out more about the PRU or ADC
> peripherals and try to write the respective drivers for the BSP. Since
> I am not associated with GSoC or any other institute, I will keep an eye
> on the mailing lists and make sure I am not duplicating work which
> others are doing on the Beaglebone black.
>
> Thanks again for all the help.
>
> Regards,
> Sarvesh
Hello Sarvesh,
good to hear that you managed to get started. Sorry that I assumed that
you are a student interested in GSoC participation. We currently have
the phase where the students start to search for projects.
Best regards
Christian
>
> On Wed, Mar 6, 2019 at 10:18 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> 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>
> > <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>
> > <mailto: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>
> > <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>
> <mailto: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>
> <mailto: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
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto: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.
>
--
--------------------------------------------
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.
More information about the users
mailing list