Re: 回复： GSOC 2017 Beagleboard BSP projects
Christian Mauderer
christian.mauderer at embedded-brains.de
Tue Mar 21 13:21:44 UTC 2017
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.mauderer at embedded-brains.de>;
> *发送时间:* 2017年3月21日(星期二) 下午4:33
> *收件人:* "joel"<joel at rtems.org>;
> *抄送:* "RTEMS"<devel at 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.mauderer at embedded-brains.de
>> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>>
>> ----- Ursprüngliche Mail -----
>> > Von: "赵 思晨" <zsc19940506 at outlook.com
>> <mailto:zsc19940506 at outlook.com>>
>> > An: "RTEMS" <devel at rtems.org <mailto:devel at 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 at rtems.org <mailto:devel at 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.mauderer at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at 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.
More information about the devel
mailing list