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