GSoC'18-Introduction

Russell Haley russ.haley at gmail.com
Mon Feb 26 22:32:13 UTC 2018


On Mon, Feb 26, 2018 at 12:54 PM, Christian Mauderer <list at c-mauderer.de> wrote:
> Am 26.02.2018 um 18:01 schrieb Russell Haley:
>> On Mon, Feb 26, 2018 at 12:04 AM, Christian Mauderer
>> <christian.mauderer at embedded-brains.de> wrote:
>>> Hello Udit,
>>>
>>> Am 26.02.2018 um 08:30 schrieb Russell Haley:
>>>> On Sun, Feb 25, 2018 at 11:08 PM, Udit agarwal <dev.madaari at gmail.com> wrote:
>>>>> Hi,
>>>>> So, the error turned out to be due to missing dts only, after building the
>>>>> scripts again with FDT, both the I2C sample code(Logs:here),
>>>>> media01(Logs:here) example worked flawlessly, and thus i was able to read
>>>>> sd-card data. What could be my next possible task on libbsd?
>>>
>>> Most of the time, students are encouraged to fix some small bugs or
>>> create some small patches during this phase of GSoC. So you might want
>>> to do that.
>>>
>>> I think there are only few if any (small) open bugs in the RT regarding
>>> libbsd. But the BBB BSP currently lacks a getentropy implementation
>>> based on the hardware random number generator. That could be a nice
>>> small patch and it would increase the strength of any cryptography (like
>>> for example WiFi) on the BBB.
>>>
>>>>> Moreover, I tried building wifi sample app as well, but i have Atheros
>>>>> AR9271(Firmware name:  ath9k_htc/htc_9271-1.4.0.fw) wireless card. Following
>>>>> sichen's blog posts(here) i tried building support for my wireless card, but
>>>>> it looks like FreeBSD itself lacks support for this( as mentioned here )
>>>>> Is there any other way, apart from using FreeBSD for generating support for
>>>>> my wifi card?
>>>>
>>>> I know you said "apart from using FreeBSD" but there is a good chance
>>>> that partial support for your card is lying around in FreeBSD HEAD. If
>>>> you're really keen you could go on the freebsd-arm at freebsd.org mailing
>>>> list and ask. Alternatively you pop onto IRC. Adrian and the other
>>>> guys on there are the ones that can help you out.
>>>>
>>>
>>> If FreeBSD doesn't support your dongle, it's quite hard to get it
>>> working. You would either have to write the driver yourself or find some
>>> FreeBSD compatible one. I would say that writing a WiFi driver yourself
>>> would be a project that heavily exceeds a GSoC project. For the other
>>> solution (finding a driver) Russell already gave the best hints: Talk to
>>> the FreeBSD developers. But I would expect that you won't have a quick
>>> success there too.
>>>
>>> So the simplest solution would be to buy some (cheap) WiFi dongle that
>>> is supported or can easily be ported.
>>
>> Even drivers that work need someone to go through and validate their
>> performance. The following is a link to a conversation I had about
>> WiFi drivers (albeit a different radios) with marginal or no support.
>> While my radio was not supported, the original complainants was.
>>
>> http://freebsd.1045724.x6.nabble.com/template/NamlServlet.jtp?macro=search_page&node=3556680&query=Beaglebone+Black+%2B+FreeBSD+%2B+USB+WiFi+%3D+WAP&n=3556680
>
> Yes of course a new driver needs someone to test it too and if some
> fixes are necessary that can be a great GSoC project on it's own. @Udit:
> Please note that if you want to do that as a project we should get at
> least one FreeBSD programmer into the boat.
>
>>
>> While I am unsure of what RTEMS supports, there is also an SDIO driver
>> in FreeBSD that is somewhat new that nobody has properly
>> tested/compared against the original sdhc driver. I was trying to get
>> there but ran out of time (I was using DTrace, RTEMS will have
>> different benchmark tools). The original port was on BBB. An excellent
>> project would be to go and build the original sdhc driver and the new
>> SDIO driver and benchmark them (In FreeBSD, this was done by using two
>> different kernel configs). This driver is also in the process of being
>> adopted to support SDIO WiFi chips, which are wildly popular now.
>
> With the libbsd RTEMS basically should be able to take over new drivers
> quite easily. User space tools are a little harder.
>
> It's really great to hear that there is a SDIO support for FreeBSD in
> preparation.
>
> Russells suggestion could make a nice project too. Porting the new
> driver and compare different driver versions on different systems would
> give us some nice performance charts and could help finding bugs in the
> new FreeBSD driver.
>
> @Russell: It seems that you have some experience with FreeBSD. If you
> have time and if you feel like it you could think about mentoring or
> co-mentoring a RTEMS or rtems-libbsd project.

