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