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
