Hi Gedara Bloom, Hi all:
Ok, that's sound good. So i need rephrase my proposal about the 802.11 protocol, right? Best Regards Sichen Zhao 发自 Outlook<http://aka.ms/weboutlook> ________________________________ 发件人: ged...@gwmail.gwu.edu <ged...@gwmail.gwu.edu> 代表 Gedare Bloom <ged...@rtems.org> 发送时间: 2017年3月22日 1:35:08 收件人: 赵 思晨 抄送: Christian Mauderer; 赵思晨; devel 主题: Re: 答复: 回复： GSOC 2017 Beagleboard BSP projects On Tue, Mar 21, 2017 at 9:51 AM, 赵 思晨 <zsc19940...@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. > > Best Regards > > Sichen Zhao > > > 发自 Outlook > ________________________________ > 发件人: devel <devel-boun...@rtems.org> 代表 Christian Mauderer > <christian.maude...@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.maude...@embedded-brains.de>; >> *发送时间:* 2017年3月21日(星期二) 下午4:33 >> *收件人:* "joel"<j...@rtems.org>; >> *抄送:* "RTEMS"<devel@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.maude...@embedded-brains.de >>> <mailto:christian.maude...@embedded-brains.de>> wrote: >>> >>> ----- Ursprüngliche Mail ----- >>> > Von: "赵 思晨" <zsc19940...@outlook.com >>> <mailto:zsc19940...@outlook.com>> >>> > An: "RTEMS" <devel@rtems.org <mailto:devel@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@rtems.org <mailto:devel@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.maude...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > -- > -------------------------------------------- > embedded brains GmbH > Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
