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

Wesley Terpstra wesley at sifive.com
Tue Jul 19 18:30:40 BST 2016


On Tue, Jul 19, 2016 at 9:30 AM, Alex Bradbury <asb at asbradbury.org> wrote:
> On 14 July 2016 at 14:01, Arnd Bergmann <arnd at arndb.de> wrote:
>> On Thursday, July 14, 2016 5:44:20 AM CEST krste at berkeley.edu wrote:
>>> Our config string is a simple plain printable UTF-8 string, and we've
>>> already provided a library for managing this in the Linux port.  We
>>> will relicense this code under BSD.
>>
>> I think such code is unlikely to get merged into the Linux kernel
>> though, there will be significant resistance for subsystem maintainers
>> in adding yet another boot loader interface.

Why? How a system boots and how the hardware self reports is not
something that is within the scope of the linux kernel. The linux
kernel must work on what the hardware and BIOS-equivalent provide. If
the maintainers rejected boot loaders because they were baroque, linux
would not support x86.

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.

>> However, you could have your own interface for the first-stage bootloader,
>> and then load something like the pxa-impedence-matcher[1] that converts
>> the data into normal DTB format before starting the kernel.
>
> I've been playing with the config string and Linux today, and I'm
> really starting to think that if device-tree is seen as unsuitable as
> the standard, then at least the config string should always be
> translated to devicetree at boot.

I am definitely opposed to a translation. You would then have
information in two incompatible formats. In my experience, there is
always a mismatch in the information when you go down this route. If
we do device tree, we should go all the way and use it natively, OR we
should stick with the config string. I think a half measure smells
like a legacy compatibility layer... and yet we are starting with a
clean slate.

> As things are, I'm finding the configuration string rather awkward
> when attempting to work with devices with existing drivers. All
> existing Linux devices can take extra configuration from either a
> struct passed to them (platdata), or read from device tree.

Even if you said that all existing linux PLATFORM device drivers take
their configuration from plat data or device tree, the above would
still be inaccurate. Firstly, the vast majority of linux device
drivers are not for platform devices. They are for devices connected
to some other bus, like PCI or USB. Those work unmodified on RISC-V.
Secondly, many platform devices do not use device tree, but instead
simply use the 'resource's that are probed for them. We are already
compatible with this interface. Finally, many architectures (including
x86) do not use device tree, but another mechanism, so RISC-V is not
unusual in this regard.

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

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

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

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.

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.



More information about the lowrisc-dev mailing list