<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 1:22 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">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">Just to pile on, I have a small port of OFW underneath sparc64, it<br>
would be great to replace it. It might also provide some useful code,<br>
maybe.. Anyway, look at what it is using<span class="gmail_default" style="font-size:small">.</span></blockquote><div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Thanks for letting me know about this. It somewhat gives me a direction to</div><div class="gmail_default" style="font-size:small">head in. While going through the code, I came across ofw_call. I couldn't</div><div class="gmail_default" style="font-size:small">figure out how it works :(. I tried going through the assembly of the ofw function</div><div class="gmail_default" style="font-size:small">in ofwasm.S but the ABI of SPARC wasn't easy for me to go through. I am intrigued</div><div class="gmail_default" style="font-size:small">by how this function works. I also have the following doubts.</div><div class="gmail_default" style="font-size:small">What is ofw_cif used for? It is some kind of function pointer table?</div><div class="gmail_default" style="font-size:small">Does ofw_init initialize ofw_cif?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks,</div><div class="gmail_default" style="font-size:small">Niteesh.</div><br></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"><span class="gmail_default" style="font-size:small"></span> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, May 5, 2020 at 12:20 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a>> wrote:<br>
><br>
> Hello Niteesh,<br>
><br>
> On 05/05/2020 19:10, Niteesh G. S. wrote:<br>
> > This is thread is about implementing OFW functions in RTEMS as part<br>
> > of my GSoC project. I would like to start off with this part since the<br>
> > refactoring<br>
> > work will somewhat depend on this.<br>
><br>
> I'm not sure whether everyone on the list is already fully aware of what<br>
> your project is. For some of us the GSoC preparation phase is more of a<br>
> background noise. So maybe you want to give a short (only a few<br>
> sentences) overview of your target and what is the gain for the RTEMS<br>
> project.<br>
><br>
> ><br>
> > Implementing these functions into RTEMS will make porting drivers from<br>
> > FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd implement<br>
> > the functions using libfdt variants but this causes a lot of code<br>
> > duplication.<br>
> > eg: bsps/arm/imx/start/imx_iomux.c<br>
> ><br>
> > My initial thoughts were to implement these functions one by one. But then<br>
> > Christian and Vijay mentioned about porting them from libbsd.<br>
><br>
> Yes, there has been an offlist discussion whether the approach of a<br>
> reimplementing them is a good idea.<br>
><br>
> > I went<br>
> > through the OFW code in libbsd and have described my porting process below.<br>
><br>
> If that can be ported, it would be a better approach then reimplementing.<br>
><br>
> > Please have a look at it and let me know if I have missed something or you<br>
> > would like to improve things.<br>
> ><br>
> > The following files will be ported from libbsd<br>
> > prefix = freebsd/sys/dev/ofw<br>
> > <prefix>/openfirm.c<br>
> > <prefix>/openfirm.h<br>
> > <prefix>/ofw_fdt.c<br>
> > <prefix>/ofwvar.h<br>
> ><br>
> > The main idea is to port openfirm.h but the other files are dependencies<br>
> > of openfirm.h<br>
> ><br>
> > After going through some open firmware documentation. I guess as far as<br>
> > RTEMS is<br>
> > concerned we could avoid many functions like OF_init, OF_putchar, OF_test<br>
> > and only care about functions defined under openfirm.h:105-142<br>
><br>
> OK. Note that these functions often have a "node". Think about what that<br>
> is and from where you would get it in an RTEMS driver. I think a lot of<br>
> FreeBSD drivers get it from their (logical) bus system like ofwbus.<br>
><br>
> ><br>
> > But these functions have dependency on the automatically generated<br>
> > ofw_if.h and KOBJS.<br>
> > But after a close inspection, I guess the KOBJSLOOKUP macro in ofw_if.h<br>
> > can be<br>
> > redefined or replaced for RTEMS. Since all it does is call the<br>
> > respective functions defined in ofw_fdt_methods(ofw_fdt.c).<br>
><br>
> Note that the automatically generated interface is used for the FreeBSD<br>
> device driver structure (or rather the bus interface). If you port the<br>
> stuff to RTEMS you should think about whether<br>
><br>
> a) it should replace the libbsd stuff. In that case: What changes would<br>
> be necessary to libbsd.<br>
><br>
> b) or whether it should live side by side.<br>
><br>
> ><br>
> > I had just spent a few hours going through the code. If I had missed<br>
> > something<br>
> > please let me know.<br>
> ><br>
> > Thanks,<br>
> > Niteesh.<br>
><br>
> Best regards<br>
><br>
> Christian<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></div>