Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>
Subject: Re: Kendryte K210 support v4
Date: Fri, 27 Mar 2020 00:38:50 +0000
Message-ID: <CO2PR04MB2343F5DC42542E7FC9268FF2E7CC0@CO2PR04MB2343.namprd04.prod.outlook.com> (raw)
In-Reply-To: <mhng-9925e921-28e5-4f0d-8f93-3958d8226e11@palmerdabbelt-glaptop1>

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


  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24  4:19 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 [this message]
2020-04-03 17:35         ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO2PR04MB2343F5DC42542E7FC9268FF2E7CC0@CO2PR04MB2343.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmerdabbelt@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git