A virtio front-end driver for RTEMS
Hi, I am a graduate student of System Software Lab at Konkuk University (http://sslab.konkuk.ac.kr). We are implementing a virtio front-end network driver for RTEMS and have published some preliminary results in ACM SIGBED Review (http://sigbed.seas. upenn.edu/archives/2016-01/EWiLi15_5.pdf). The current version of our implementation runs quite stably with RTEMS-pc386 over KVM hypervisor (linux 3.18.0). Now we are trying to make it work over VirtualBox. If the RTEMS community is interested in our work, wed like to open the source codes and contribute to RTEMS. However, currently, we are not sure whether our virtio driver is better to be incorporated in an RTEMS source branch or to be managed separately through our own GitHub for example. Please give your advice. with best regards, Jin-Hyun ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC 2016
Hi, Thanks for informing. Another interesting idea on which I would like to work upon, from the Ideas page is "Unified Interrupts and Devices" . In case this project is already assigned to someone please suggest me the project which I can pick up, and can get started with. Regarding my skills, I have good knowledge of GNU/Linux environment, operating system related things like Processes, CPU Scheduling, System calls, Concurrency and Threading, Locking mechanisms, File systems etc and also I have implemented custom syscalls in xv6 os. I have experience in programming languages like C, C++, Python, JavaScript and have a good algorithmic background. Regards On Tue, Mar 8, 2016 at 8:59 AM, Gedare Bloom wrote: > Hi Animesh, > > I think the condition variables will be fixed by another developer > (Sebastian Huber). Any other projects catch your eye? > > On Sat, Mar 5, 2016 at 5:31 AM, animesh pathak > wrote: > > Hello everyone, > > I am Animesh Chandra Pathak. > > I am pursuing my BTech in Computer Science at IIIT Hyderabad. > > I am interested in working with RTEMS as a part of Google summer of code > > 2016 project. > > > > I have successfully completed the Getting Started part as mentioned in > the > > quick start and modified the hello world programme. Now when I am trying > to > > compile the network-demos, I am getting "error: too few arguments to > > function 'mg_start' ". How should I do to compile this ? > > Screenshot is attached. > > > > I want to work on the "Implement Classic API and supercore condition > > variables" as a part of Google summer of code project. > > > > what should I do before applying for Google summer of code ? > > > > ___ > > 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: BBB GSoC Projects was Re: Gsoc 2016 project proposal
On Sun, Mar 6, 2016 at 8:54 PM, punit vara wrote: > > > On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah > wrote: > >> Hello Punit and all, >> >> According to me, Punit you must have completed some gpio test through >> gpio API that was merged last year. So till the final result of accepted >> student you can start working with PWM driver that plays an important role >> for any embedded project. This would be a good kick-start for you as well >> as a strong reason to showcase in your proposal. Try to give hardware test >> and post the video if possible. >> >> Coming to further I2C and SPI can be next milestones. To me these should >> be at the highest priorities. I had done I2C driver but was not able to >> make the hardware test. So you can also refer that and come up with the >> output along with best modifications. >> >> Next target you can set for SPI after both drivers are tested and >> committed. >> >> For the references you can always have a loot at code of GPIO >> API,MINIX,FreeBSD for BBB drivers. >> >> Any suggestions ? >> >> In case of any queries you can always ping. >> >> Cheers, >> Ketul >> >> On 5 March 2016 at 01:02, Marcos Díaz > > wrote: >> >>> We use I2c but using drivers from TI's baremetal drivers they provide in >>> their StarterWare software suite. >>> So, currently we cannot commit that into RTEMS. >>> But those drivers should be very useful to port to RTEMS. >>> >>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill wrote: >>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz < marcos.d...@tallertechnologies.com> wrote: > > > On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill wrote: > >> >> >> On Wed, Mar 2, 2016 at 1:41 PM, punit vara >> wrote: >> >>> Yes I have checked previous year work of ketul . He has done ADC and >>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked >>> rtems.git and I am not sure about I2C .I asked last year student Ketul >>> .According to him , I2c is also need to be modified. I tried to contact >>> Ben >>> but he is unreachable on mailing list :-( >>> >>> >> Let me reach out to Ketul and see if a private ping helps. >> >> Start with the assumption that USB needs work. That involves the >> rtems-libbsd tree and >> there is likely code to import from FreeBSD that will help a lot. >> >> SPI and i2c are close to one another in my understanding. Likely >> Ketul is referring to changes >> in the RTEMS i2c interfaces. >> >> My recollection is that the NIC had performance issues based on the >> version of U-Boot >> used. There was some traffic at the end of GSoC about this. I don't >> know if it was >> ever resolved. But the NIC should work. Maybe worth benchmarking. >> > We had more of these problems when trying to use I2C. It was fixed in > > https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764. > I think we dont need tos ee these problems any more > >> >> Marcos.. does this mean that the BBB i2c is complete now? And is my understanding that this covers SPI correct? What else on the BBB is left? --joel > --joel >> >> >> On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill >>> wrote: >>> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary < heshamelmat...@gmail.com> wrote: > Hi Punit, > > You can have a look at the open projects here [1] and find one or > more > that match your experience/interests. > > [1] https://devel.rtems.org/wiki/Developer/OpenProjects > > I have added Ben Gras. He knows more about the BBB than anyone. I am unsure what is left to do. Have you compared the status of last year's projects versus the git repository? --joel > Regards, > > On Wed, Mar 2, 2016 at 7:14 PM, punit vara > wrote: > > I have asked for BBB BSP proposal before but I haven't found > any good > > response from someone. What are the projects you are going to > mentor @joel ? > > Would anyone please suggest me to pick any other project ? > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > Hesham > ___ > 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: x86_64 BSP as GSOC2016 project
Hi Joel, On Tue, Mar 1, 2016 at 5:40 AM, Joel Sherrill wrote: > > > On Mon, Feb 29, 2016 at 2:00 PM, Saket Sinha > wrote: >> >> On Tue, Mar 1, 2016 at 1:14 AM, Saket Sinha >> wrote: >> > Hi, >> > >> > Congratulations to the coreboot team for selection in GSOC 2016. >> >> Sorry for the typo. I meant the RTEMS team. I worked for Coreboot last >> year so still relate to with GSOC everytime mistakenly. >> >> > >> > I am interested in working on x86_64 BSP as GSOC2016 project with >> > RTEMS and with initial guidance from Joel as to how to get started, I >> > am working on the same. >> > > Great! This is a nice project we need. > > Have you done the RTEMS GSoC hello world project? > Yes. I am done with that. > The x86_64 now has tools for 4.12. It needs a port and a BSP. The BSP can > share > with the pc386 but we likely have to address the dependency on legacy > hardware. > Some of those issues are captured in the pc386 project page. I have started > to try > to fix the dependency on legacy PCI BIOS but there is more like APIC support > and > device probes. > I have tried building x86_64 with RTEMS source builder just to verify where we are. Now my question in how to test it? Do you want me to run it on a real x86_64 hardware or qemu-x86_64 would be enough to test it ? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
