<div dir="ltr">I am in the process of preparing my GSoC proposal and I would like to<div>discuss in more detail on implementation and necessary functions.</div><div><br></div><div><div>Assuming, a basic probe and attach functionality have been added, I guess the</div><div>console-config could be changed to <a href="http://collabedit.com/adyhf" target="_blank">http://collabedit.com/adyh</a>f.</div><div>A similar driver could be written for arm pl011 also. We can then remove the uart_probe</div><div>and just have console_select.</div><div>What all functions should be included other than ofw_get_reg and ofw_get_irq</div><div><br></div><div>Will these structures be enough for representing devices and drivers?</div><div><br></div><div>struct device {</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>const char *name;</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>const char *desc;</div></blockquote></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>driver *drv;</div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">uint32_t phandle;<br></blockquote>}<div>From my point of view, a device object should be a reference to a node in the</div><div>device tree file and should have the selected driver referenced to it.</div><div><br></div><div>struct driver{</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>const char *name;</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">device_methods *methods;<br>void *dev_context;</blockquote>}</div><div><div>What are all the other required members? the dev_context will be used to store</div><div>the device context. For example the structure representing the SPI bus</div><div><a href="https://github.com/RTEMS/rtems/blob/9e4f21b927e8a81df8044806e88128388911e123/bsps/arm/imx/spi/imx-ecspi.c#L29" target="_blank">https://github.com/RTEMS/rtems/blob/9e4f21b927e8a81df8044806e88128388911e123/bsps/arm/imx/spi/imx-ecspi.c#L29</a><br></div><div>could be part of the dev_context.</div><div><br></div><div>This is my incomplete proposal.</div><div><a href="https://docs.google.com/document/d/1gvGJSxrMtFtqFjbsmXW4OZsBq5lu7EVxs881G_Rohfs/edit" target="_blank">https://docs.google.com/document/d/1gvGJSxrMtFtqFjbsmXW4OZsBq5lu7EVxs881G_Rohfs/edit</a></div></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 21, 2020 at 2:13 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</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">Hello Niteesh,<br>
<br>
great that you pick up that project.<br>
<br>
On 20/01/2020 18:38, Niteesh wrote:<br>
> This is what I have understood till now, please correct me if I am wrong<br>
> All this explanation is in context with FreeBSD.<br>
<br>
Note that this stuff in FreeBSD is quite universal and tend to be a bit<br>
more complex than would be absolutely necessary. I think a first<br>
implementation for RTEMS can be a lot simpler.<br>
<br>
> The drivers register themselves using* EARLY_DRIVER_MODULE*, this done with<br>
> the help of linker sets right?<br>
<br>
I'm not entirely sure whether it's linker set in FreeBSD but in libbsd<br>
we use linker sets for that.<br>
<br>
> Where all the data structures for the<br>
> drivers stored things like<br>
> compatible strings etc. Is it also in linkerset?<br>
<br>
In the simplest form (the one that would be the right target for a first<br>
draft) the strings are just written as constants in the driver source.<br>
For example take a look at freebsd/sys/arm/ti/am335x/am335x_usbss.c. The<br>
usbss_probe just has the following line:<br>
<br>
if (!ofw_bus_is_compatible(dev, "ti,am33xx-usb"))<br>
return (ENXIO);<br>
<br>
The relevant convenient function here is ofw_bus_is_compatible.<br>
Something like that would be great for RTEMS too.<br>
<br>
> At some point during initialization, the *ofwbus(fdtbus) *is<br>
> initialized, it is attached to some kind of<br>
> bus not sure which one, is it *nexus or newbus*? To which another<br>
> abstract bus called *simplebus *is<br>
> attached, all peripherals are then attached to this bus.<br>
<br>
Correct. FreeBSD uses a bus system for all hardware. It can have<br>
different connections and different order depending on the board. All of<br>
them are connected sooner or later to a Nexus. That's the first bus in<br>
the system.<br>
<br>
Don't go too deep into the different bus systems. I don't think that you<br>
would need more than one "bus" for the project. Maybe it's not even<br>
necessary to copy the bus structure but just use a similar interface<br>
instead.<br>
<br>
> I couldn't find anything called *fdtbus*, in the FreeBSD code, All I<br>
> could find was *ofwbus*, but all reference<br>
> talk only about *fdtbus*, am I missing something?<br>
<br>
The "open firmware bus" is the one that parses the FDT. That's the<br>
relevant one for you. I'm not sure where the term "fdtbus" comes from.<br>
Maybe it's an old one?<br>
<br>
> After *simplebus* init is done, the *ofwbus_attach(ofwbus.c:137) *goes<br>
> through all nodes and attaches<br>
> them to *simplebus*.<br>
OK.<br>
<br>
> But I am really sure of what happens after, it<br>
> would be really helpful if someone could<br>
> explain it or at least provide some resources.<br>
<br>
Basically the FreeBSD bus systems provide an abstracted view to<br>
information about the devices. Each bus loops through the connected<br>
devices (for ofwbus this means looping through all active nodes in the fdt).<br>
<br>
For each device the probe of all (relevant) drivers is called to check<br>
whether the driver want's to drive the device. If it wants the device<br>
and no better driver is found (depends on the return value of probe) the<br>
attach of the driver will be called. From there it's more or less the<br>
responsibility of the driver what it want's to do.<br>
<br>
The driver can ask the bus systems for resources like interrupts, pins<br>
or memory. The bus will then look up the resource in it's information<br>
source - for the ofwbus it will look in the fdt - and return the<br>
resource. That stuff is done with "bus_alloc_resource_any" functions and<br>
similar.<br>
<br>
> <br>
> The resources that I used:<br>
> <a href="https://www.bsdcan.org/2010/schedule/attachments/136_FreeBSD_FDT-slides.pdf" rel="noreferrer" target="_blank">https://www.bsdcan.org/2010/schedule/attachments/136_FreeBSD_FDT-slides.pdf</a><br>
> <a href="https://www.semihalf.com/pub/bsdcan/2010_FreeBSD_FDT-paper.pdf" rel="noreferrer" target="_blank">https://www.semihalf.com/pub/bsdcan/2010_FreeBSD_FDT-paper.pdf</a><br>
> Man pages from FreeBSD.<br>
> <br>
> <br>
> On Mon, Jan 20, 2020 at 10:30 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
> I interested in adding FDT infrastructure similar to FreeBSD and<br>
> Linux to<br>
> RTEMS as a GSOC project. I have very little knowledge of how all<br>
> this works,<br>
> but I have started learning by digging into FreeBSD code, using online<br>
> forums and also thanks to Christian for patiently answering all my<br>
> questions.<br>
> <br>
> My plan is to add a subsystem, which will parse the DTB file and<br>
> initialize all active<br>
> devices present in the system. It will ask for drivers that can<br>
> handle the devices and<br>
> the best driver is selected and attached to the driver.<br>
> As I told before, I have very little idea of the complexity, I have<br>
> no idea of what problems<br>
> I would face?<br>
> <br>
> I will discuss what I have learned till now in a following mail,<br>
> please correct me if I <br>
> am wrong.<br>
> <br>
> What do you guys think about this? what all should be implemented in<br>
> a GSOC timeline?<br>
> I know this is not very detailed, but I will create a more detailed<br>
> proposal based<br>
> on your comments soon.<br>
> <br>
> Thank you,<br>
> Niteesh<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>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>