From: Atish Patra <Atish.Patra@wdc.com>
To: "atishp@atishpatra.org" <atishp@atishpatra.org>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
"seanga2@gmail.com" <seanga2@gmail.com>
Cc: "linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
Anup Patel <Anup.Patel@wdc.com>,
"palmer@dabbelt.com" <palmer@dabbelt.com>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>
Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
Date: Sat, 7 Mar 2020 01:51:27 +0000 [thread overview]
Message-ID: <38c188169a59df88bafc2ade4eb4f642dbe07582.camel@wdc.com> (raw)
In-Reply-To: <c84b632a-9372-fcbf-de3d-be016d36a970@gmail.com>
On Fri, 2020-03-06 at 19:02 -0500, Sean Anderson wrote:
> On 3/5/20 3:18 AM, Atish Patra wrote:
> > On Wed, Mar 4, 2020 at 9:14 PM Damien Le Moal <
> > Damien.LeMoal@wdc.com> wrote:
> > > On 2020/03/05 13:58, Anup Patel wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Palmer Dabbelt <palmer@dabbelt.com>
> > > > > Sent: 05 March 2020 00:59
> > > > > To: Damien Le Moal <Damien.LeMoal@wdc.com>
> > > > > Cc: linux-riscv@lists.infradead.org; Paul Walmsley
> > > > > <paul.walmsley@sifive.com>; Anup Patel <Anup.Patel@wdc.com>
> > > > > Subject: Re: [PATCH 04/10] riscv: Add BUILTIN_DTB support
> > > > >
> > > > > On Wed, 12 Feb 2020 02:34:26 PST (-0800), Damien Le Moal
> > > > > wrote:
> > > > > > Enable a kernel builtin dtb for boards not capable of
> > > > > > providing a
> > > > > > device tree to the kernel.
> > > > >
> > > > > I'd prefer if we picked a mechanism that allows a single
> > > > > kernel binary to be
> > > > > run on multiple systems. I think there's two use cases here:
> > > >
> > > > I strongly support "single kernel binary for multiple systems"
> > > > but it's for
> > > > different purpose here.
> > > >
> > > > > * Bootloaders that provide no DTB at all.
> > > > > * Bootloaders that provied a DTB that, for some reason, isn't
> > > > > usable.
> > >
> > > Sure, but as Anup mentions below, the current use case it to not
> > > even use any
> > > bootloader at all for the K210 since that brings no value at all
> > > (in my
> > > opinion). More on this below.
> > >
> > > > > Given those constraints, could we do something similar to the
> > > > > early fixups?
> > > > > I'm thinking we could build a mapping between a hardware
> > > > > identifier and a
> > > > > DTB, then look up the DTB we want to use. Users that want a
> > > > > kernel that
> > > > > only runs on a single device can do so by configuring only a
> > > > > single DTB, users
> > > > > that want a more portable kernel can select a bunch -- that's
> > > > > essentially the
> > > > > same as how we're treating everything else (for example, the
> > > > > CONFIG_SOC_* stuff).
> > > >
> > > > There is no bootloader on Kendryte K210. The Linux RISC-V NOMMU
> > > > kernel
> > > > boots directly. The BUILTIN_DTB is only applicable to cases
> > > > where there is
> > > > no bootloader before kernel.
> > > >
> > > > The Linux RISC-V NOMMU will tend be used in cases where:
> > > > 1. There is no bootloader and kernel boots directly hence we
> > > > need
> > > > builtin DTB feature.
> > > > 2. There is very less RAM so we will have to build kernel
> > > > specific to
> > > > a particular platform with bare minimum drivers. Due to this,
> > > > we will
> > > > have separate defconfig for NOMMU platforms.
> > > >
> > > > I think point1 can be tackled if we enforce having bootloader
> > > > (such as U-Boot)
> > > > for NOMMU systems and drop this patch.
> > >
> > > But that would go against point 2 as that will use more memory...
> > > By "drop this
> > > patch", may be you meant to say "not use this config option" ?
> > >
> > > > For point2 above, we don't have much alternatives other than
> > > > reducing
> > > > kernel binary size by disabling unwanted drivers.
> > >
> > > And not using a boot loader. Sean got U-boot working with
> > > Kendryte, so it is not
> > > that we cannot make it work. It is only that it may be less
> > > optimal due to the
> > > memory used by the boot loader itself. Unless we can recover it
> > > if the kernel
> > > relocate itself over it ? Surely doable, but it does sound to me
> > > like an
> > > overkill for this particular use case, i.e. a tiny, hyper-
> > > embedded board where
> > > running Linux is probably not the best choice in the first place,
> > > at least when
> > > looking at real applications. The story is different for
> > > "hobbyist" level. My
> > > on-going 6 DoF robotic arm project controlled with Linux on K210
> > > is a valid use
> > > case after all :)
> > >
> >
> > Just a thought: How about keeping the loader out of kernel as a
> > separate project as a tinyloader ?
> > That tinyloader project can host the DTB and pass it to kernel in
> > a1
> > register. This tinyloader can be used for
> > any M-mode only platforms with memory constraints. If platform has
> > sufficient memory and supports U-boot, users can use that as well.
> > That will allow single kernel image to boot all the platforms and
> > we
> > can mandate one booting protocol for all platforms.
> > Otherwise, we have to specify different booting protocol for
> > M-Mode/NoMMU linux and S-mode Linux.
> > In future, there may be more platforms with Builtin DTB request as
> > well.
>
> Couldn't this sort of thing be done by SBI? OpenSBI currently has a
> port
> for the K210. The only issue with SBI in general is that there is no
> way
> to set the VM mode, since it is stored in mstatus and not satp on
> older
> priv spec versions. There used to be a proposal related to this, but
> they chose to change the location of the VM mode rather than have SBI
> or
> some other bootloader set it. I think one of the ideas was for SBI to
> set the mode based off the mmu-type property.
>
Just to avoid confusion: SBI is the specification and OpenSBI is the
implementation. I think you meant OpenSBI here. It is possible but the
question is whether it should be done by OpenSBI. Because OpenSBI is
supposed to provide the SBI implementation. As NOMMU Linux doesn't need
any of the SBI, I think it would be unnecessary to keep the OpenSBI
code resident after Linux boots.
I think U-Boot or a separate loader is an ideal solution but I see
your U-Boot patches mention that loading an Image still is an issue.
However, everybody needs to agree that booting single Linux kernel
image on all boards(at least supported in upstream Linux)
can be documented as a hard requirement before we discuss more on this
topic. If that is possible, it is easier to enforce booting protocol
(a0 - hartid, a1 - DTB and no builtin DTB) as well. I am not sure if
that is the best approach but that's what we have currently.
> --Sean
>
--
Regards,
Atish
next prev parent reply other threads:[~2020-03-07 1:51 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-12 10:34 [PATCH 00/10] Kendryte k210 SoC boards support Damien Le Moal
2020-02-12 10:34 ` [PATCH 01/10] riscv: Fix gitignore Damien Le Moal
2020-02-20 0:15 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 02/10] riscv: Force flat memory model with no-mmu Damien Le Moal
2020-02-14 20:18 ` Sean Anderson
2020-02-15 2:15 ` Damien Le Moal
2020-02-15 2:26 ` Sean Anderson
2020-02-15 2:40 ` Damien Le Moal
2020-03-02 3:48 ` Anup Patel
2020-03-04 18:38 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 03/10] riscv: Unaligned load/store handling for M_MODE Damien Le Moal
2020-03-02 3:57 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 04/10] riscv: Add BUILTIN_DTB support Damien Le Moal
2020-03-02 3:58 ` Anup Patel
2020-03-04 19:28 ` Palmer Dabbelt
2020-03-05 4:58 ` Anup Patel
2020-03-05 5:14 ` Damien Le Moal
2020-03-05 5:37 ` Anup Patel
2020-03-05 6:13 ` Damien Le Moal
2020-03-08 6:10 ` Anup Patel
2020-03-05 8:18 ` Atish Patra
2020-03-07 0:02 ` Sean Anderson
2020-03-07 1:51 ` Atish Patra [this message]
2020-03-07 2:08 ` Sean Anderson
2020-03-06 23:56 ` Sean Anderson
2020-02-12 10:34 ` [PATCH 05/10] riscv: Add SOC early init support Damien Le Moal
2020-03-04 19:28 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 06/10] riscv: Add Kendryte K210 SoC support Damien Le Moal
2020-02-14 20:31 ` Sean Anderson
2020-03-04 19:38 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 07/10] riscv: Select required drivers for Kendryte SOC Damien Le Moal
2020-03-02 3:59 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 08/10] riscv: Add Kendryte K210 device tree Damien Le Moal
2020-02-14 20:51 ` Sean Anderson
2020-02-15 2:34 ` Damien Le Moal
2020-02-15 2:48 ` Sean Anderson
2020-02-15 3:00 ` Damien Le Moal
2020-02-18 14:12 ` Carlos Eduardo de Paula
2020-02-18 14:18 ` Sean Anderson
2020-02-18 14:30 ` Carlos Eduardo de Paula
2020-02-18 17:48 ` Sean Anderson
2020-02-18 19:26 ` Carlos Eduardo de Paula
2020-02-19 9:06 ` Wladimir J. van der Laan
2020-02-19 22:28 ` Sean Anderson
2020-02-20 10:48 ` Wladimir J. van der Laan
2020-02-22 19:07 ` Wladimir J. van der Laan
2020-04-01 17:55 ` Drew Fustini
2020-04-02 2:24 ` Damien Le Moal
2020-02-19 8:50 ` Wladimir J. van der Laan
2020-02-27 19:43 ` Sean Anderson
2020-03-02 4:06 ` Anup Patel
2020-03-02 4:15 ` Damien Le Moal
2020-03-02 4:22 ` Anup Patel
2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:05 ` Anup Patel
2020-03-02 5:08 ` Damien Le Moal
2020-03-07 0:18 ` Sean Anderson
2020-03-07 4:11 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 09/10] riscv: Kendryte K210 default config Damien Le Moal
2020-03-02 4:07 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-12 10:34 ` [PATCH 10/10] riscv: create a loader.bin for the kendryte kflash.py tool Damien Le Moal
2020-03-02 4:08 ` Anup Patel
2020-03-04 19:44 ` Palmer Dabbelt
2020-02-14 15:05 ` [PATCH 00/10] Kendryte k210 SoC boards support Carlos Eduardo de Paula
2020-02-15 2:02 ` Damien Le Moal
2020-02-17 13:28 ` Carlos Eduardo de Paula
2020-02-26 21:31 ` Carlos Eduardo de Paula
2020-02-27 2:18 ` Damien Le Moal
2020-02-28 20:32 ` Sean Anderson
2020-03-02 3:01 ` Damien Le Moal
2020-03-02 3:53 ` Sean Anderson
2020-03-02 4:11 ` Damien Le Moal
2020-03-02 4:18 ` Sean Anderson
2020-03-02 4:54 ` Damien Le Moal
2020-03-02 4:56 ` Sean Anderson
2020-03-02 5:03 ` Damien Le Moal
2020-03-02 4:17 ` Anup Patel
2020-03-02 4:21 ` Sean Anderson
2020-03-02 4:48 ` Damien Le Moal
2020-03-02 4:51 ` Damien Le Moal
2020-03-02 5:02 ` Sean Anderson
2020-03-02 5:11 ` Damien Le Moal
2020-03-02 5:25 ` Sean Anderson
2020-03-02 5:43 ` Damien Le Moal
2020-03-04 19:44 ` 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=38c188169a59df88bafc2ade4eb4f642dbe07582.camel@wdc.com \
--to=atish.patra@wdc.com \
--cc=Anup.Patel@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=atishp@atishpatra.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=seanga2@gmail.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).