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
