[lowrisc-dev] Re: [sw-dev] Is a de facto standard memory map
helpful or harmful?
wesley at sifive.com
Fri Jul 22 22:14:57 BST 2016
Since no one else responded, I end up again defending the config
string. Here we go...
On Wed, Jul 20, 2016 at 2:32 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> My reading of the config string interface is that it assumes that a
> type of information can always be expressed as a string or a single
> integer number
That's how the convenience methods I wrote work, but actually, the
config string allows an arbitrary number of integers or strings
following a key. I was going to add an additional 'nth' parameter to
> In a system-wide view, having global numbers or names as identifiers
> for resources does not scale, because you can have additional
> providers for things like irqs, gpios, dma, leds, ... on external buses,
The config string is 'XML-like' in that you have recursive
descriptions, so the complete path need be globally unique.
> - an irqchip needing to pass local hwirq number plus flags (polarity,
> type of interrupt) that the consumer driver doesn't know.
> - dmaengine requiring request number plus dma master identifier
> - gpio passing some settings (bank-nr, polarity, drive strength, ...)
> - pwm period and flags
I don't see a problem with most of these. You can have hierarchical
information at any given path in the config string, and drivers attach
at the point in the hierarchy where they assume responsibility.
> Note that you should always be able to describe a full system
> with a flattened device tree, even if it started out using some
> other format (atags, fex, bios, ...), since the DT is basically
> a superset of information that you can have elsewhere.
Right. Except when you translate between formats things might end up
either missing or in an unexpected location.
> There is already an ongoing unification with the "device properties"
> interface that allows you to query generic properties from a
> 'struct device' in Linux, regardless of whether it was instantiated
> from architecture code (no legacy machines), using devicetree
> (on most modern embedded systems) or from ACPI (on embedded x86),
> since all of them have a way to attach numbers or strings to named
If we stick with the config string, I will definitely explore adding
the config-string meta-data to this interface.
> The same thing can of course be used for querying config strings
> that are embedded in a RISC-V SoC, but it quickly becomes awkward
> when you need to have cross-references to other nodes, as those
> cannot easily be generalised.
This is one of my main concerns. It's true that device tree has a lot
of cruft, but it's also a widely used spec, so some of what looks
overly complex actually solves a problem you didn't know existed.
Case-and-point: cross references. This is something the config-string
does not have, although I am sure its advocates would say: "Nothing
prevents you from including a string that refers to another path in
the hierarchy". However, unless that cross-reference format has been
specified somewhere, you won't get the sort of reuse that makes a
general-purpose parser and convenience functions available.
> The device tree is used for several things beyond that today, each
> of which needs a solution:
> - passing configuration from the bootloader, including amount of
> installed memory, root console settings and the kernel command
> line. These are often handled in some architecture specific
> way and I assume there is something in place already
Currently you get this information from a combination of SBI
(essentially the BIOS) calls and the config string. We were planning
to reduce the number of SBI calls to the bare minimum needed to hand
off the config string, and then put all the information you need in
> - describing on-chip components: this is annoying because the
> SoC should already know what it is and have a way to convey
> that information to an OS without the need of describing it
> in software. x86 doesn't need this because the hardware is
> known in advance: everything is either at a fixed address
> or it shows up logically as a discoverable PCI device.
> Today's SoCs almost all get that wrong, and that's why we
> describe them in DT.
Right. This is the problem the config string advocates are trying to solve.
> If the config strings can be embedded in each on-chip device
> in a way that they are always accessible without the need
> for a boot loader interface in the way that PCI is discoverable,
> that means we don't need DT for this and can just have a
> single DT node for the SoC itself, and make that present itself
> as a combined irqchip/gpiochip/pwm/led/clk/reset/mmio/...
Currently, the idea was to bake the config string for the SoC into the
boot ROM for that SoC. That means one ROM for the whole SoC, not one
ROM per device.
> - describing off-chip non-discoverable buses, there really
> isn't much of an alternative to DT, as these can be rather
> complex, each device can both be a consumer and a provider
> of resources (e.g. gpios or regulators controlled over i2c),
> and we don't want to describe individual machines in source
> code any more. embedded x86 machines with ACPI can get around
> some of these problems by sticking data that is compatible
> with the DT format into ACPI tables.
This is a definite gap in the current scheme. Probably the best answer
with the current system is that the boot loader for that board would
inject additional data describing the i2c components on the board into
the config string. However, DT already has a scheme for overlaying
data like this, and IMO it seems rather foolish to reinvent the wheel
with the config string.
> - adding missing information to discoverable buses: this
> happens surprisingly often: sdio is discoverable in theory,
> but many wifi adapters need to read their MAC address and
> connect to a clock controller, a reset controller, a regulator
> or an external interrupt. USB ethernet is similar, when people
> are cheap and leave out the eprom that stores device information.
> Even on PCI we have the need to pass additional data like
> tuning for wireless network adapters, or you can have a
> SDIO-on-USB-on-PCI adapter and get all of the above.
This was not even on our radar. Thank you for pointing this scenario out.
More information about the lowrisc-dev