Re: 答复: 回复： GSOC 2017 Beagleboard BSP projects

[Christian Mauderer]

Am 21.03.2017 um 18:35 schrieb Gedare Bloom:
> On Tue, Mar 21, 2017 at 9:51 AM, 赵 思晨  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  代表 Christian Mauderer
>> 
>> 发送时间: 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";;
>>> *发送时间:* 2017年3月21日(星期二) 下午4:33
>>> *收件人:* "joel";
>>> *抄送:* "RTEMS";
>>> *主题:* 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
 >>> > wrote:

 - Ursprüngliche Mail -
 > Von: "赵 思晨" >>> >
 > An: "RTEMS" 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>
 >
 > ___
 > devel mailing list
 > devel@rtems.org 
 > 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 fo

答复: 答复: 回复： GSOC 2017 Beagleboard BSP projects

[赵 思晨]

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



发件人: Christian Mauderer 
发送时间: 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, 赵 思晨  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  代表 Christian Mauderer
>> 
>> 发送时间: 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";;
>>> *发送时间:* 2017年3月21日(星期二) 下午4:33
>>> *收件人:* "joel";
>>> *抄送:* "RTEMS";
>>> *主题:* 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
 >>> > wrote:

 - Ursprüngliche Mail -
 > Von: "赵 思晨" >>> >
 > An: "RTEMS" 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
 >
 >
 >
 >
 

Re: 答复: 答复: 回复： GSOC 2017 Beagleboard BSP projects

[Thomas Doerfler]

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 
> 
> 
> 
> *发件人:* Christian Mauderer 
> *发送时间:* 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, 赵 思晨  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  代表 Christian Mauderer
>>> 
>>> 发送时间: 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";;
 *发送时间:* 2017年3月21日(星期二) 下午4:33
 *收件人:* "joel";
 *抄送:* "RTEMS";
 *主题:* 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
>  > wrote:
>
> - Ursprüngliche Mail -
> > Von: "赵 思晨"  >
> > An: "RTEMS" 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
> netwo

Re: [PATCH v3 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Sebastian Huber]

Thanks, I checked it in as:

https://git.rtems.org/rtems/commit/?id=1c6926c11f2e5efcb166c668b097d64a0321d66e

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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

Re: Interested in GSoC 2017 Project: Memory Protection.

[Abhimanyu Rawat]

On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom  wrote:

> Please prefer to try to keep general GSoC / RTEMS project discussions on
> the mailing list. Direct e-mail is ok but inefficient in many cases and
> should only be preferred for communciations of a personal or private matter.
>
> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat <
> h2015...@pilani.bits-pilani.ac.in> wrote:
>
>>
>> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom  wrote:
>>
>>>
>>>
>>> On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat <
>>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>>
 Hello Dr. Bloom,

 Sorry for writing after a big gap( was busy with a product
 integration), although I found time to go through the pointers you put
 together for me, thanks they were really helpful in getting an idea about
 the project and how to process everything in time.

 Gaps are normal and acceptable (until you are getting paid for work
>>> :)). You should also expect to have gaps in responses from developers on
>>> the mailing list, since we are also generally volunteering.
>>>
>>>
 I noticed that all the existing work on MMU is not moving very fast
 like other supporting components for RTEMS, last year too no one was
 selected to do MMU project #2904. I know only one guy applied but the
 proposal was not quite promising. But trust me, all that doesn't make it
 any less desirable for me to take it. Now, I have a few questions:

 I would not recommend judging the priority/value of a proposed project
>>> based on whether or not it was done in the past. Definitely discuss with
>>> mentors, etc. This project area is a good, long-term investment for RTEMS,
>>> but it does move slowly.
>>>
>>>

 On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom  wrote:

