Re: 答复: 答复: 回复： GSOC 2017 Beagleboard BSP projects
Thomas Doerfler
thomas.doerfler at embedded-brains.de
Wed Mar 22 10:47:34 UTC 2017
Hi all,
Christian and I had a talk about this discussion. The thing is: one of
our customers does require WPA support rather soon, therefore (most
likely) we will do a first implementation/port within the next 2-3
months. We are not yet sure whether the results are fit enough to be
published at once, but in the long term WPA support would then be
available for RTEMS.
I hate the idea of two concurrent implementations of the same
functionality. I also hate the idea of having a GSOC project being of no
use for RTEMS (this is a wast of creativity and if I were the student, I
would regard it quite frustrating).
So if you find different BBB areas which still need driver support, this
would IMHO make more sense.
But please observe: this is just my personal opinion. Maybe others also
have some thoughts on this?
wkr,
Thomas.
Am 22.03.2017 um 09:26 schrieb 赵 思晨:
> Hi Christian Mauderer ,Hi Gedare Bloom:
>
> I think i can add the porting wpa to my proposal, and it will be the
> last part of my GSOC goal.
> And i guess may left a mouth or less to do the wpa porting, and may can
> not finish it. but i will try my
> best.
> What do you think so?
>
> Best Regards
>
> Sichen Zhao
>
>
> From Outlook <http://aka.ms/weboutlook>
>
>
> ------------------------------------------------------------------------
> *发件人:* Christian Mauderer <christian.mauderer at embedded-brains.de>
> *发送时间:* 2017年3月22日 16:07
> *收件人:* Gedare Bloom; 赵 思晨
> *抄送:* 赵思晨; devel
> *主题:* Re: 答复: 回复： GSOC 2017 Beagleboard BSP projects
>
> Am 21.03.2017 um 18:35 schrieb Gedare Bloom:
>> On Tue, Mar 21, 2017 at 9:51 AM, 赵 思晨 <zsc19940506 at outlook.com> wrote:
>>> Hello Christian Mauderer:
>>>
>>> I think there are still some misunderstanding:
>>>
>>>
>>> I want to add the hardware independent parts of WLAN (IEEE802.11 standard),
>>> cause i think the USB driver and WLAN protocol is necessary for the USB
>>> wireless network card. And i think you mean i only wanna add the USB driver,
>>> right?
>>>
>> It sounds like the hardware-independent parts of WLAN are expected to
>> be already completed and merged by the folks at Embedded Brains. So,
>> you can focus instead on the driver specific to your dongle.
>>
>
> Yes correctly. The hardware independent part of unencrypted WLAN is
> already available and working in rtems-libbsd. It's quite likely (but
> not 100% sure at this point in time) that we also get a project for the
> encrypted part.
>
> Beneath that, to enable the encryption, a essential part is to port the
> wpa-supplicant daemon to RTEMS. That will be a complex part and I'm
> really not sure if it would be doable as only a part of a GSoC project.
> You will have to add quite some additional time for getting familiar
> with the problems and how to solve them.
>
>>>
>>> Best Regards
>>>
>>> Sichen Zhao
>>>
>>>
>>> 发自 Outlook
>>> ________________________________
>>> 发件人: devel <devel-bounces at rtems.org> 代表 Christian Mauderer
>>> <christian.mauderer at embedded-brains.de>
>>> 发送时间: 2017年3月21日 21:21:44
>>> 收件人: 赵思晨
>>> 抄送: devel
>>> 主题: Re: 回复： GSOC 2017 Beagleboard BSP projects
>>>
>>> Hello Sichen Zhao,
>>>
>>> Am 21.03.2017 um 12:22 schrieb 赵思晨:
>>>> Hi Christian Mauderer:
>>>> 1.There is no WLAN chip on BBB, so my need USB dongle. So the USB driver
>>>> is important and is my main goal of GOSC BBB BSP project.
>>>
>>> OK. It's fine if that is your focus.
>>>
>>>> 2.I don't think there is a potential conflict: I think Project
>>>> Deliverables is a deadline to check , and the work adding the 802.11
>>>> protocol should be check at the deadline August 29-September 5. June
>>>> 27 - August 23 (Second Half) is what i need to do during the two month.
>>>> and the work i did will be check at the Project Deliverables time. So
>>>> it's not conflict.
>>>
>>> So if I understand you correctly, this parts have to do with the
>>> hardware dependent driver (depending on your USB dongle) and getting one
>>> example with an USB-WLAN dongle to run? Eventually you should try to
>>> rephrase that. I read the "adding the 802.11 protocol" in a way that you
>>> want to add the hardware independent parts of WLAN (IEEE802.11 standard).
>>>
>>> Kind regards
>>>
>>> Christian Mauderer
>>>
>>>>
>>>>
>>>> ------------------ 原始邮件 ------------------
>>>> *发件人:* "Christian Mauderer";<christian.mauderer at embedded-brains.de>;
>>>> *发送时间:* 2017年3月21日(星期二) 下午4:33
>>>> *收件人:* "joel"<joel at rtems.org>;
>>>> *抄送:* "RTEMS"<devel at rtems.org>;
>>>> *主题:* Re: GSOC 2017 Beagleboard BSP projects
>>>>
>>>> Am 21.03.2017 um 00:45 schrieb Joel Sherrill:
>>>>>
>>>>>
>>>>> On Sun, Mar 19, 2017 at 4:38 PM, Christian Mauderer
>>>>> <christian.mauderer at embedded-brains.de
>>>>> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>>>>>
>>>>> ----- Ursprüngliche Mail -----
>>>>> > Von: "赵 思晨" <zsc19940506 at outlook.com
>>>>> <mailto:zsc19940506 at outlook.com>>
>>>>> > An: "RTEMS" <devel at rtems.org <mailto:devel at rtems.org>>
>>>>> > Gesendet: Sonntag, 19. März 2017 15:29:03
>>>>> > Betreff: GSOC 2017 Beagleboard BSP projects
>>>>>
>>>>> > Hi all:
>>>>> >
>>>>> >
>>>>> > I am interested in the ticket #2819 Beagleboard BSP projects
>>>>> >
>>>>> >
>>>>> > And i have a idea about the project: add the USB and wireless
>>>>> network card
>>>>> > driver to RTEMS. So RTEMS can apply on many scene applications
>>>>> such as the UAV.
>>>>> > And for now, i am working on transplant the USB driver from
>>>>> FreeBSD to RTEMS.
>>>>> >
>>>>> >
>>>>> >
>>>>> > I am a master student from China NanJing University. and i am
>>>>> interested in
>>>>> > applying for GSoC 2017 under RTEMS.
>>>>> > I have develop project on RTEMS for almost a year, so i am very
>>>>> familiar with
>>>>> > RTEMS development.
>>>>> >
>>>>> > For now, i have done these works on RTEMS:
>>>>> > 1.Porting the ethernet driver from FreeBSD to RTEMS on BBB bsp.
>>>>> > 2.Transplant the ION-DTN protocol stack on RTEMS.
>>>>> > 3.Took over Punitvara's(GSOC 2016 student) unfinished work on BBB
>>>>> i2c driver,
>>>>> > and can use i2c read the EEPROM info..(already send PV my pull
>>>>> request)
>>>>> > 4.Porting the ethernet driver from UBoot to RTEMS on BBB bsp.
>>>>> >
>>>>> > Best Regrads
>>>>> > Sichen Zhao
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > 发自 Outlook<http://aka.ms/weboutlook <http://aka.ms/weboutlook>>
>>>>> >
>>>>> > _______________________________________________
>>>>> > devel mailing list
>>>>> > devel at rtems.org <mailto:devel at rtems.org>
>>>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>>> <http://lists.rtems.org/mailman/listinfo/devel>
>>>>>
>>>>> Hello Sichen Zhao,
>>>>>
>>>>> just a note regarding the WLAN support in rtems-libbsd: I have just
>>>>> recently ported a lot of the necessary kernel modules for
>>>>> unencrypted WLAN. Depending on the projects progress, It's quite
>>>>> possible that we (embedded brains) will work on encrypted WLAN too
>>>>> in the near future. So this might could collide with the goals in
>>>>> your proposal that relate to the hardware independent parts of the
>>>>> network stack.
>>>>>
>>>>>
>>>>> Christian.. I appreciate you giving a heads up but isn't the work of
>>>>> USB support for a BB and a specific WLAN driver for a USB WLAN stick
>>>>> rather independent of adding encryption support? It would seem they
>>>>> are in different areas of the tree.
>>>>>
>>>>> I can see where he could focus on unencrypted support and then
>>>>> if things work out, take advantage of the encrypted support later.
>>>>> I thought the tree was already up to date so there wouldn't be any
>>>>> massive updates of code.
>>>>>
>>>>> What conflicts do you foresee? And can you work with the student
>>>>> to avoid or minimize them.
>>>>>
>>>>> Working in the open and coordinating efforts is critical in any open
>>>>> source project. This seems like one which can be managed. Especially
>>>>> if you help out on this project so you can help avoid the issues.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> --joel
>>>>>
>>>>
>>>> Hello Joel, Hello Sichen Zhao,
>>>>
>>>> I agree, that most of the proposal won't be touched by the WLAN part
>>>> that is already done or will be (hopefully) done in the near future. I'm
>>>> not sure what WLAN chip set is used on the BB (or on the intended USB
>>>> dongle) so currently I can't say for sure whether it is already build
>>>> with the rest of the drivers or not. Sichen Zhao: Do you have any
>>>> information on that?
>>>>
>>>> A potential conflict in the proposal is in the "Project Deliverables"
>>>> the part "August 29-September 5 (Final Evaluation) - Add the wireless
>>>> protocol such as 802.11". That is also mentioned in "June 27 - August 23
>>>> (Second Half)" under the point "5.Adding the wireless protocol 802.11 on
>>>> RTEMS."
>>>>
>>>> But to be honest: It might anyhow would have been a quite big workpiece
>>>> if it would have been only a part of a GSoC project. The unencrypted
>>>> WLAN port has been quite some effort and there is a big part necessary
>>>> for the encrypted WLAN user space (the wpa supplicant). So it quite
>>>> likely is better to concentrate on the device specific driver and try to
>>>> get it running with unencrypted WLAN. If that works, it shouldn't be a
>>>> big problem to get the encrypted one running.
>>>>
>>>> If there is time left for any work: For the encrypted WLAN, it is always
>>>> interesting if there is any hardware encryption support. If the WLAN
>>>> chip doesn't have it itself (not all USB chips have it), a hardware
>>>> encryption of the host processor might be useful. So if the processor on
>>>> the BB has a hardware encryption module, it could be nice to have it
>>>> supported by the rtems-libbsd. But I'm not sure whether we already have
>>>> any encryption on other platforms and I'm also not sure how much work
>>>> that would be.
>>>>
>>>> Please note that I don't really have any experience what the usual scope
>>>> is for a GSoC project. So I'm not sure whether that would be possible or
>>>> realistic in the given time.
>>>>
>>>> Kind regards
>>>>
>>>> Christian Mauderer
>>>> --
>>>> --------------------------------------------
>>>> embedded brains GmbH
>>>> 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.
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> --
>>> --------------------------------------------
>>> embedded brains GmbH
>>> 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.
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> --------------------------------------------
> embedded brains GmbH
> 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.
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
--
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list