<div dir="ltr">I have gone through the details of the project <a href="https://devel.rtems.org/ticket/2904" target="_blank">adding memory protection</a> using MMU and have a few questions and observations regarding the same-<div><br></div><div>1. Is this a project for which someone from the community would be willing to mentor for GSoC?</div><div>2. As far I could understand by looking into the rtems tree ARM uses static initialization wherein it first invalidates the cache and TLB blocks and then performs initialization by setting up a 1 to 1 mapping of the parts of address space. According to me, static initialization of the mmu is a generic enough method that can be utilized in most of the architectures.</div><div>3. For the thread stack protection, I believe either of the stack guard protection approach or by verification of stack canaries whereby the OS on each context switch would check whether the numbers associated with the canaries are still intact or not are worth considering. Although I still only have a high-level idea of both of these approaches and will be looking into their implementation details, I would request your kind feedback on it.</div><div><br></div><div>Regards,</div><div>Utkarsh Rai.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 21, 2020 at 10:28 PM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com">utkarsh.rai60@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks, I will check it out.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 21, 2020 at 12:56 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 18, 2020 at 12:45 PM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
><br>
> Based on your feedback,  adding memory protection or enhancing Wi-fi Support in libbsd are two projects that I would like to work upon.<br>
><br>
> For MMU support I think a lot unmerged PowerPC code is already present, but since  I would be using BBB I would only be able to use that as a reference. Is it feasible to start it from scratch?<br>
><br>
The state-of-the-art has advanced in the rtems.git tree since these<br>
projects happened, and it is not all documented. The ARM in particular<br>
generally uses a static initialization or boot-time initialization of<br>
the MMU. You  should study how the ARM approach works in the RTEMS<br>
main repo, and consider whether that approach can be adopted by other<br>
architectures/BSPs, how to improve that approach, and how to build<br>
higher-level services on top of the low-level BSP support that exists.<br>
<br>
One of the main interesting applications is to provide thread stack protection.<br>
<br>
> For Wi-Fi support, I would require an RTL8188 USB dongle along with JTAG for debugging purposes. I am not quite sure about how to handle the 'hot-plugging' case in this project it would be very helpful if someone could point me in the right direction.<br>
><br>
I can't speak to the WiFi support, maybe others know. But to get<br>
started you would need to at least demonstrate that you have the<br>
necessary hardware to succeed and that you can at a minimum boot/run<br>
BBB with libbsd, and probably we should like you to show that you can<br>
generate patches for libbsd.<br>
<br>
Gedare<br>
<br>
><br>
> On Tue, Feb 18, 2020 at 1:21 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>><br>
>> On Mon, Feb 17, 2020 at 9:42 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
>>><br>
>>> Hello everyone,<br>
>><br>
>> Hello Utkarsh Rai,<br>
>><br>
>>><br>
>>> I would like to contribute to the Beagleboard BSP project, in particular towards the improvement of the peripheral support. I have a few questions pertaining to the same:-<br>
>>><br>
>>> 1. Is adding support for Ethernet and USB a reasonable goal for the duration of the GSOC?<br>
>>><br>
>>> 2. FreeBSD has support for Ethernet and USB  can we port that to libbsd?<br>
>>><br>
>>> 3. What are the deliverables for this project, for instance, would I be required to add shell support for these peripherals or maybe an example app?<br>
>>><br>
>>> I have also attached a screenshot of the changed  'hello world' program along with this email<br>
>><br>
>> Thanks. It is nice to see that you already ran it successfully on the BBB.<br>
>><br>
>> As of now, the BBB has quite mature support including Ethernet and USB. There is another student actively working on a proposal to expand our BBB support a bit further. I'm not certain if there is sufficient work/interest/mentoring available to support multiple BBB projects. You might consider what specific projects would interest you though. You should take a look at past years' GSoC projects documented on our wiki, they are linked from our main 'GSoC' page.<br>
>><br>
>> There are also lots of interesting projects that can be done in a BSP-agnostic way, but still could be valuable to test with the BBB. The most important aspect about doing development with a BBB is that you can use the JTAG, which requires some soldering and additional effort to work with a standalone JTAG debugger.  If you don't have that, and want to work with the BBB, it is highly recommended.<br>
>><br>
>><br>
>>><br>
>>> _______________________________________________<br>
>>> devel mailing list<br>
>>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>
</blockquote></div>