GSOC: Adding FDT infrastructure to RTEMS
Niteesh
gsnb.gn at gmail.com
Sun Feb 2 06:32:20 UTC 2020
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.mauderer at 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.gn at gmail.com
> > <mailto:gsnb.gn at 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200202/419bad18/attachment.html>
More information about the devel
mailing list