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

Alex Bradbury asb at asbradbury.org
Tue Jul 19 19:14:40 BST 2016

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

> That said, it is definitely true that there are many existing
> _platform_ drivers that use device tree.

You're right, I was overly broad - thanks for the clarification.

>> The config-string code
>> will recognise resources such as irqs and addresses but of course many
>> drivers need more parameters than that.
> Yes. See, for example, gpio-riscv.c which executes:
>>      rv->chip.ngpio = config_string_u64(pdev, "ngpio");
> ... which does not seem so cumbersome.

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.

>> Modifying any driver that
>> might be used as part of a RISC-V platform so it can use
>> config_string_u64 and config_string_str as well as of_property_read_*
>> and the platdata approach seems like a non-starter.
> Well, that depends.
> How many existing devices are we planning on integrating directly into
> the SoC? Again, any device that connects via another bus standard will
> work unmodified. I would hope that we aim to include open source
> hardware in the SoC, which would need a new driver anyway.

Sometimes you want to instantiate existing IP, e.g. Xilinx SPI. Some
open source IP is already supported in the kernel (e.g. some devices
from open cores). Additionally, it seems unnecessary to assume that
newly-created open source IP will be RISC-V only. People may choose to
instantiate it with other cores (ARM, MIPS, proprietary, OpenRISC,
OpenSPARC, ...). Although at lowRISC we aim for open-source
peripherals, many other RISC-V implementers are likely to use existing
in-house IP or commercially licensed IP.

> Platform device drivers that correspond to well established IP already
> do exactly what you are advocating against. See
> drivers/pci/host/pcie-{qcom,his}.c, for example. Those are thin C
> wrappers that add probing via device tree for a specific platform to
> the general-purpose DesignWare driver. Notice that they had to write
> distinct drivers for two different platforms, despite the use of
> device tree. We could very easily add another C file that did the
> probing via the config string.

The fact that devicetree doesn't solve all driver-related issues seems
somewhat orthogonal to config-string vs devicetree. If I were to
submit a patch to add config_string_str calls to a driver that already
supports of_property_read_* I think it would be hard to convince
myself I'm actually making the kernel better.

> In summary: I am not necessarily advocating for the config string, but
> I don't find the config string approach to be much of a show stopper.
> The porting effort is minimal per device. This only leaves open the
> question of how many devices would we need to port. The only impacted
> devices are those with existing (but not already widely ported)
> drivers that we would want to integrate directly into the SoC.

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. For use cases like this, it doesn't seem it would be
worth totally stripping the system of DT and instead you'd end up
using either a mixture of config-string and device-tree or device-tree
throughout (by e.g. having the bootloader convert the config-string).
I'm far from an expert here though, so do correct me if you think I'm
missing the point.


More information about the lowrisc-dev mailing list