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

Wesley Terpstra wesley at sifive.com
Tue Jul 19 21:55:25 BST 2016


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.

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

> Devicetree is already supported out of the box in a large part of
> the existing platform drivers, so with using devicetree there
> wouldn't be any need to port specific drivers at all in many
> cases - they could be used as is.

I agree that this is a desirable feature.

When I first saw the config string, my response was also: why did we
not use an existing standard. All I want is that we don't end up with
two orthogonal description languages in a new platform.

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

All fair points.

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

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



More information about the lowrisc-dev mailing list