<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Tue, May 26, 2020 at 11:26 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de">oss@c-mauderer.de</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Niteesh,<br>
<br>
On 25/05/2020 11:20, Niteesh G. S. wrote:<br>
> Hello,<br>
> <br>
> I have completed the porting of the OFW code from FreeBSD to RTEMS.<br>
> I do acknowledge the fact that we haven't decided on the directory for files<br>
> to be placed in. The previous conversation had stopped quite a while ago.<br>
> Christian suggested I work on the patch since that would also start the<br>
> conversation again and also refactoring the patch to the correct directory<br>
> will not be much of work.<br>
> <br>
> cpukit/libfreebsd was suggested as one of the directories to place the<br>
> ported<br>
> FreeBSD files. It is suggested to place all the source files under this<br>
> directory.<br>
> Since this will make the sync part easier. But this causes issues when<br>
> porting<br>
> BSP dependent files. Since RTEMS currently doesn't allow files in cpukit to<br>
> reference bsp headers. I faced a similar issue during my porting process<br>
> also.<br>
> The OFW init function require bsp_fdt_get function to get a reference to<br>
> the fdt<br>
> blob. But I can't include the bsp/fdt.h header file from a source file<br>
> under cpukit.<br>
> We must decide the directory quickly because my project will import other<br>
> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.<br>
<br>
Do you have a suggestion for another directory?<br>
<br>
If cpukit makes problems (which it clearly does due to the BSP<br>
dependencies) maybe something in bsps/shared?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The more organized way, in my opinion, will be to have the source files</div><div class="gmail_default" style="font-size:small">in their respective directories. This is would make more sense than having</div><div class="gmail_default" style="font-size:small">all source files under a single directory. But as discussed in the previous</div><div class="gmail_default" style="font-size:small">mailing list using this approach will make it harder for the person writing</div><div class="gmail_default" style="font-size:small">the sync script. I also have no idea of what complexity goes behind such</div><div class="gmail_default" style="font-size:small">a script. So points from the person who's most probably going to write the</div><div class="gmail_default" style="font-size:small">script will be really important.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> <a href="https://github.com/gs-niteesh/rtems/commits/ofw_branch" rel="noreferrer" target="_blank">https://github.com/gs-niteesh/rtems/commits/ofw_branch</a><br>
<br>
For small patches it would be better to send them to the list using "git<br>
send-email". That allows to comment directly on the patches. But in this<br>
case using a repo is OK because especially the import is quite big.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Once we have a decent enough patch I'll send it to the mailing list. </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'll add comments for small stuff directly on github. I hope that works ;-)<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> Please have a look at the last 6 patches for the ported work.<br>
> Below is a short summary of the patch.<br>
> * The openfirm.h is the OF interface that will provided to the user.<br>
> * The openfirm.c contains the function definition for openfirm.h. The<br>
> functions<br>
> call the respective OFW_* functions which are responsible for choosing<br>
> the correct implementation for OF interface.<br>
> * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto<br>
> generated<br>
> header in FreeBSD which choose the correct OF implementation(ofw_fdt,<br>
> ofw_std,<br>
> ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation as<br>
> suggested by Sebastian.<br>
> * ofw_fdt.c contains the fdt implementation of OF interface.<br>
> <br>
> Thanks,<br>
> Niteesh.<br>
> <br>
</blockquote></div></div>