Hi all, Christian and I had a talk about this discussion. The thing is: one of our customers does require WPA support rather soon, therefore (most likely) we will do a first implementation/port within the next 2-3 months. We are not yet sure whether the results are fit enough to be published at once, but in the long term WPA support would then be available for RTEMS.
I hate the idea of two concurrent implementations of the same functionality. I also hate the idea of having a GSOC project being of no use for RTEMS (this is a wast of creativity and if I were the student, I would regard it quite frustrating). So if you find different BBB areas which still need driver support, this would IMHO make more sense. But please observe: this is just my personal opinion. Maybe others also have some thoughts on this? wkr, Thomas. Am 22.03.2017 um 09:26 schrieb 赵 思晨: > Hi Christian Mauderer ,Hi Gedare Bloom: > > I think i can add the porting wpa to my proposal, and it will be the > last part of my GSOC goal. > 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 > best. > What do you think so? > > Best Regards > > Sichen Zhao > > > From Outlook <http://aka.ms/weboutlook> > > > ------------------------------------------------------------------------ > *发件人:* Christian Mauderer <christian.maude...@embedded-brains.de> > *发送时间:* 2017年3月22日 16:07 > *收件人:* Gedare Bloom; 赵 思晨 > *抄送:* 赵思晨; devel > *主题:* Re: 答复: 回复： GSOC 2017 Beagleboard BSP projects > > 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 > -- -------------------------------------------- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 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
