Am 21.03.2017 um 18:35 schrieb Gedare Bloom: > 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. >
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-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 -- -------------------------------------------- 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