>
>
> On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat <
> h2015...@pilani.bits-pilani.ac.in> wrote:
>
>> Hello folks,
>>
>> I am Abhimanyu Rawat, a Computer Science Masters degree student from
>> BITS Pilani Campus, India. I found Memory Protection project #2904
>>  very interesting and vital for
>> the the RTEMS. Among the lots of projects listed on the ideas page, 
>> Memory
>> Protection draws me to RTEMS as it's a very challenging project and I 
>> would
>> thoroughly enjoy working on it. I am a really enthusiastic person who 
>> would
>> like to contribute to the project. I have previous experience in C, C++ 
>> and
>> Python etc.  At present I am an intern at EMC ^2 where I am working on
>> DataDomain Operating system, building configuration tool for the latest
>> DDOS software update. I have also lead a BITS-Stanford inter-university
>> project, where my team worked on Django based project with an inbuilt
>> authorization tool + chat application etc. I usually help my friends with
>> their projects as well.
>>
>> When does your internship complete, and when does your school year
> begin again?
>
>
>> As required, I went through the initial brief about the project and I
>> think it would be a valuable addition to RTEMS. Also, I have completed 
>> the
>> https://devel.rtems.org/wiki/GSoC/GettingStarted, and configured and
>> Built RTEMS for SPARC/erc32. Subsequently, I have the snapshot of the
>> terminal showing my name and the GSOC text as pictured here
>> .
>> Kindly tell me how  selectively pointed towto send the proof of the
>> terminal and the diff file as required.
>>
>> Send to me by email is fine.
>
>
>> It would be great if you can give me some pointers about the
>> structure of the project and the direction I should pursue.
>>
>> Have a look at the current approach taken to provide low-level
> support for the MMUs in the ARM bsps. You can find this looking in the
> source tree via c/src/lib/libbsp/arm/* with most of the relevant parts in
> the shared subdirectory there, where each BSP defines a table of
> statically-configured MMU initialization.
>

 You selectively pointed towards the c/src/lib/libbsp/arm/* shared
 subdirectory where some BSP's has low level code for MMU configuration, I
 found ome cache code too. And trying digging deep to build a common
 understanding of different BSP MMU code. The code initally is quite hard to
 understand but as a unit what task is taking place is I can understand
 like, data cache and line cleaing etc. Therefore I would request you to
 provide me a documented code review or process guide( if available) so
 that I can develop something to test the MMU code changes/patches,
 otherwise I will have to brute force the search. As from this point I want
 to move fast and reflect the my progress.

>
>
 I

Re: Interested in GSoC 2017 Project: Memory Protection.

[Joel Sherrill]

I may have missed this but Gedare has been working on adding
the mmap/shm services from POSIX. It would be nice for the
dynamic changes interface he mentioned to have an interface
to these calls. I am sure Gedare has thought of how this would
work already. :)

--joel

On Thu, Mar 9, 2017 at 1:14 PM, Abhimanyu Rawat <
h2015...@pilani.bits-pilani.ac.in> wrote:

> Hello folks,
>
> I am Abhimanyu Rawat, a Computer Science Masters degree student from BITS
> Pilani Campus, India. I found Memory Protection project #2904
>  very interesting and vital for the
> the RTEMS. Among the lots of projects listed on the ideas page, Memory
> Protection draws me to RTEMS as it's a very challenging project and I would
> thoroughly enjoy working on it. I am a really enthusiastic person who would
> like to contribute to the project. I have previous experience in C, C++ and
> Python etc.  At present I am an intern at EMC ^2 where I am working on
> DataDomain Operating system, building configuration tool for the latest
> DDOS software update. I have also lead a BITS-Stanford inter-university
> project, where my team worked on Django based project with an inbuilt
> authorization tool + chat application etc. I usually help my friends with
> their projects as well.
>
> As required, I went through the initial brief about the project and I
> think it would be a valuable addition to RTEMS. Also, I have completed the
> https://devel.rtems.org/wiki/GSoC/GettingStarted, and configured and
> Built RTEMS for SPARC/erc32. Subsequently, I have the snapshot of the
> terminal showing my name and the GSOC text as pictured here
> .
> Kindly tell me how to send the proof of the terminal and the diff file as
> required.
>
> It would be great if you can give me some pointers about the structure of
> the project and the direction I should pursue.
>
> Overall, I look forward to working with the community and improving my
> skills by actively contributing to the project(in long run also).
>
> *Closing with thank you and warm Regards,*
>
> *Abhimanyu Rawat*
> *M.E. Computer Science, *
> *CS/IS Department, BITS Pilani, Pilani Campus*
> *Email - h2015...@pilani.bits-pilani.ac.in
>  / abhimanyura...@yahoo.com
> *
> *Phone. 08930399302 (call/Whatsapp), 09466899302*
>
>  ▄
> ᐧ
>
> ___
> 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

Re: Interested in GSoC 2017 Project: Memory Protection.

[Abhimanyu Rawat]

Hello Dr. Joel,

Dr. Bloom obviously have this approach lined up, and that is why he advised
me to go work on the low level support for some more bsp's in order to
start supporting a firm MMU/MPU interface to applications running. I guess
now I need to support more bsp's in order to get to a pragmatic design for
intermediate layers.

Cheers,
Abhimanyu


On 22 Mar 2017 20:12, "Joel Sherrill"  wrote:

I may have missed this but Gedare has been working on adding
the mmap/shm services from POSIX. It would be nice for the
dynamic changes interface he mentioned to have an interface
to these calls. I am sure Gedare has thought of how this would
work already. :)

--joel

On Thu, Mar 9, 2017 at 1:14 PM, Abhimanyu Rawat <
h2015...@pilani.bits-pilani.ac.in> wrote:

> Hello folks,
>
> I am Abhimanyu Rawat, a Computer Science Masters degree student from BITS
> Pilani Campus, India. I found Memory Protection project #2904
>  very interesting and vital for the
> the RTEMS. Among the lots of projects listed on the ideas page, Memory
> Protection draws me to RTEMS as it's a very challenging project and I would
> thoroughly enjoy working on it. I am a really enthusiastic person who would
> like to contribute to the project. I have previous experience in C, C++ and
> Python etc.  At present I am an intern at EMC ^2 where I am working on
> DataDomain Operating system, building configuration tool for the latest
> DDOS software update. I have also lead a BITS-Stanford inter-university
> project, where my team worked on Django based project with an inbuilt
> authorization tool + chat application etc. I usually help my friends with
> their projects as well.
>
> As required, I went through the initial brief about the project and I
> think it would be a valuable addition to RTEMS. Also, I have completed the
> https://devel.rtems.org/wiki/GSoC/GettingStarted, and configured and
> Built RTEMS for SPARC/erc32. Subsequently, I have the snapshot of the
> terminal showing my name and the GSOC text as pictured here
> .
> Kindly tell me how to send the proof of the terminal and the diff file as
> required.
>
> It would be great if you can give me some pointers about the structure of
> the project and the direction I should pursue.
>
> Overall, I look forward to working with the community and improving my
> skills by actively contributing to the project(in long run also).
>
> *Closing with thank you and warm Regards,*
>
> *Abhimanyu Rawat*
> *M.E. Computer Science, *
> *CS/IS Department, BITS Pilani, Pilani Campus*
> *Email - h2015...@pilani.bits-pilani.ac.in
>  / abhimanyura...@yahoo.com
> *
> *Phone. 08930399302 (call/Whatsapp), 09466899302*
>
>  ▄
> ᐧ
>
> ___
> 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

Re: Interested in GSoC 2017 Project: Memory Protection.

[Gedare Bloom]

On Wed, Mar 22, 2017 at 10:41 AM, Joel Sherrill  wrote:

> I may have missed this but Gedare has been working on adding
> the mmap/shm services from POSIX. It would be nice for the
> dynamic changes interface he mentioned to have an interface
> to these calls. I am sure Gedare has thought of how this would
> work already. :)
>
> We need to walk before we run. I want to see something supported at the hw
level so we can provide higher-level protection (including mmap-style).


> --joel
>
> On Thu, Mar 9, 2017 at 1:14 PM, Abhimanyu Rawat <
> h2015...@pilani.bits-pilani.ac.in> wrote:
>
>> Hello folks,
>>
>> I am Abhimanyu Rawat, a Computer Science Masters degree student from BITS
>> Pilani Campus, India. I found Memory Protection project #2904
>>  very interesting and vital for the
>> the RTEMS. Among the lots of projects listed on the ideas page, Memory
>> Protection draws me to RTEMS as it's a very challenging project and I would
>> thoroughly enjoy working on it. I am a really enthusiastic person who would
>> like to contribute to the project. I have previous experience in C, C++ and
>> Python etc.  At present I am an intern at EMC ^2 where I am working on
>> DataDomain Operating system, building configuration tool for the latest
>> DDOS software update. I have also lead a BITS-Stanford inter-university
>> project, where my team worked on Django based project with an inbuilt
>> authorization tool + chat application etc. I usually help my friends with
>> their projects as well.
>>
>> As required, I went through the initial brief about the project and I
>> think it would be a valuable addition to RTEMS. Also, I have completed the
>> https://devel.rtems.org/wiki/GSoC/GettingStarted, and configured and
>> Built RTEMS for SPARC/erc32. Subsequently, I have the snapshot of the
>> terminal showing my name and the GSOC text as pictured here
>> .
>> Kindly tell me how to send the proof of the terminal and the diff file as
>> required.
>>
>> It would be great if you can give me some pointers about the structure of
>> the project and the direction I should pursue.
>>
>> Overall, I look forward to working with the community and improving my
>> skills by actively contributing to the project(in long run also).
>>
>> *Closing with thank you and warm Regards,*
>>
>> *Abhimanyu Rawat*
>> *M.E. Computer Science, *
>> *CS/IS Department, BITS Pilani, Pilani Campus*
>> *Email - h2015...@pilani.bits-pilani.ac.in
>>  / abhimanyura...@yahoo.com
>> *
>> *Phone. 08930399302 (call/Whatsapp), 09466899302*
>>
>>  ▄
>> ᐧ
>>
>> ___
>> 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

Re: Interested in GSoC 2017 Project: Memory Protection.

[Gedare Bloom]

On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat <
h2015...@pilani.bits-pilani.ac.in> wrote:

>
> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom  wrote:
>
>> Please prefer to try to keep general GSoC / RTEMS project discussions on
>> the mailing list. Direct e-mail is ok but inefficient in many cases and
>> should only be preferred for communciations of a personal or private matter.
>>
>> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat <
>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>
>>>
>>> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom  wrote:
>>>


 On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat <
 h2015...@pilani.bits-pilani.ac.in> wrote:

> Hello Dr. Bloom,
>
> Sorry for writing after a big gap( was busy with a product
> integration), although I found time to go through the pointers you put
> together for me, thanks they were really helpful in getting an idea about
> the project and how to process everything in time.
>
> Gaps are normal and acceptable (until you are getting paid for work
 :)). You should also expect to have gaps in responses from developers on
 the mailing list, since we are also generally volunteering.


> I noticed that all the existing work on MMU is not moving very fast
> like other supporting components for RTEMS, last year too no one was
> selected to do MMU project #2904. I know only one guy applied but the
> proposal was not quite promising. But trust me, all that doesn't make it
> any less desirable for me to take it. Now, I have a few questions:
>
> I would not recommend judging the priority/value of a proposed project
 based on whether or not it was done in the past. Definitely discuss with
 mentors, etc. This project area is a good, long-term investment for RTEMS,
 but it does move slowly.


>
> On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom 
> wrote:
>
>>
>>
>> On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat <
>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>
>>> Hello folks,
>>>
>>> I am Abhimanyu Rawat, a Computer Science Masters degree student from
>>> BITS Pilani Campus, India. I found Memory Protection project #2904
>>>  very interesting and vital
>>> for the the RTEMS. Among the lots of projects listed on the ideas page,
>>> Memory Protection draws me to RTEMS as it's a very challenging project 
>>> and
>>> I would thoroughly enjoy working on it. I am a really enthusiastic 
>>> person
>>> who would like to contribute to the project. I have previous experience 
>>> in
>>> C, C++ and Python etc.  At present I am an intern at EMC ^2 where I am
>>> working on DataDomain Operating system, building configuration tool for
>>> the latest DDOS software update. I have also lead a BITS-Stanford
>>> inter-university project, where my team worked on Django based project 
>>> with
>>> an inbuilt authorization tool + chat application etc. I usually help my
>>> friends with their projects as well.
>>>
>>> When does your internship complete, and when does your school year
>> begin again?
>>
>>
>>> As required, I went through the initial brief about the project and
>>> I think it would be a valuable addition to RTEMS. Also, I have completed
>>> the https://devel.rtems.org/wiki/GSoC/GettingStarted, and
>>> configured and Built RTEMS for SPARC/erc32. Subsequently, I have the
>>> snapshot of the terminal showing my name and the GSOC text as pictured
>>> here
>>> .
>>> Kindly tell me how  selectively pointed towto send the proof of the
>>> terminal and the diff file as required.
>>>
>>> Send to me by email is fine.
>>
>>
>>> It would be great if you can give me some pointers about the
>>> structure of the project and the direction I should pursue.
>>>
>>> Have a look at the current approach taken to provide low-level
>> support for the MMUs in the ARM bsps. You can find this looking in the
>> source tree via c/src/lib/libbsp/arm/* with most of the relevant parts in
>> the shared subdirectory there, where each BSP defines a table of
>> statically-configured MMU initialization.
>>
>
> You selectively pointed towards the c/src/lib/libbsp/arm/* shared
> subdirectory where some BSP's has low level code for MMU configuration, I
> found ome cache code too. And trying digging deep to build a common
> understanding of different BSP MMU code. The code initally is quite hard 
> to
> understand but as a unit what task is taking place is I can understand
> like, data cache and line cleaing etc. Therefore I would request you to
> provide me a documented code review or process guide( if available)
> so tha

Re: Interested in GSoC 2017 Project: Memory Protection.

[Abhimanyu Rawat]

Indeed, PowerPC code is somewhat developed, would you recommend if there
are some specific features in PowerPC that I should revisit? As this is
little confusing as some work has been done on exception handler, page
tables, cache already, so what should I target next and what to modify
first? Past developer of the PowerPC support might help if you would
connect me to?
ᐧ

*Closing with thank you and warm Regards,*

*Abhimanyu Rawat*
*M.E. Computer Science, *
*CS/IS Department, BITS Pilani, Pilani Campus*
*Email - h2015...@pilani.bits-pilani.ac.in
 / abhimanyura...@yahoo.com
*
*Phone. 08930399302 (call/Whatsapp), 09466899302*

 ▄

On Wed, Mar 22, 2017 at 8:29 PM, Gedare Bloom  wrote:

>
>
> On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat <
> h2015...@pilani.bits-pilani.ac.in> wrote:
>
>>
>> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom  wrote:
>>
>>> Please prefer to try to keep general GSoC / RTEMS project discussions on
>>> the mailing list. Direct e-mail is ok but inefficient in many cases and
>>> should only be preferred for communciations of a personal or private matter.
>>>
>>> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat <
>>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>>

 On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom  wrote:

>
>
> On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat <
> h2015...@pilani.bits-pilani.ac.in> wrote:
>
>> Hello Dr. Bloom,
>>
>> Sorry for writing after a big gap( was busy with a product
>> integration), although I found time to go through the pointers you put
>> together for me, thanks they were really helpful in getting an idea about
>> the project and how to process everything in time.
>>
>> Gaps are normal and acceptable (until you are getting paid for work
> :)). You should also expect to have gaps in responses from developers on
> the mailing list, since we are also generally volunteering.
>
>
>> I noticed that all the existing work on MMU is not moving very fast
>> like other supporting components for RTEMS, last year too no one was
>> selected to do MMU project #2904. I know only one guy applied but the
>> proposal was not quite promising. But trust me, all that doesn't make it
>> any less desirable for me to take it. Now, I have a few questions:
>>
>> I would not recommend judging the priority/value of a proposed
> project based on whether or not it was done in the past. Definitely 
> discuss
> with mentors, etc. This project area is a good, long-term investment for
> RTEMS, but it does move slowly.
>
>
>>
>> On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom 
>> wrote:
>>
>>>
>>>
>>> On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat <
>>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>>
 Hello folks,

 I am Abhimanyu Rawat, a Computer Science Masters degree student
 from BITS Pilani Campus, India. I found Memory Protection project
 #2904  very interesting and
 vital for the the RTEMS. Among the lots of projects listed on the ideas
 page, Memory Protection draws me to RTEMS as it's a very challenging
 project and I would thoroughly enjoy working on it. I am a really
 enthusiastic person who would like to contribute to the project. I have
 previous experience in C, C++ and Python etc.  At present I am an 
 intern at
 EMC ^2 where I am working on DataDomain Operating system, building
 configuration tool for the latest DDOS software update. I have also 
 lead a
 BITS-Stanford inter-university project, where my team worked on Django
 based project with an inbuilt authorization tool + chat application 
 etc. I
 usually help my friends with their projects as well.

 When does your internship complete, and when does your school year
>>> begin again?
>>>
>>>
 As required, I went through the initial brief about the project and
 I think it would be a valuable addition to RTEMS. Also, I have 
 completed
 the https://devel.rtems.org/wiki/GSoC/GettingStarted, and
 configured and Built RTEMS for SPARC/erc32. Subsequently, I have the
 snapshot of the terminal showing my name and the GSOC text as pictured
 here
 .
 Kindly tell me how  selectively pointed towto send the proof of the
 terminal and the diff file as required.

 Send to me by email is fine.
>>>
>>>
 It would be great if you can give me some pointers about the
 structure of the project and the direction I should pursue.

 Have a look at the current approach taken to provide low-level
>

答复: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

[赵 思晨]

Hi Gedare Bloom, Hi Ben:


Latest news. I just modify the PV's i2c code these days, and now it can read 
the EEPROM preliminarily by the interrupt not the polling , it is the different 
way from my previously submitted work(the diff.patch). Without the read eeprom 
function and other not standardized funciton i created before.

And i will test and modify the code in the future to make sure it can works 
more normative.


Best Regards

Sichen Zhao




发自 Outlook

发件人: devel  代表 Gedare Bloom 
发送时间: 2017年3月22日 1:36:13
收件人: Ben Gras
抄送: devel@rtems.org
主题: Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the 
eeprom info.

On Tue, Mar 21, 2017 at 12:12 AM, Ben Gras  wrote:
> Dear all,
>
> SZ, great initiative. Gedare and Sebastian have commented.
>
> For my part, can I just check - the implementation is supposed to be
> generic to i2c devices, correct?
>
> If so, can you explain what read_eeprom is for? Is it just as demo? Is
> the code generic otherwise?
>
I believe PV used EEPROM to test his i2c implementation.

> Cheers,
>
> Ben
>
>
> On 03/14/2017 10:05 AM, Sichen Zhao wrote:
>> ---
>>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 
>> --
>>  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
>>  cpukit/dev/i2c/eeprom.c   |  24 +-
>>  testsuites/samples/i2c0/init.c|  98 -
>>  4 files changed, 777 insertions(+), 47 deletions(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
>> b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
>> index 6b790e5..6a22125 100644
>> --- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
>> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
>> @@ -21,11 +21,23 @@
>>  #include 
>>  #include 
>>
>> +#define u16 unsigned int
>> +
>> +static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
>> +static void omap24_i2c_init(i2c_bus *base);
>> +static void flush_fifo(i2c_bus *base);
>> +static int wait_for_bb(i2c_bus *base);
>> +static int omap24_i2c_probe(i2c_bus *base);
>> +static u16 wait_for_event(i2c_bus *base);
>> +static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, 
>> int alen, unsigned char *buffer,
>> +   int len);
>> +static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
>> +static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint 
>> addr,int alen, unsigned char *buffer,
>> +int len);
>>  /*
>>  static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>>  {
>>bool status =true;
>> -
>>  // We will check i2c_bus_id in am335x_i2c_bus_register
>>  // Apart from mode and pull_up register what about SCREWCTRL & RXACTIVE 
>> ??
>>if (bus->i2c_bus_id == I2C1) {
>> @@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>>  /* ref. Table 21-4 I2C Clock Signals */
>>  /*
>>   For I2C1/2
>> -
>>   Interface clock - 100MHz - CORE_LKOUTM4 / 2 - pd_per_l4ls_gclk
>> -
>>   Functional clock - 48MHz - PER_CLKOUTM2 / 4 - pd_per_ic2_fclk
>>  */
>>
>> @@ -74,7 +84,6 @@ state. Functional clocks are guarantied to stay present. 
>> As long as in
>>  this configuration, power domain sleep transition cannot happen.*/
>>   /* REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) |=
>>  AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE;
>> -
>>while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) &
>>AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE) != 
>> AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE);
>>  */
>> @@ -86,30 +95,29 @@ this configuration, power domain sleep transition cannot 
>> happen.*/
>>if (bus->i2c_bus_id == I2C1) {
>>REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) |=
>>   AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE;
>> -
>>while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) &
>>   AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE) != 
>> AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE);
>>} else if (bus->i2c_bus_id == I2C2) {
>>REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) |=
>>   AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE;
>> -
>>while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) &
>>   AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE) != 
>> AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE);
>> -
>>while(!(REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
>> (AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_L4LS_GCLK |
>>  AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_I2C_FCLK)));
>> -
>>}
>>  }
>>  */
>>
>>  static void am335x_i2c0_pinmux(bbb_i2c_bus *bus)
>>  {
>> -  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
>> +  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
>> AM335X_CONF_I2C0_SDA);
>> +  printf("bus->regs:%x\n", bus->regs);
>> +
>> +  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
>>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>>
>> -  REG(bus->regs + AM335X_CONF

Dates in the proposal templates

[Tanu Hari Dixit]

Hello all,

The dates in the "Proposed Schedule" section in the GSoC template
(https://devel.rtems.org/wiki/GSoC) are off by a few days, probably.
They are last year's dates, probably. There are three phases this time
as opposed to two halves for evaluation. Am I missing something? Can
somebody confirm?

Thanks,
Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Interested in GSoC 2017 Project: Memory Protection.

[Gedare Bloom]

On Wed, Mar 22, 2017 at 11:13 AM, Abhimanyu Rawat <
h2015...@pilani.bits-pilani.ac.in> wrote:

> Indeed, PowerPC code is somewhat developed, would you recommend if there
> are some specific features in PowerPC that I should revisit? As this is
> little confusing as some work has been done on exception handler, page
> tables, cache already, so what should I target next and what to modify
> first? Past developer of the PowerPC support might help if you would
> connect me to?
> ᐧ
>
> I've CC'd some of the folks who previously worked on this topic. So
perhaps they have input for you.

I think the important thing is that when we design a framework that it is
flexible enough to accommodate the many varieties of memory management
hardware.


> *Closing with thank you and warm Regards,*
>
> *Abhimanyu Rawat*
> *M.E. Computer Science, *
> *CS/IS Department, BITS Pilani, Pilani Campus*
> *Email - h2015...@pilani.bits-pilani.ac.in
>  / abhimanyura...@yahoo.com
> *
> *Phone. 08930399302 (call/Whatsapp), 09466899302*
>
>  ▄
>
> On Wed, Mar 22, 2017 at 8:29 PM, Gedare Bloom  wrote:
>
>>
>>
>> On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat <
>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>
>>>
>>> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom  wrote:
>>>
 Please prefer to try to keep general GSoC / RTEMS project discussions
 on the mailing list. Direct e-mail is ok but inefficient in many cases and
 should only be preferred for communciations of a personal or private 
 matter.

 On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat <
 h2015...@pilani.bits-pilani.ac.in> wrote:

>
> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom 
> wrote:
>
>>
>>
>> On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat <
>> h2015...@pilani.bits-pilani.ac.in> wrote:
>>
>>> Hello Dr. Bloom,
>>>
>>> Sorry for writing after a big gap( was busy with a product
>>> integration), although I found time to go through the pointers you put
>>> together for me, thanks they were really helpful in getting an idea 
>>> about
>>> the project and how to process everything in time.
>>>
>>> Gaps are normal and acceptable (until you are getting paid for work
>> :)). You should also expect to have gaps in responses from developers on
>> the mailing list, since we are also generally volunteering.
>>
>>
>>> I noticed that all the existing work on MMU is not moving very fast
>>> like other supporting components for RTEMS, last year too no one was
>>> selected to do MMU project #2904. I know only one guy applied but the
>>> proposal was not quite promising. But trust me, all that doesn't make it
>>> any less desirable for me to take it. Now, I have a few questions:
>>>
>>> I would not recommend judging the priority/value of a proposed
>> project based on whether or not it was done in the past. Definitely 
>> discuss
>> with mentors, etc. This project area is a good, long-term investment for
>> RTEMS, but it does move slowly.
>>
>>
>>>
>>> On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom 
>>> wrote:
>>>


 On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat <
 h2015...@pilani.bits-pilani.ac.in> wrote:

> Hello folks,
>
> I am Abhimanyu Rawat, a Computer Science Masters degree student
> from BITS Pilani Campus, India. I found Memory Protection project
> #2904  very interesting and
> vital for the the RTEMS. Among the lots of projects listed on the 
> ideas
> page, Memory Protection draws me to RTEMS as it's a very challenging
> project and I would thoroughly enjoy working on it. I am a really
> enthusiastic person who would like to contribute to the project. I 
> have
> previous experience in C, C++ and Python etc.  At present I am an 
> intern at
> EMC ^2 where I am working on DataDomain Operating system, building
> configuration tool for the latest DDOS software update. I have also 
> lead a
> BITS-Stanford inter-university project, where my team worked on Django
> based project with an inbuilt authorization tool + chat application 
> etc. I
> usually help my friends with their projects as well.
>
> When does your internship complete, and when does your school year
 begin again?


> As required, I went through the initial brief about the project
> and I think it would be a valuable addition to RTEMS. Also, I have
> completed the https://devel.rtems.org/wiki/GSoC/GettingStarted, and
> configured and Built RTEMS for SPARC/erc32. Subsequently, I have the
> snapshot of the terminal showing my name and the GSOC text as pictured
> here

Re: Dates in the proposal templates

[Gedare Bloom]

You aren't missing anything. I believe this is already mentioned that
you may need to adapt the template. Thanks.

On Wed, Mar 22, 2017 at 11:22 AM, Tanu Hari Dixit  wrote:
> Hello all,
>
> The dates in the "Proposed Schedule" section in the GSoC template
> (https://devel.rtems.org/wiki/GSoC) are off by a few days, probably.
> They are last year's dates, probably. There are three phases this time
> as opposed to two halves for evaluation. Am I missing something? Can
> somebody confirm?
>
> Thanks,
> Tanu Hari Dixit.
> ___
> 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

Re: Queries regarding Tracing related bugs and GSoC 2017

[Gedare Bloom]

On Sun, Mar 19, 2017 at 11:23 AM, vivek kukreja  wrote:
> Hello developers,
>
> I have worked on CTF tracing last year under GSoC. I was working on my
> previous deliverables and i noticed there are some bugs in the current
> capture and function tracing examples on qemu for arm/xilinx_zynq_a9,
> related to recent updates made to TCB and termios implementation. I'm
> working on resolving these issues so I can merge my previous changes.
> I have mailed Chris regarding this and I was suggested to ping the
> developer list for further clarification on these errors, and whether
> I should create any tickets.
>
Good. Probably you should have a ticket related to the project. Maybe
create a GSoC Project ticket.

> I also wanted to enquire about the status of the Live tracing project
> this year in GSoC. I'm considering the following ideas for a proposal,
> once the tracing support is re-established:
>
> 1. libDWARF integration: I've been studying libDWARF for
> functionalities that can be ported to RTEMS, for the purpose of
> finding function signatures and variable types to be traced by the
> trace linker. This can be used to auto-configure the signatures/types
> at the trace linking phase of an application.
>
> 2. Transports API: In GSoC 2016 I worked on transport for moving
> traces to host. I investigated serial and USB transport apart from
> ethernet using libBSD. There is discussion on the Tracing projects
> page about integrating all transports and providing an API for custom
> transports in the application for both capture and function tracing.
>
> 3. Live tracing: In capture tracing, the trace process has to be
> paused before reading the trace (as discussed with Jennifer Averrett,
> the previous contributor). I'm looking at alternatives like copying
> the unsafe buffer to a new one which can in turn be dumped on host
> using NFS or other transport options. We can create a low priority
> task for this purpose, along with the trace buffering functions
> defined in rtld-trace-buffer.ini.
>
> Please suggest any improvements or additions to the above ideas. Also
> I dont know if there is any interest in this project for GSoC 2017 but
> I would like to merge my previous changes soon nonetheless.
>
This continues to be an important area to support. I suspect a
"Transports API" would be a good beneficial project to scope out and
understand. Without Transports, it is hard to create a uniform
approach to live tracing that would work well across Architectures/BSP
families.

> Regards,
> Vivek
> ___
> 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

Re: Dates in the proposal templates

[Tanu Hari Dixit]

Hi Gedare,

Thank you for clarifying.

Regards,
Tanu Hari Dixit.

On Wed, Mar 22, 2017 at 8:59 PM, Gedare Bloom  wrote:
> You aren't missing anything. I believe this is already mentioned that
> you may need to adapt the template. Thanks.
>
> On Wed, Mar 22, 2017 at 11:22 AM, Tanu Hari Dixit  
> wrote:
>> Hello all,
>>
>> The dates in the "Proposed Schedule" section in the GSoC template
>> (https://devel.rtems.org/wiki/GSoC) are off by a few days, probably.
>> They are last year's dates, probably. There are three phases this time
>> as opposed to two halves for evaluation. Am I missing something? Can
>> somebody confirm?
>>
>> Thanks,
>> Tanu Hari Dixit.
>> ___
>> 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

Re: Large number of failures on leon3

[Jiri Gaisler]

On 03/21/2017 10:26 PM, Joel Sherrill wrote:
>
>
> On Tue, Mar 21, 2017 at 5:17 AM, Jiri Gaisler  > wrote:
>
> The culprit seems to be the CASA instruction. The leon3 bsp is
> built to always need this instruction, regardless if SMP is
> enabled or not. The sis simulator does not support CASA at the
> moment, hence the failures. The erc32 and leon2 bsp does not use
> CASA since the hardware does not support it. If the leon3 bsp is
> supposed to always require CASA, then it should be noted in the
> bsp documentation as not all leon3 hardware actually supports CASA.
>
>
> Hmmm... I let this sit so I could think. I wanted to make sure we didn't
> head down a path of needing another BSP variant or multilib variant
> unnecessarily.
>
> Where is this instruction used? I didn't see it in the port or BSP. But
> again "grep -i cas" has a LOT of output.
>
> Do all SMP configurations have CASA? 
>
> Is the instruction optional in uniprocessor configurations? If so, is
> there a case where you must use it in uniprocessor configurations?
>
> Is this something in gcc (atomics?) that needs to be more conditional
> on the CPU model? And.. could that push us to a multilib variant?
>
> Sorry for sounding confused. I just would like to understand when
> the instruction is present and which knob settings we have to set
> and how to know when it is OK to use.  So it starts with knowing
> when it is available in HW, when gcc might use it, etc.

The CASA (compare and swap) is present in the gcc multi-libbed libraries
such as libatomic.a and libsupc++.a. The CASA is only present when the
-mcpu=leon3 option is used, which is default for the leon3 bsp. So I
think that it would be sufficient to note in the documentation that the
default settings in the leon3 bsp requires support for CASA in the
hardware. By removing -mcpu=leon3 from CPU_FLAGS in the leon3.cfg, the
bsp can be built to work without CASA in the hardware. I have tested
this, and some tests that previously failed (e.g. cdtest.exe) then
worked OK on sis-leon3. I will however probably not work (well) with SMP.

Other tests (e.g. sp69.exe) still fails on sis-leon3, but this is a
problem in the leon3 port of sis and I am trying to fix it right now.

To simplify testing in the future, I have added support for CASA to the
leon3 port of sis. This makes it possible to test bsps both without CASA
(erc32 & leon2) and with CASA (leon3).

I will make new patches for sis once I have everything sorted...

Jiri.
>
> Thanks.
>
> --joel
>
> Jiri.
>
>
> On 03/19/2017 02:32 PM, Joel Sherrill wrote:
>> Hi
>>
>> I was following up on Gedare's testing and tried leon3. There
>> were a surprising number of failures there with SMP disabled.
>> This is testing with gdb. Does anyone else get the same 
>> results with qemu or tsim?  Any idea what's broken?
>>
>>
>> Passed:   458
>> Failed:20
>> Timeouts:  73
>> Invalid:3
>> -
>> Total:554
>>
>> Failures:
>>  cdtest.exe
>>  spintrcritical20.exe
>>  dl05.exe
>>  spintrcritical01.exe
>>  spintrcritical04.exe
>>  spintrcritical10.exe
>>  spintrcritical22.exe
>>  sp69.exe
>>  spintrcritical21.exe
>>  sp11.exe
>>  spintrcritical16.exe
>>  spintrcritical23.exe
>>  psxfile01.exe
>>  spintrcritical05.exe
>>  spintrcritical02.exe
>>  spintrcritical08.exe
>>  psxgetrusage01.exe
>>  spcpucounter01.exe
>>
>>
>>
>> ___
>> 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

GSOC 2017 beagleboard bsp project

[赵 思晨]

Hi all:

I already rephrase my proposal, remove the part" add the WLAN protocol 802.11", 
and add the "USB dongle support".

If any one has advice or question about my proposal, please email me.


Thank you

Best Regards

Sichen Zhao



from Outlook
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel