Re: OFWBUS: How does autoconfiguration work?

On Tue, 2020-02-04 at 19:09 +0530, Niteesh wrote:
> I am working on an operating systems project at my university, which
> currently
> uses lazy driver initialization i.e. that is the drivers initialize the
> hardware only
> during the first invocation, for example, the UART hardware is initialized
> only during the first call to output_char.
> 
> Currently, we have multiple BSP's to support different variants even though
> they are quite similar. For example, we have two BSPs to support BeagleBone
> Black
> and white. We are trying to avoid this by using device tree files. Our goal
> is to parse the
> DTB at boot time and call all the registered drivers to initialize the
> hardware. By registered
> drivers, I mean drivers which are statically linked to executable.
> 
> I am trying to add a system, which will parse the DTB files and initialize
> them by calling
> the appropriate drivers. I want a system similar to FreeBSD or Linux
> a probe and attach method for device drivers. It doesn't have to be as
> complex as FreeBSD
> but a simple one will do.
> 
> If you have any other questions please let me know :)
> 
> Thanks,
> Niteesh
> 

I don't think there is anything much in the freebsd code that will help
you with that.  The book "The Design and Implementation of the FreeBSD
Operating System 2nd ed." describes the freebsd autoconfiguration
mechanisms.  Those mechanisms are designed to solve problems a lot more
complex than parsing a simple hierarchical dtb to find active devices,
it supports a mix of buses that can identify the devices on the bus
(USB, PCI), buses that are described with metadata (ACPI, fdt
simplebus, ISA bus with PNP data), and drivers that can just force a
bus to adopt them by using an identify() method.  Resource management
(interrupts and mmio ranges, mostly) are also part of the scheme.  FDT
data adds another wrinkle by creating cross-hierarchy links between
devices using phandles, and there are sideband subsystems in freebsd to
handle that stuff separately from the normal hiearchical parent/child
bus relationships.

There just isn't much that can reasonably be separated out and used in
another project, I think.

-- Ian