Unfortunately I am more of a 'hanger-on' than an active participant in
most things at this level due to time constraints. I'm always happy to
chip in where possible though.

Russ
>>
>>>> For What It's Worth,
>>>> Russ
>>>>
>>>>> Moreover, regarding libbsd documentation, i am keeping note of every step,
>>>>> and will soon update the document(libbsd.txt).
>>>
>>> That would be a great patch too. Thanks.
>>
>> I can't overstate what a fantastic learning opportunity documentation
>> support is:
>>
>> - It forces one to go back and validate everything that you *think*
>> you know and explain it.
>> - It demonstrates that you understand the source material.
>> - You learn new tools and and options in the process (RTEMS has a great toolset)
>>
>> In my opinion it's far better to partially succeed but have good
>> documents, then to finish something once and have none.
>
> Unfortunately we have only few documentation for the libbsd. I agree
> that a better documentation would be great. Therefore: Every patch
> improving the documentation is great.
>
> Best regards
>
> Christian
>
>>
>> There is my morning randomness, let me know if any of it makes sense. ;)
>>
>> Russ
>>
>>> Best regards
>>>
>>> Christian
>>>
>>>>>
>>>>> Thanks,
>>>>> Udit Agarwal
>>>>>
>>>>> On Sun, Feb 25, 2018 at 11:15 PM, Russell Haley <russ.haley at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Sorry for the top post.
>>>>>>
>>>>>> Dts file in freebsd tree are here. The Dts files are imported from Linux
>>>>>> for compatability.
>>>>>>
>>>>>> https://svnweb.freebsd.org/base/head/sys/gnu/dts/arm/
>>>>>>
>>>>>> Russ
>>>>>>
>>>>>> Sent from my BlackBerry 10 smartphone on the Virgin Mobile network.
>>>>>>   Original Message
>>>>>> From: Christian Mauderer
>>>>>> Sent: Sunday, February 25, 2018 2:32 AM
>>>>>> To: Udit agarwal; Users
>>>>>> Subject: Re: GSoC'18-Introduction
>>>>>>
>>>>>> Am 25.02.2018 um 08:41 schrieb Udit agarwal:
>>>>>>> Hi,
>>>>>>> I did build libbsd for beagleboneBlack and executed selectpollkqueue01
>>>>>>> test successfully.(Logs:here
>>>>>>> <https://gist.github.com/madaari/ae7b3334514a9aec3b063eaa3a0dcd05>)
>>>>>>> However, while trying to access SD card, media01 test failed with an
>>>>>>> error "fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)  " (Logs:here
>>>>>>> <https://gist.github.com/madaari/c6d524bc06e896359f9535d90c0a447a>)
>>>>>>> I tried debugging the script, by putting printf statements in various
>>>>>>> functions, but it seems like it's failing even before entering
>>>>>>> test_main().
>>>>>>> Also, is there a better method with which we can debug RTEMS scripts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Udit Agarwal
>>>>>>
>>>>>> Hello Udit,
>>>>>>
>>>>>> it's great that you can already compile and run some of the libbsd
>>>>>> examples.
>>>>>>
>>>>>>
>>>>>> Regarding your problem with the SD card: Note that the BBB BSP uses the
>>>>>> flattened device tree (at least the libbsd on BBB does). Therefore you
>>>>>> have to load a dtb too. My U-Boot boot lines looks like follows:
>>>>>>
>>>>>> fatload mmc 0 0x80800000 rtems-app.img
>>>>>> fatload mmc 0 0x88000000 am335x-boneblack.dtb
>>>>>> bootm 0x80800000 - 0x88000000
>>>>>>
>>>>>> I create a SD-Card image with a script that is based on one that is (or
>>>>>> was) contained some time back in the BSP. You can have a look here:
>>>>>>
>>>>>>
>>>>>> https://gitlab.com/c-mauderer/rtems-bbb/blob/master/build/create-sdcardimage.sh
>>>>>>
>>>>>> The script does a lot of things that are not necessary any more (like
>>>>>> copying a U-Boot to the SD card). Basically the necessary points would
>>>>>> be to create a image and an uEnv.txt (with the lines from 78 to 83). You
>>>>>> can use the dtb file that is provided by a FreeBSD or a Linux for BBB.
>>>>>>
>>>>>>
>>>>>> Regarding debugging the application: I would strongly recommend to use
>>>>>> some kind of hardware JTAG debugger. Some Beagle Bone variants have an
>>>>>> on-board debugger (I think mainly the older white one). For others you
>>>>>> can use hardware debuggers like quite a number of adapters supported by
>>>>>> OpenOCD (FlySwatter2, simple FTDI-based ones, ...), Segger J-Link (in
>>>>>> your case the EDU version) or whatever you find that can debug the BBB.
>>>>>>
>>>>>> It may be possible to use the libdebugger as a serial debugger. But I
>>>>>> never used it so I'm not sure how well you can debug through the libbsd
>>>>>> with it. I'm also not sure whether it works for the BBB. Chris Johns
>>>>>> added the ARM support some time back. Maybe he can give you any hints if
>>>>>> you want to try libdebugger.
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Christian Mauderer
>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 23, 2018 at 11:25 PM, Christian Mauderer <list at c-mauderer.de
>>>>>>> <mailto:list at c-mauderer.de>> wrote:
>>>>>>>
>>>>>>> Am 23.02.2018 um 05:17 schrieb Udit agarwal:
>>>>>>>> Hi,
>>>>>>>> Thanks for your help mentors,
>>>>>>>> Since last time, I have managed to modify and execute hello world
>>>>>>>> application on both the platforms, my local machine(Ubuntu 14.04) and
>>>>>>>> BeagleBone Black.
>>>>>>>> I have attached the screenshots and patch file as proof and  detailed
>>>>>>>> logs can be found on these(1
>>>>>>>> <https://gist.github.com/madaari/8aae37012d0d175b859c6471a5b13248
>>>>>>> <https://gist.github.com/madaari/8aae37012d0d175b859c6471a5b13248>>
>>>>>>> and 2
>>>>>>>> <https://gist.github.com/madaari/a7f1d223fb0513e4890025fd1ba6184d
>>>>>>> <https://gist.github.com/madaari/a7f1d223fb0513e4890025fd1ba6184d>>)
>>>>>>> gists.
>>>>>>>> Moreover, I went through all the mentioned projects, and found a few
>>>>>>>> of
>>>>>>>> them(Like extending support for PRU, integration of networking stack
>>>>>>>> ,porting RTEMS on PocketBeagle etc) really interesting and doable
>>>>>>>> withing the given time constraint!
>>>>>>>> So, i thought of starting off by studying a bit about the networking
>>>>>>>> stack, its implementation etc. Please recommend few resources from
>>>>>>>> where
>>>>>>>> i can explore this.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Udit agarwal
>>>>>>>>
>>>>>>>
>>>>>>> Hello Udit,
>>>>>>>
>>>>>>> it's great that you already have build and successfully executed the
>>>>>>> example on BBB.
>>>>>>>
>>>>>>> Regarding the network stack. First of all: Note that there are at least
>>>>>>> three network stacks in RTEMS:
>>>>>>>
>>>>>>> 1. The "old" one which is integrated into the RTEMS sources. This one
>>>>>>> exists since quite some time in RTEMS. It is a fork of a really old
>>>>>>> version of the FreeBSD network stack and it has been heavily adapted
>>>>>>> during the time. I think there is a manual regarding this stack on the
>>>>>>> docs.rtems.org <http://docs.rtems.org>. It has only IPv4 support.
>>>>>>>
>>>>>>> 2. The "new" one which lives in it's own libbsd repository. That one is
>>>>>>> a fork of the latest FreeBSD development version. One of the important
>>>>>>> points during the development has been that the sources should be as
>>>>>>> close as possible to the upstream FreeBSD sources. This makes it simpler
>>>>>>> to keep up to the FreeBSD development. This one can IPv4 and IPv6 and
>>>>>>> should be basically able to support everything FreeBSD does. Beneath
>>>>>>> that it also brings in USB and SD-Card support and some other subsystems
>>>>>>> of FreeBSD.
>>>>>>>
>>>>>>> 3. I'm quite sure that I have seen some posts about the lwIP
>>>>>>> (lightweight IP) stack used together with RTEMS.
>>>>>>>
>>>>>>>
>>>>>>> Most network stack related projects on the open projects page refer to
>>>>>>> the libbsd (second one in my list). So you most likely should
>>>>>>> concentrate on that one.
>>>>>>>
>>>>>>> The big disadvantage of the libbsd is that it heavily lacks
>>>>>>> documentation. The main documentation is the one big libbsd.txt in the
>>>>>>> source tree (https://git.rtems.org/rtems-libbsd/tree/libbsd.txt
>>>>>>> <https://git.rtems.org/rtems-libbsd/tree/libbsd.txt>) and
>>>>>>> some other files (like CONTRIBUGING.md).
>>>>>>>
>>>>>>> If you want to work on the libbsd, I would suggest that you try to build
>>>>>>> it for the Beagle Bone Black and for example access the SD card content.
>>>>>>>
>>>>>>> For that I would suggest to take a look at the libbsd.txt and maybe at
>>>>>>> the work of last years students (for the libbsd in 2017 that is mainly
>>>>>>> Sichen Zhao). Please ask any question you have on the mailing list. And
>>>>>>> please write down everything you learn and add it to the libbsd.txt. It
>>>>>>> would be a really great start to improve that document.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Christian Mauderer
>>>>>>>
>>>>>>>> On Thu, Feb 22, 2018 at 12:28 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 21.02.2018 um 00:14 schrieb Joel Sherrill:
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > On Tue, Feb 20, 2018 at 3:23 PM, Gedare Bloom <gedare at rtems.org
>>>>>>>> <mailto:gedare at rtems.org> <mailto:gedare at rtems.org
>>>>>>> <mailto:gedare at rtems.org>>
>>>>>>>>     > <mailto:gedare at rtems.org <mailto:gedare at rtems.org>
>>>>>>> <mailto:gedare at rtems.org <mailto:gedare at rtems.org>>>> wrote:
>>>>>>>>     >
>>>>>>>>     >     Hello and welcome,
>>>>>>>>     >
>>>>>>>>     >     For projects that intend to use a specific board, we
>>>>>>> require that you
>>>>>>>>     >     can demonstrate some proficiency with the board itself.
>>>>>>> In this case,
>>>>>>>>     >     you should be able to run RTEMS on the BBB first. Now,
>>>>>>> there has been
>>>>>>>>     >     significant progress made on BBB support, so hopefully
>>>>>>> someone may
>>>>>>>>     >     chime in with what else might remain to be done with it.
>>>>>>> With a little
>>>>>>>>     >     bit of digging, you should be able to find prior
>>>>>>> students and mentors
>>>>>>>>     >     for BBB related projects.
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > My recollection is that the student working on Wifi got it
>>>>>>> working
>>>>>>>>     with a
>>>>>>>>     > USB dongle on either the BBB or Pi. The Wifi stack still
>>>>>>> needs work
>>>>>>>>     > independent of any BSP and we have listed that as a project.
>>>>>>>>     >
>>>>>>>>     > But I thought the BBB was in pretty good shape overall. But
>>>>>>> that's
>>>>>>>>     just
>>>>>>>>     > from memory.
>>>>>>>>     >
>>>>>>>>     > --joel
>>>>>>>>     >
>>>>>>>>
>>>>>>>>     Hello,
>>>>>>>>
>>>>>>>>     I have been a mentor for Sichen last year. He has done some driver
>>>>>>>>     support for the core RTEMS BSP of the BBB last year and he
>>>>>>> ported the
>>>>>>>>     necessary libbsd drivers to use a USB WiFi dongle on that
>>>>>>> board. He also
>>>>>>>>     put a lot of work into the encrypted WiFi support.
>>>>>>>>
>>>>>>>>     I think the year before Punit has worked on the BBB BSP.
>>>>>>>>
>>>>>>>>     Like Joel already said, the core BBB is quite well supported.
>>>>>>> But there
>>>>>>>>     are still some drivers like CAN, Ethernet or USB OTG (to name
>>>>>>> a few)
>>>>>>>>     that could be implemented. I've posted an update to the ticket
>>>>>>> on BBB
>>>>>>>>     (#2891) some weeks back.
>>>>>>>>
>>>>>>>>     There are also still two projects regarding the WiFi support
>>>>>>> that could
>>>>>>>>     be done. The BBB is a really good platform for that. That
>>>>>>> would be the
>>>>>>>>     tickets #3222 and #3223.
>>>>>>>>
>>>>>>>>     You can find the tickets linked on the open projects page in
>>>>>>> the wiki.
>>>>>>>>
>>>>>>>>     Regards
>>>>>>>>
>>>>>>>>     Christian
>>>>>>>>
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     >     Gedare
>>>>>>>>     >
>>>>>>>>     >     On Tue, Feb 20, 2018 at 1:56 PM, Udit agarwal
>>>>>>> <dev.madaari at gmail.com <mailto:dev.madaari at gmail.com>
>>>>>>> <mailto:dev.madaari at gmail.com <mailto:dev.madaari at gmail.com>>
>>>>>>>>     >     <mailto:dev.madaari at gmail.com <mailto:dev.madaari at gmail.com>
>>>>>>> <mailto:dev.madaari at gmail.com <mailto:dev.madaari at gmail.com>>>> wrote:
>>>>>>>>     >     > Hi,
>>>>>>>>     >     > I am Udit Agarwal(irc handle: madaari), pursuing my
>>>>>>>> undergraduate
>>>>>>>>     >     degree in
>>>>>>>>     >     > Electronics Engineering from Netaji subash Institute of
>>>>>>>>     >     Technology, India.
>>>>>>>>     >     > I had some experience of TI-RTOS on MSP432(Cortex M)
>>>>>>>>     >     microcontroller, with a
>>>>>>>>     >     > pretty good grasp on Beagle Bone Black and other hardware
>>>>>>>> stuff.
>>>>>>>>     >     I'm pretty
>>>>>>>>     >     > excited about the project of improving RTEMS support on
>>>>>>>> Beagle
>>>>>>>>     >     Bone Black,
>>>>>>>>     >     > and would thus like to compete for it.
>>>>>>>>     >     > Being already started with RTEMS documentation and the
>>>>>>>> Hello World
>>>>>>>>     >     project,
>>>>>>>>     >     > I would like to know about any other resources i can
>>>>>>>> consider
>>>>>>>>     >     apart from
>>>>>>>>     >     > documentation and RSB guide, for this specific BSP(Beagle
>>>>>>>> Bone Black)?
>>>>>>>>     >     >
>>>>>>>>     >     > Thanks,
>>>>>>>>     >     > Udit Agarwal
>>>>>>>>     >     >
>>>>>>>>     >     > _______________________________________________
>>>>>>>>     >     > users mailing list
>>>>>>>>     >     > users at rtems.org <mailto:users at rtems.org>
>>>>>>>> <mailto:users at rtems.org
>>>>>>> <mailto:users at rtems.org>>
>>>>>>>>     <mailto: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
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>
>>>>>>>>     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>>
>>>>>>>>     >     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>
>>>>>>>>     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <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>>
>>>>>>>>     <mailto: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
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>
>>>>>>>>     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>>
>>>>>>>>     >     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>
>>>>>>>>     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <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
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>
>>>>>>>>     <http://lists.rtems.org/mailman/listinfo/users
>>>>>>> <http://lists.rtems.org/mailman/listinfo/users>>
>>>>>>>>     >
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> users mailing list
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> 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.
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>>


More information about the users mailing list