<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p></p>
<div class="PlainText" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
Hi <span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
Christian Mauderer ,Hi </span><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">Gedare Bloom:</span></div>
<div class="PlainText" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
<span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;"><br>
</span></div>
<div class="PlainText" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
I think i can add the porting wpa to my proposal, and it will be the last part of my GSOC goal.</div>
<div class="PlainText" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
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</div>
<div class="PlainText" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
best.</div>
<div class="PlainText" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 13.3333px;">
What do you think so?</div>
<br>
<p></p>
<p><span style="font-size: 10pt;">Best Regards</span></p>
<p><span style="font-size: 10pt;">Sichen Zhao</span></p>
<p><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
From <a href="http://aka.ms/weboutlook" id="LPNoLP">Outlook</a></div>
</div>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr style="display:inline-block; width:98%" tabindex="-1">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>发件人:</b> Christian Mauderer <christian.mauderer@embedded-brains.de><br>
<b>发送时间:</b> 2017年3月22日 16:07<br>
<b>收件人:</b> Gedare Bloom; 赵 思晨<br>
<b>抄送:</b> 赵思晨; 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">Am 21.03.2017 um 18:35 schrieb Gedare Bloom:<br>
> 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>
Yes correctly. The hardware independent part of unencrypted WLAN is<br>
already available and working in rtems-libbsd. It's quite likely (but<br>
not 100% sure at this point in time) that we also get a project for the<br>
encrypted part.<br>
<br>
Beneath that, to enable the encryption, a essential part is to port the<br>
wpa-supplicant daemon to RTEMS. That will be a complex part and I'm<br>
really not sure if it would be doable as only a part of a GSoC project.<br>
You will have to add quite some additional time for getting familiar<br>
with the problems and how to solve them.<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>
<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>
</div>
</span></font></div>
</div>
</body>
</html>