<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Gedara Bloom, Hi all:</p>
<p><br>
</p>
<p>Ok, that's sound good. So i need <span>rephrase my proposal about the 802.11 protocol, right?</span></p>
<p><span><br>
</span></p>
<p><span>Best Regards</span></p>
<p><span>Sichen Zhao</span></p>
<p><br>
</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
发自 <a href="http://aka.ms/weboutlook" id="LPNoLP">Outlook</a></div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>发件人:</b> gedare@gwmail.gwu.edu <gedare@gwmail.gwu.edu> 代表 Gedare Bloom <gedare@rtems.org><br>
<b>发送时间:</b> 2017年3月22日 1:35:08<br>
<b>收件人:</b> 赵 思晨<br>
<b>抄送:</b> Christian Mauderer; 赵思晨; devel<br>
<b>主题:</b> Re: 答复: 回复: GSOC 2017 Beagleboard BSP projects</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Tue, Mar 21, 2017 at 9:51 AM, 赵 思晨 <zsc19940506@outlook.com> wrote:<br>
> Hello Christian Mauderer:<br>
><br>
> I think there are still some misunderstanding:<br>
><br>
><br>
> I want to add the hardware independent parts of WLAN (IEEE802.11 standard),<br>
> cause i think the USB driver and WLAN protocol is necessary for the USB<br>
> wireless network card. And i think you mean i only wanna add the USB driver,<br>
> right?<br>
><br>
It sounds like the hardware-independent parts of WLAN are expected to<br>
be already completed and merged by the folks at Embedded Brains. So,<br>
you can focus instead on the driver specific to your dongle.<br>
<br>
><br>
> Best Regards<br>
><br>
> Sichen Zhao<br>
><br>
><br>
> 发自 Outlook<br>
> ________________________________<br>
> 发件人: devel <devel-bounces@rtems.org> 代表 Christian Mauderer<br>
> <christian.mauderer@embedded-brains.de><br>
> 发送时间: 2017年3月21日 21:21:44<br>
> 收件人: 赵思晨<br>
> 抄送: devel<br>
> 主题: Re: 回复: GSOC 2017 Beagleboard BSP projects<br>
><br>
> Hello Sichen Zhao,<br>
><br>
> Am 21.03.2017 um 12:22 schrieb 赵思晨:<br>
>> Hi Christian Mauderer:<br>
>> 1.There is no WLAN chip on BBB, so my need USB dongle. So the USB driver<br>
>> is important and is my main goal of GOSC BBB BSP project.<br>
><br>
> OK. It's fine if that is your focus.<br>
><br>
>> 2.I don't think there is a potential conflict: I think Project<br>
>> Deliverables is a deadline to check , and the work adding the 802.11<br>
>> protocol should be check at the deadline August 29-September 5.    June<br>
>> 27 - August 23 (Second Half) is what i need to do during the two month.<br>
>> and the work i did will be check at the Project Deliverables time. So<br>
>> it's not conflict.<br>
><br>
> So if I understand you correctly, this parts have to do with the<br>
> hardware dependent driver (depending on your USB dongle) and getting one<br>
> example with an USB-WLAN dongle to run? Eventually you should try to<br>
> rephrase that. I read the "adding the 802.11 protocol" in a way that you<br>
> want to add the hardware independent parts of WLAN (IEEE802.11 standard).<br>
><br>
> Kind regards<br>
><br>
> Christian Mauderer<br>
><br>
>><br>
>><br>
>> ------------------ 原始邮件 ------------------<br>
>> *发件人:* "Christian Mauderer";<christian.mauderer@embedded-brains.de>;<br>
>> *发送时间:* 2017年3月21日(星期二) 下午4:33<br>
>> *收件人:* "joel"<joel@rtems.org>;<br>
>> *抄送:* "RTEMS"<devel@rtems.org>;<br>
>> *主题:* Re: GSOC 2017 Beagleboard BSP projects<br>
>><br>
>> Am 21.03.2017 um 00:45 schrieb Joel Sherrill:<br>
>>><br>
>>><br>
>>> On Sun, Mar 19, 2017 at 4:38 PM, Christian Mauderer<br>
>>> <christian.mauderer@embedded-brains.de<br>
>>> <<a href="mailto:christian.mauderer@embedded-brains.de">mailto:christian.mauderer@embedded-brains.de</a>>> wrote:<br>
>>><br>
>>>     ----- Ursprüngliche Mail -----<br>
>>>     > Von: "赵 思晨" <zsc19940506@outlook.com<br>
>>>     <<a href="mailto:zsc19940506@outlook.com">mailto:zsc19940506@outlook.com</a>>><br>
>>>     > An: "RTEMS" <devel@rtems.org <<a href="mailto:devel@rtems.org">mailto:devel@rtems.org</a>>><br>
>>>     > Gesendet: Sonntag, 19. März 2017 15:29:03<br>
>>>     > Betreff: GSOC 2017 Beagleboard BSP projects<br>
>>><br>
>>>     > Hi all:<br>
>>>     ><br>
>>>     ><br>
>>>     > I am interested in the ticket #2819 Beagleboard BSP projects<br>
>>>     ><br>
>>>     ><br>
>>>     > And i have a idea about the project: add the USB and wireless<br>
>>>     network card<br>
>>>     > driver to RTEMS. So RTEMS can apply on many scene applications<br>
>>>     such as the UAV.<br>
>>>     > And for now, i am working on transplant the USB driver from<br>
>>>     FreeBSD to RTEMS.<br>
>>>     ><br>
>>>     ><br>
>>>     ><br>
>>>     > I am a master student from China NanJing University. and i am<br>
>>>     interested in<br>
>>>     > applying for GSoC 2017 under RTEMS.<br>
>>>     > I have develop project on RTEMS for almost a year, so i am very<br>
>>>     familiar with<br>
>>>     > RTEMS development.<br>
>>>     ><br>
>>>     > For now, i have done these works on RTEMS:<br>
>>>     > 1.Porting the ethernet driver from FreeBSD to RTEMS on BBB bsp.<br>
>>>     > 2.Transplant the ION-DTN protocol stack on RTEMS.<br>
>>>     > 3.Took over Punitvara's(GSOC 2016 student) unfinished work on BBB<br>
>>>     i2c driver,<br>
>>>     > and can use i2c read the EEPROM info..(already send PV my pull<br>
>>>     request)<br>
>>>     > 4.Porting  the ethernet driver from UBoot to RTEMS on BBB bsp.<br>
>>>     ><br>
>>>     > Best Regrads<br>
>>>     > Sichen Zhao<br>
>>>     ><br>
>>>     ><br>
>>>     ><br>
>>>     ><br>
>>>     > 发自 Outlook<<a href=""></a>http://aka.ms/weboutlook <<a href="http://aka.ms/weboutlook">http://aka.ms/weboutlook</a>>><br>
>>>     ><br>
>>>     > _______________________________________________<br>
>>>     > devel mailing list<br>
>>>     > devel@rtems.org <<a href="mailto:devel@rtems.org">mailto:devel@rtems.org</a>><br>
>>>     > <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>>     <<a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
>>><br>
>>>     Hello Sichen Zhao,<br>
>>><br>
>>>     just a note regarding the WLAN support in rtems-libbsd: I have just<br>
>>>     recently ported a lot of the necessary kernel modules for<br>
>>>     unencrypted WLAN. Depending on the projects progress, It's quite<br>
>>>     possible that we (embedded brains) will work on encrypted WLAN too<br>
>>>     in the near future. So this might could collide with the goals in<br>
>>>     your proposal that relate to the hardware independent parts of the<br>
>>>     network stack.<br>
>>><br>
>>><br>
>>> Christian.. I appreciate you giving a heads up but isn't the work of<br>
>>> USB support for a BB and a specific WLAN driver for a USB WLAN stick<br>
>>> rather independent of adding encryption support? It would seem they<br>
>>> are in different areas of the tree.<br>
>>><br>
>>> I can see where he could focus on unencrypted support and then<br>
>>> if things work out, take advantage of the encrypted support later.<br>
>>> I thought the tree was already up to date so there wouldn't be any<br>
>>> massive updates of code.<br>
>>><br>
>>> What conflicts do you foresee? And can you work with the student<br>
>>> to avoid or minimize them.<br>
>>><br>
>>> Working in the open and coordinating efforts is critical in any open<br>
>>> source project. This seems like one which can be managed. Especially<br>
>>> if you help out on this project so you can help avoid the issues.<br>
>>><br>
>>> Thanks.<br>
>>><br>
>>> --joel<br>
>>><br>
>><br>
>> Hello Joel, Hello Sichen Zhao,<br>
>><br>
>> I agree, that most of the proposal won't be touched by the WLAN part<br>
>> that is already done or will be (hopefully) done in the near future. I'm<br>
>> not sure what WLAN chip set is used on the BB (or on the intended USB<br>
>> dongle) so currently I can't say for sure whether it is already build<br>
>> with the rest of the drivers or not. Sichen Zhao: Do you have any<br>
>> information on that?<br>
>><br>
>> A potential conflict in the proposal is in the "Project Deliverables"<br>
>> the part "August 29-September 5 (Final Evaluation) - Add the wireless<br>
>> protocol such as 802.11". That is also mentioned in "June 27 - August 23<br>
>> (Second Half)" under the point "5.Adding the wireless protocol 802.11 on<br>
>> RTEMS."<br>
>><br>
>> But to be honest: It might anyhow would have been a quite big workpiece<br>
>> if it would have been only a part of a GSoC project. The unencrypted<br>
>> WLAN port has been quite some effort and there is a big part necessary<br>
>> for the encrypted WLAN user space (the wpa supplicant). So it quite<br>
>> likely is better to concentrate on the device specific driver and try to<br>
>> get it running with unencrypted WLAN. If that works, it shouldn't be a<br>
>> big problem to get the encrypted one running.<br>
>><br>
>> If there is time left for any work: For the encrypted WLAN, it is always<br>
>> interesting if there is any hardware encryption support. If the WLAN<br>
>> chip doesn't have it itself (not all USB chips have it), a hardware<br>
>> encryption of the host processor might be useful. So if the processor on<br>
>> the BB has a hardware encryption module, it could be nice to have it<br>
>> supported by the rtems-libbsd. But I'm not sure whether we already have<br>
>> any encryption on other platforms and I'm also not sure how much work<br>
>> that would be.<br>
>><br>
>> Please note that I don't really have any experience what the usual scope<br>
>> is for a GSoC project. So I'm not sure whether that would be possible or<br>
>> realistic in the given time.<br>
>><br>
>> Kind regards<br>
>><br>
>> Christian Mauderer<br>
>> --<br>
>> --------------------------------------------<br>
>> embedded brains GmbH<br>
>> Christian Mauderer<br>
>> Dornierstr. 4<br>
>> D-82178 Puchheim<br>
>> Germany<br>
>> email: christian.mauderer@embedded-brains.de<br>
>> Phone: +49-89-18 94 741 - 18<br>
>> Fax:   +49-89-18 94 741 - 08<br>
>> PGP: Public key available on request.<br>
>><br>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> devel@rtems.org<br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> --<br>
> --------------------------------------------<br>
> embedded brains GmbH<br>
> Christian Mauderer<br>
> Dornierstr. 4<br>
> D-82178 Puchheim<br>
> Germany<br>
> email: christian.mauderer@embedded-brains.de<br>
> Phone: +49-89-18 94 741 - 18<br>
> Fax:   +49-89-18 94 741 - 08<br>
> PGP: Public key available on request.<br>
><br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> _______________________________________________<br>
> devel mailing list<br>
> devel@rtems.org<br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> devel@rtems.org<br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</div>
</span></font>
</body>
</html>