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

Alex Bradbury asb at asbradbury.org
Tue Jul 19 17:30:01 BST 2016

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:
>> We couldn't see any advantage to adding another layer of cruft of top
>> of a poorly thought out standard.
>> 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.
> 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've CCed Wesley who has written the
initial Linux config-string patches and perhaps may comment on what
the longer term vision is.

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. The
config-string code
will recognise resources such as irqs and addresses but of course many
drivers need more parameters than that. 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.

Does anyone have thoughts on this issue or plans to share regarding



More information about the lowrisc-dev mailing list