[lowrisc-dev] Re: [sw-dev] Is a de facto standard memory map helpful or harmful?

Arnd Bergmann arnd at arndb.de
Wed Jul 20 10:32:08 BST 2016

On Tuesday, July 19, 2016 1:55:25 PM CEST Wesley Terpstra wrote:
> On Tue, Jul 19, 2016 at 1:10 PM, Karsten Merker <merker at debian.org> wrote:
> > On Tue, Jul 19, 2016 at 07:14:40PM +0100, Alex Bradbury wrote:
> >> On 19 July 2016 at 18:30, Wesley Terpstra <wesley at sifive.com> wrote:
> >
> >> > I think that whatever decision we make wrt. how the system describes
> >> > its contained hardware should not consider whether a hypothetical
> >> > kernel developer will reject a merge of the architecture, because this
> >> > is not within the scope of kernel software. That said, if it makes
> >> > porting many drivers to RISC-V a pain, then we might want to take that
> >> > pain into consideration.
> >>
> >> I disagree, with RISC-V we have the opportunity for much greater
> >> collaboration between hardware and software developers. These
> >> decisions should be made ins consultation with software developers
> >> rather than thrown over the wall (publishing drafts of the privileged
> >> spec before they are adopted by the RISC-V Foundation has of course
> >> been useful for this).
> I am not saying that we should not collaborate with software
> developers. Certainly we want to reach a solution that is good for
> both the hardware and software implementations. Rather, I don't think
> we should be making a decision based on the fear of not getting
> whatever support is necessary into the kernel. If the software is
> needed for the platform, it will get merged.

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.

> >> Yes I saw that. It's not cumbersome to add it for any given device,
> >> but it does seem a shame if we're now going to end up with three
> >> configuration codepaths for every platform device that might want to
> >> be used on RISC-V as well as other devicetree supporting platforms.
> Right. I just question how many such devices there will be.

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

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 generalized.

> > Another important field for platform driver support are
> > peripherals on non-discoverable busses such as I2C and SPI, for
> > which we have a plethora of existing drivers with device-tree
> > support.
> I agree that you need some way to compensate for deficient busses.

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

- 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.
  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/...

- 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.

- 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.

> >> Devicetree can also be used for configuring on-board devices as used
> >> with devices like Beaglebone Black and Raspberry Pi through
> >> device-tree overlays. e.g. you may load a certain device tree overlay
> >> when an audio 'hat' or 'cape' is connected to enable I2S on the
> >> desired pins.
> If you attach an external bus described by DT, I agree you will want
> to keep using that format.
> I also agree mixing standards is bad. I just want to avoid that there
> are two different description languages used at different layers of
> the system.
> Ultimately, though, you need to convince the actors who advocate for
> the config string. They argue that DT does not include the fields
> needed for RISC-V and would need to be extended, anyway.
> I wonder if one could address most of the concerns about the config
> string by implementing DT API-compatible methods for the config
> string.

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, while the DT format for most subsystems defines the
format as using a reference to a node providing the resource, followed
by an arbitrary number of integers in a format that is defined by
the provider.

It's probably possible to map one into the other, but it's not nice.
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,
and an OS like Linux already contains infrastructure to handle
those but requires them to be registered as separate devices that
each define their own local addressing.

Having a single number as an identifier works most of the time, but
there are plenty of examples where it doesn't:

- 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

If you only have a scalar identifier, then you need a global
lookup table somewhere reachable by the driver. Using a string
obviously works for this too, but requires a parser in each driver.


More information about the lowrisc-dev mailing list