* Kendryte K210 support v4
@ 2020-03-24 4:19 Damien Le Moal
2020-03-26 22:09 ` Palmer Dabbelt
0 siblings, 1 reply; 6+ messages in thread
From: Damien Le Moal @ 2020-03-24 4:19 UTC (permalink / raw)
To: linux-riscv, Palmer Dabbelt
Palmer,
Ping ?
It would be great to get this series in 5.7.
(sorry I could send this in reply to my original posting as infradead does not
send me back the emails I am sending to the list)
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kendryte K210 support v4
2020-03-24 4:19 Kendryte K210 support v4 Damien Le Moal
@ 2020-03-26 22:09 ` Palmer Dabbelt
2020-03-26 23:40 ` Damien Le Moal
0 siblings, 1 reply; 6+ messages in thread
From: Palmer Dabbelt @ 2020-03-26 22:09 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv
On Mon, 23 Mar 2020 21:19:05 PDT (-0700), Damien Le Moal wrote:
> > Palmer,
>
> Ping ?
>
> It would be great to get this series in 5.7.
Well, the real issue here is that the new series don't appear to address the
fundamental issue I had with the patch set (kernel binaries that only run on
one system). As a result it's gone on the list of things I need to go fix,
which is quite a bit longer than the review queue.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kendryte K210 support v4
2020-03-26 22:09 ` Palmer Dabbelt
@ 2020-03-26 23:40 ` Damien Le Moal
2020-03-26 23:59 ` Palmer Dabbelt
0 siblings, 1 reply; 6+ messages in thread
From: Damien Le Moal @ 2020-03-26 23:40 UTC (permalink / raw)
To: Palmer Dabbelt; +Cc: linux-riscv
On 2020/03/27 7:09, Palmer Dabbelt wrote:
> On Mon, 23 Mar 2020 21:19:05 PDT (-0700), Damien Le Moal wrote:
>>> Palmer,
>>
>> Ping ?
>>
>> It would be great to get this series in 5.7.
>
> Well, the real issue here is that the new series don't appear to address the
> fundamental issue I had with the patch set (kernel binaries that only run on
> one system). As a result it's gone on the list of things I need to go fix,
> which is quite a bit longer than the review queue.
>
I do not understand... Are you referring to the compressed instruction #ifdef
that was in the unaligned load/store handler ? The latest v4 removed that and I
actuall tested all 4 combinations of kernel and user space being compiled with
and without compressed instructions. All worked fine.
We had the same problem in OpenSBI by the way and we fixed it there too.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kendryte K210 support v4
2020-03-26 23:40 ` Damien Le Moal
@ 2020-03-26 23:59 ` Palmer Dabbelt
2020-03-27 0:38 ` Damien Le Moal
0 siblings, 1 reply; 6+ messages in thread
From: Palmer Dabbelt @ 2020-03-26 23:59 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv
On Thu, 26 Mar 2020 16:40:34 PDT (-0700), Damien Le Moal wrote:
> On 2020/03/27 7:09, Palmer Dabbelt wrote:
> On Mon, 23 Mar 2020 21:19:05 PDT (-0700), Damien Le Moal wrote:
>>> Palmer,
>>
>> Ping ?
>>
>> It would be great to get this series in 5.7.
>
> Well, the real issue here is that the new series don't appear to address the
> fundamental issue I had with the patch set (kernel binaries that only run on
> one system). As a result it's gone on the list of things I need to go fix,
> which is quite a bit longer than the review queue.
>
I do not understand... Are you referring to the compressed instruction #ifdef
that was in the unaligned load/store handler ? The latest v4 removed that and I
actuall tested all 4 combinations of kernel and user space being compiled with
and without compressed instructions. All worked fine.
We had the same problem in OpenSBI by the way and we fixed it there too.
It's the BUILTIN_DTB issue -- this should look up the DTB to use based on some
sort of SOC unique identifier, either something unique in the device tree that
was provided (assuming whatever loads Linux on the Kendryte provides one) or
mvendorid+marchid+mimpid (probably with some sort of masking).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kendryte K210 support v4
2020-03-26 23:59 ` Palmer Dabbelt
@ 2020-03-27 0:38 ` Damien Le Moal
2020-04-03 17:35 ` Palmer Dabbelt
0 siblings, 1 reply; 6+ messages in thread
From: Damien Le Moal @ 2020-03-27 0:38 UTC (permalink / raw)
To: Palmer Dabbelt; +Cc: linux-riscv
On 2020/03/27 8:59, Palmer Dabbelt wrote:
> On Thu, 26 Mar 2020 16:40:34 PDT (-0700), Damien Le Moal wrote:
>> On 2020/03/27 7:09, Palmer Dabbelt wrote:
>> On Mon, 23 Mar 2020 21:19:05 PDT (-0700), Damien Le Moal wrote:
>>>> Palmer,
>>>
>>> Ping ?
>>>
>>> It would be great to get this series in 5.7.
>>
>> Well, the real issue here is that the new series don't appear to address the
>> fundamental issue I had with the patch set (kernel binaries that only run on
>> one system). As a result it's gone on the list of things I need to go fix,
>> which is quite a bit longer than the review queue.
>>
>
> I do not understand... Are you referring to the compressed instruction #ifdef
> that was in the unaligned load/store handler ? The latest v4 removed that and I
> actuall tested all 4 combinations of kernel and user space being compiled with
> and without compressed instructions. All worked fine.
>
> We had the same problem in OpenSBI by the way and we fixed it there too.
>
> It's the BUILTIN_DTB issue -- this should look up the DTB to use based on some
> sort of SOC unique identifier, either something unique in the device tree that
> was provided (assuming whatever loads Linux on the Kendryte provides one) or
> mvendorid+marchid+mimpid (probably with some sort of masking).
Hmmm. Yes, that would be nice. However, an SoC identifier is not the same as a
board identifier, and since the device tree describes not just the SoC, I am not
sure this would in the end be a unique enough ID and so not improve anything.
The other problem with this I think is that this does not improve in any way the
"bad" case where none of the embedded DTBs available match the hardware. What to
do then ? At that point, the kernel code is such in an early stage that it
cannot even display anything. That is the same situation with the current single
BUILTIN dtb: if the dtb is wrong, the kernel will likely not boot.
The current BUILTIN_DTB approach comes from other arch where that already
exists. Nothing new here, and it looks like other arch at least didn't mind the
end-result special kernel-for-this-paltform-only approach. We are talking about
a tiny hardware/super embedded thing here. I sure would not want to use BUILTIN
DTB for anything bigger then the Kendryte boards and this may be where we can
improve using KConfig: allow selecting BUILTIN DTB only if the KENDRYTE SOC is
selected ?
In the end, I would really like to see this series in 5.7 to enable all the
hobbyist and hackers out there to more easily contribute improvements in this
area. I do not see much problem with starting with the BUILTIN DTB as it is and
improve on it as we go. There will not be any "backward compatibility" problems
that I can see.
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kendryte K210 support v4
2020-03-27 0:38 ` Damien Le Moal
@ 2020-04-03 17:35 ` Palmer Dabbelt
0 siblings, 0 replies; 6+ messages in thread
From: Palmer Dabbelt @ 2020-04-03 17:35 UTC (permalink / raw)
To: Damien Le Moal; +Cc: linux-riscv
On Thu, 26 Mar 2020 17:38:50 PDT (-0700), Damien Le Moal wrote:
>> On 2020/03/27 8:59, Palmer Dabbelt wrote:
>> On Thu, 26 Mar 2020 16:40:34 PDT (-0700), Damien Le Moal wrote:
>>> On 2020/03/27 7:09, Palmer Dabbelt wrote:
>>> On Mon, 23 Mar 2020 21:19:05 PDT (-0700), Damien Le Moal wrote:
>>>>> Palmer,
>>>>
>>>> Ping ?
>>>>
>>>> It would be great to get this series in 5.7.
>>>
>>> Well, the real issue here is that the new series don't appear to address the
>>> fundamental issue I had with the patch set (kernel binaries that only run on
>>> one system). As a result it's gone on the list of things I need to go fix,
>>> which is quite a bit longer than the review queue.
>>>
>>
>> I do not understand... Are you referring to the compressed instruction #ifdef
>> that was in the unaligned load/store handler ? The latest v4 removed that and I
>> actuall tested all 4 combinations of kernel and user space being compiled with
>> and without compressed instructions. All worked fine.
>>
>> We had the same problem in OpenSBI by the way and we fixed it there too.
>>
>> It's the BUILTIN_DTB issue -- this should look up the DTB to use based on some
>> sort of SOC unique identifier, either something unique in the device tree that
>> was provided (assuming whatever loads Linux on the Kendryte provides one) or
>> mvendorid+marchid+mimpid (probably with some sort of masking).
>
> Hmmm. Yes, that would be nice. However, an SoC identifier is not the same as a
> board identifier, and since the device tree describes not just the SoC, I am not
> sure this would in the end be a unique enough ID and so not improve anything.
IIRC there's only one DT for this platform anyway, so it at least fixes the
issue here.
> The other problem with this I think is that this does not improve in any way the
> "bad" case where none of the embedded DTBs available match the hardware. What to
> do then ? At that point, the kernel code is such in an early stage that it
> cannot even display anything. That is the same situation with the current single
> BUILTIN dtb: if the dtb is wrong, the kernel will likely not boot.
>
> The current BUILTIN_DTB approach comes from other arch where that already
> exists. Nothing new here, and it looks like other arch at least didn't mind the
> end-result special kernel-for-this-paltform-only approach. We are talking about
> a tiny hardware/super embedded thing here. I sure would not want to use BUILTIN
> DTB for anything bigger then the Kendryte boards and this may be where we can
> improve using KConfig: allow selecting BUILTIN DTB only if the KENDRYTE SOC is
> selected ?
Well, the ARM stuff has a whole bunch of compile-time issues with supporting
multiple vendors' SOCs at the same time. That's proving to be a big headache.
>
> In the end, I would really like to see this series in 5.7 to enable all the
> hobbyist and hackers out there to more easily contribute improvements in this
> area. I do not see much problem with starting with the BUILTIN DTB as it is and
> improve on it as we go. There will not be any "backward compatibility" problems
> that I can see.
OK, I'll just go fix it.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-03 17:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-24 4:19 Kendryte K210 support v4 Damien Le Moal
2020-03-26 22:09 ` Palmer Dabbelt
2020-03-26 23:40 ` Damien Le Moal
2020-03-26 23:59 ` Palmer Dabbelt
2020-03-27 0:38 ` Damien Le Moal
2020-04-03 17:35 ` Palmer Dabbelt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).