Handling RISC-V config-string in the Linux kernel (Re: [sw-dev] Is a de facto standard memory map helpful or harmful?)
5:22 a.m.
(Changed the subject to better reflect the current discussion topic)
On 19 July 2016 at 21:55, Wesley Terpstra <wesley(a)sifive.com> wrote:
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 think we're in agreement here. I totally get the danger of
making decisions that are easy in the short term with regards to
software work that may turn out to bite us further down the road.
>> 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.
Yes, a quick grep of the kernel tree shows ~3k of_property_read_*
instances (and that's not been stripped for references in docs or
comments). A patch to add support for reading config-string values as
well as device-tree would probably be at least 6k-9k lines. Not
insanely huge, but also big enough you might consider if there's a
better way of doing this that doesn't require adding lots of
admittedly trivial but likely untested code-paths to the kernel tree.
As you point out, it may be that only a subset of devices are
interesting which would reduce the amount of necessary work - though
the fact device-tree is used on a number of SPI or I2C devices means
the number isn't going to be tiny.
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.
I think this is one of the key points. The major criticism of
devicetree in the privileged spec seems to be the binary encoding -
the fact it's big-endian and 32-bit. This doesn't seem like a big deal
on any system capable of running Linux and I suspect that on smaller
systems runtime config parsing is one of the first things developers
will strip out when they need to save ROM size, but I can understand
not wanting to standardise a format seen as ugly. If RISC-V decides to
reject the flattened device tree encoding, does it really need to
reject the device-tree schema as well? If the schema is the same (or
has a simple mapping) and the formats trivially convertible, then it
just becomes an implementation detail whether the bootloader or the
Linux kernel itself converts the config-string to a flattened device
tree (arguably the preferred in-memory config representation in the
kernel).
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 hadn't seen any arguments that weren't based on the FDT encoding,
I'd certainly be interested in them.
Although my emails might read otherwise, I'd like to be clear I'm not
really advocating that config-string be dropped in favour of
device-tree. My main concern is maximum compatibility with existing
device drivers in the Linux kernel. I'd argue any new system has a
certain complexity/weirdness budget before people start to really push
back. I'd personally much rather spend this budget on more interesting
user-visible features rather than something that seems more of an
implementation detail, which is why converting config-string to
devicetree and exposing that to the kernel seems promising as an
approach that requires minimal driver changes.
I wonder if one could address most of the concerns about the config
string by implementing DT API-compatible methods for the config
string.
Yes, I've thought this too. Arguably it would be better if there were
greater abstraction for devices querying config values - i.e.
get_config_val rather than of_property_read. This would handle the
case of FEX on Allwinner devices (provided the same config keys were
used!). Is it the case that a RISC-V system would never want the
device-tree versions of these symbols though? If not, just providing
the same API with duplicate symbol names seems insufficient.
Perhaps someone can comment on the config-string schema and how/if/why
it differs to the device-tree spec?
http://www.devicetree.org/specifications-pdf
Best,
Alex
5:29 a.m.
New subject: Handling RISC-V config-string in the Linux kernel (Re: [sw-dev] Is a de facto standard memory map helpful or harmful?)
On 20 Jul 2016, at 10:22, Alex Bradbury <asb(a)asbradbury.org> wrote:
> 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 hadn't seen any arguments that weren't based on the FDT encoding,
I'd certainly be interested in them.
Although my emails might read otherwise, I'd like to be clear I'm not
really advocating that config-string be dropped in favour of
device-tree. My main concern is maximum compatibility with existing
device drivers in the Linux kernel. I'd argue any new system has a
certain complexity/weirdness budget before people start to really push
back. I'd personally much rather spend this budget on more interesting
user-visible features rather than something that seems more of an
implementation detail, which is why converting config-string to
devicetree and exposing that to the kernel seems promising as an
approach that requires minimal driver changes.
And not just Linux — FDT is the standard handled by FreeBSD, real-time operating systems,
etc. Device drivers have configuration-mechanism-specific attachment points, and a new
underlying mechanism requires device drivers to be extended to support new attachment
points. Failing to conform to existing de facto standards means a lot of work on the
device-driver front and will substantially reduce the degree to which existing device
drivers will “just work”, requiring additional validation (which will probably not happen,
leading to adoption barriers as potential consumers discover things don’t work and have to
debug / fix them). Regardless of the specific in-memory encoding, conforming to an
identical schema would make a huge difference in avoiding this problem. That said, I do
have to ask: if FDT passes muster for ARM, MIPS, various FPGA-based systems, etc, and is
the industry de facto standard, I’m not convinced that not liking FDT/DTB as a format is a
good reason to diverge from it — it will generate vast amounts of work and a much bumpier
adoption path. It’s also worth pointing out that there is now an open community around
improving and extending FDT, which could easily be engaged with to fix gaps and rough
edges. Maybe there’s an exciting new contribution to be made by the RISC-V community in
the system configuration story — but more likely not, and doing one’s own thing here
simply becomes more work for potential adopters.
Robert
2:47 a.m.
Thanks, y'all, for the thoughtful discussion. Consequent to your
feedback, we're now leaning towards exposing FDT to the kernel
software, via the SBI. While FDT is far from an ideal format, it's
well supported, and it gets the job done.
Below the SBI is a different story. We expect that there will always
be some degree of translation between the bare-metal reckoning of the
platform and what gets exposed to the OS--either to redact information
about the platform, or to virtualize it, or to work around bugs.
With that in mind, we are contemplating encoding a textual DeviceTree,
rather than FDT, into the M-mode boot ROM. We see two main benefits
to the textual representation: it is useful for low-level debugging,
and it is denser than FDT. This approach is suited to embedded
systems, whose software isn't introspective and so is agnostic to the
representation; and it is fine for Unix-class systems, where the cost
of boot-time translation into FDT is a drop in the bucket.
We welcome feedback on this approach.
Andrew
On Wed, Jul 20, 2016 at 2:29 AM, Robert N.M. Watson
<robert.watson(a)cl.cam.ac.uk> wrote:
On 20 Jul 2016, at 10:22, Alex Bradbury <asb(a)asbradbury.org>
wrote:
>> 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 hadn't seen any arguments that weren't based on the FDT encoding,
> I'd certainly be interested in them.
>
> Although my emails might read otherwise, I'd like to be clear I'm not
> really advocating that config-string be dropped in favour of
> device-tree. My main concern is maximum compatibility with existing
> device drivers in the Linux kernel. I'd argue any new system has a
> certain complexity/weirdness budget before people start to really push
> back. I'd personally much rather spend this budget on more interesting
> user-visible features rather than something that seems more of an
> implementation detail, which is why converting config-string to
> devicetree and exposing that to the kernel seems promising as an
> approach that requires minimal driver changes.
And not just Linux — FDT is the standard handled by FreeBSD, real-time operating systems,
etc. Device drivers have configuration-mechanism-specific attachment points, and a new
underlying mechanism requires device drivers to be extended to support new attachment
points. Failing to conform to existing de facto standards means a lot of work on the
device-driver front and will substantially reduce the degree to which existing device
drivers will “just work”, requiring additional validation (which will probably not happen,
leading to adoption barriers as potential consumers discover things don’t work and have to
debug / fix them). Regardless of the specific in-memory encoding, conforming to an
identical schema would make a huge difference in avoiding this problem. That said, I do
have to ask: if FDT passes muster for ARM, MIPS, various FPGA-based systems, etc, and is
the industry de facto standard, I’m not convinced that not liking FDT/DTB as a format is a
good reason to diverge from it — it will generate vast amounts of work and a much bumpier
adoption path. It’s also worth pointing out that there is now an open community around
improving and extending FDT, which could easily be engaged with to fix gaps and rough
edges. Maybe there’s an exciting new contribution to be made by the RISC-V community in
the system configuration story — but more likely not, and doing one’s own thing here
simply becomes more work for potential adopters.
Robert
--
You received this message because you are subscribed to the Google Groups "RISC-V SW
Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
sw-dev+unsubscribe(a)groups.riscv.org.
To post to this group, send email to sw-dev(a)groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit
https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/DAF3479B-4E73....
4:18 a.m.
New subject: Handling RISC-V config-string in the Linux kernel (Re: [sw-dev] Is a de facto standard memory map helpful or harmful?)
Hi Andrew:
This sounds like a good strategy. I think the key thing here is conforming to the schema,
rather than the explicit representation: as long as the model and parameter names are the
same (or there is a clean mapping), then we can avoid having to change larger volumes of
software. And I think everyone would agree that the current device-tree world has its
limitations — its main advantage is that it exists and can provide an incremental path to
something better. One thing that FDT currently provides is a composition model, which is
also good to avoid breaking: we can ship FDT fragments with the boot loader or OS that
augment descriptions in firmware, which is quite nice for embedded device customisation.
There is a growing community around improving FDT that may be worth participating in
(devicetree.org) — and it might be useful for the RISC-V consortium to become a member.
More generally, the strategy you propose is important in allowing the RISC-V community to
pick its battles: disrupt where there’s clear and well-motivated advantage (e.g., the new
open-source ISA, more dynamic sets of firmware interfaces, etc) and not where it doesn’t
(e.g., legacy device-driver attachments and configuration merging).
Robert
On 20 Aug 2016, at 07:47, Andrew Waterman <andrew(a)sifive.com>
wrote:
Thanks, y'all, for the thoughtful discussion. Consequent to your
feedback, we're now leaning towards exposing FDT to the kernel
software, via the SBI. While FDT is far from an ideal format, it's
well supported, and it gets the job done.
Below the SBI is a different story. We expect that there will always
be some degree of translation between the bare-metal reckoning of the
platform and what gets exposed to the OS--either to redact information
about the platform, or to virtualize it, or to work around bugs.
With that in mind, we are contemplating encoding a textual DeviceTree,
rather than FDT, into the M-mode boot ROM. We see two main benefits
to the textual representation: it is useful for low-level debugging,
and it is denser than FDT. This approach is suited to embedded
systems, whose software isn't introspective and so is agnostic to the
representation; and it is fine for Unix-class systems, where the cost
of boot-time translation into FDT is a drop in the bucket.
We welcome feedback on this approach.
Andrew
On Wed, Jul 20, 2016 at 2:29 AM, Robert N.M. Watson
<robert.watson(a)cl.cam.ac.uk> wrote:
> On 20 Jul 2016, at 10:22, Alex Bradbury <asb(a)asbradbury.org> wrote:
>
>>> 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 hadn't seen any arguments that weren't based on the FDT encoding,
>> I'd certainly be interested in them.
>>
>> Although my emails might read otherwise, I'd like to be clear I'm not
>> really advocating that config-string be dropped in favour of
>> device-tree. My main concern is maximum compatibility with existing
>> device drivers in the Linux kernel. I'd argue any new system has a
>> certain complexity/weirdness budget before people start to really push
>> back. I'd personally much rather spend this budget on more interesting
>> user-visible features rather than something that seems more of an
>> implementation detail, which is why converting config-string to
>> devicetree and exposing that to the kernel seems promising as an
>> approach that requires minimal driver changes.
>
> And not just Linux — FDT is the standard handled by FreeBSD, real-time operating
systems, etc. Device drivers have configuration-mechanism-specific attachment points, and
a new underlying mechanism requires device drivers to be extended to support new
attachment points. Failing to conform to existing de facto standards means a lot of work
on the device-driver front and will substantially reduce the degree to which existing
device drivers will “just work”, requiring additional validation (which will probably not
happen, leading to adoption barriers as potential consumers discover things don’t work and
have to debug / fix them). Regardless of the specific in-memory encoding, conforming to an
identical schema would make a huge difference in avoiding this problem. That said, I do
have to ask: if FDT passes muster for ARM, MIPS, various FPGA-based systems, etc, and is
the industry de facto standard, I’m not convinced that not liking FDT/DTB as a format is a
good reason to diverge from it — it will generate vast amounts of work and a much bumpier
adoption path. It’s also worth pointing out that there is now an open community around
improving and extending FDT, which could easily be engaged with to fix gaps and rough
edges. Maybe there’s an exciting new contribution to be made by the RISC-V community in
the system configuration story — but more likely not, and doing one’s own thing here
simply becomes more work for potential adopters.
>
> Robert
>
> --
> You received this message because you are subscribed to the Google Groups
"RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
sw-dev+unsubscribe(a)groups.riscv.org.
> To post to this group, send email to sw-dev(a)groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit
https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/DAF3479B-4E73....
5:09 a.m.
On Sat, Aug 20, 2016 at 1:18 AM, Robert N. M. Watson
<robert.watson(a)cl.cam.ac.uk> wrote:
Hi Andrew:
This sounds like a good strategy. I think the key thing here is conforming to the schema,
rather than the explicit representation: as long as the model and parameter names are the
same (or there is a clean mapping), then we can avoid having to change larger volumes of
software. And I think everyone would agree that the current device-tree world has its
limitations — its main advantage is that it exists and can provide an incremental path to
something better. One thing that FDT currently provides is a composition model, which is
also good to avoid breaking: we can ship FDT fragments with the boot loader or OS that
augment descriptions in firmware, which is quite nice for embedded device customisation.
There is a growing community around improving FDT that may be worth participating in
(devicetree.org) — and it might be useful for the RISC-V consortium to become a member.
More generally, the strategy you propose is important in allowing the RISC-V community to
pick its battles: disrupt where there’s clear and well-motivated advantage (e.g., the new
open-source ISA, more dynamic sets of firmware interfaces, etc) and not where it doesn’t
(e.g., legacy device-driver attachments and configuration merging).
Indeed, there are better places to spend our collective intellectual
capacity and engineering effort.
Robert
> On 20 Aug 2016, at 07:47, Andrew Waterman <andrew(a)sifive.com> wrote:
>
> Thanks, y'all, for the thoughtful discussion. Consequent to your
> feedback, we're now leaning towards exposing FDT to the kernel
> software, via the SBI. While FDT is far from an ideal format, it's
> well supported, and it gets the job done.
>
> Below the SBI is a different story. We expect that there will always
> be some degree of translation between the bare-metal reckoning of the
> platform and what gets exposed to the OS--either to redact information
> about the platform, or to virtualize it, or to work around bugs.
>
> With that in mind, we are contemplating encoding a textual DeviceTree,
> rather than FDT, into the M-mode boot ROM. We see two main benefits
> to the textual representation: it is useful for low-level debugging,
> and it is denser than FDT. This approach is suited to embedded
> systems, whose software isn't introspective and so is agnostic to the
> representation; and it is fine for Unix-class systems, where the cost
> of boot-time translation into FDT is a drop in the bucket.
>
> We welcome feedback on this approach.
>
> Andrew
>
> On Wed, Jul 20, 2016 at 2:29 AM, Robert N.M. Watson
> <robert.watson(a)cl.cam.ac.uk> wrote:
>> On 20 Jul 2016, at 10:22, Alex Bradbury <asb(a)asbradbury.org> wrote:
>>
>>>> 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 hadn't seen any arguments that weren't based on the FDT encoding,
>>> I'd certainly be interested in them.
>>>
>>> Although my emails might read otherwise, I'd like to be clear I'm
not
>>> really advocating that config-string be dropped in favour of
>>> device-tree. My main concern is maximum compatibility with existing
>>> device drivers in the Linux kernel. I'd argue any new system has a
>>> certain complexity/weirdness budget before people start to really push
>>> back. I'd personally much rather spend this budget on more interesting
>>> user-visible features rather than something that seems more of an
>>> implementation detail, which is why converting config-string to
>>> devicetree and exposing that to the kernel seems promising as an
>>> approach that requires minimal driver changes.
>>
>> And not just Linux — FDT is the standard handled by FreeBSD, real-time operating
systems, etc. Device drivers have configuration-mechanism-specific attachment points, and
a new underlying mechanism requires device drivers to be extended to support new
attachment points. Failing to conform to existing de facto standards means a lot of work
on the device-driver front and will substantially reduce the degree to which existing
device drivers will “just work”, requiring additional validation (which will probably not
happen, leading to adoption barriers as potential consumers discover things don’t work and
have to debug / fix them). Regardless of the specific in-memory encoding, conforming to an
identical schema would make a huge difference in avoiding this problem. That said, I do
have to ask: if FDT passes muster for ARM, MIPS, various FPGA-based systems, etc, and is
the industry de facto standard, I’m not convinced that not liking FDT/DTB as a format is a
good reason to diverge from it — it will generate vast amounts of work and a much bumpier
adoption path. It’s also worth pointing out that there is now an open community around
improving and extending FDT, which could easily be engaged with to fix gaps and rough
edges. Maybe there’s an exciting new contribution to be made by the RISC-V community in
the system configuration story — but more likely not, and doing one’s own thing here
simply becomes more work for potential adopters.
>>
>> Robert
>>
>> --
>> You received this message because you are subscribed to the Google Groups
"RISC-V SW Dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email
to sw-dev+unsubscribe(a)groups.riscv.org.
>> To post to this group, send email to sw-dev(a)groups.riscv.org.
>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
>> To view this discussion on the web visit
https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/DAF3479B-4E73....
11:15 a.m.
New subject: Handling RISC-V config-string in the Linux kernel (Re: [sw-dev] Is a de facto standard memory map helpful or harmful?)
On Friday, August 19, 2016 11:47:56 PM CEST Andrew Waterman wrote:
Below the SBI is a different story. We expect that there will
always
be some degree of translation between the bare-metal reckoning of the
platform and what gets exposed to the OS--either to redact information
about the platform, or to virtualize it, or to work around bugs.
With that in mind, we are contemplating encoding a textual DeviceTree,
rather than FDT, into the M-mode boot ROM. We see two main benefits
to the textual representation: it is useful for low-level debugging,
and it is denser than FDT. This approach is suited to embedded
systems, whose software isn't introspective and so is agnostic to the
representation; and it is fine for Unix-class systems, where the cost
of boot-time translation into FDT is a drop in the bucket.
We welcome feedback on this approach.
One thing that libfdt lets you do quite easily is to modify properties
in place on an fdt file. This is a bit harder with a text representation.
I'm not sure what you mean with 'denser' above, do you see the size of
the dtb file being larger than the dts file? That is possible, but
unexpected, as the dtb format uses a (very simplistic) string compression
to reduce the size for commonly used identifiers.
The text representation has another advantage, when you want to build
the final dtb from multiple sources: a .dtsi or .dts file can refer
to labels and paths using a string as an identifier, and that keeps
working when one of the two files is updated independently of the
other. With the .dtb format, I think you'd have to use overlay
files to do something similar, as the "phandle" numbers are not
guaranteed to be the same when you compile a modified .dts. I don't
know too much about how the overlays work though (they are fairly
new), so I'd recommend having a look at those before you make the
final decision.
Other than those, I don't see a problem with using either representation,
dtc can easily convert one into the other. You can also have your
own internal representation, as both Linux and OpenFirmware do.
The way that OpenFirmware traditionally works is that the kernel
walks the device tree by calling into the firmware client interface
to retrieve handles for each device node, and then read their children
and properties one at a time. This is particularly useful when the
device tree is dynamically built by the firmware, but is less useful
on embedded systems.
Arnd
2475
days inactive
2510
days old
5 comments
5 participants
participants (5)
-
Alex Bradbury -
Andrew Waterman -
Arnd Bergmann -
Robert N. M. Watson -
Robert N.M. Watson