All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: linux-riscv@lists.infradead.org
Cc: Anup Patel <anup@brainfault.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	atishp@rivosinc.com,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Guo Ren <guoren@linux.alibaba.com>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Guo Ren <guoren@kernel.org>
Subject: Re: [RFC PATCH 0/3] riscv: Add riscv.fwsz kernel parameter to save memory
Date: Wed, 24 Nov 2021 13:16:13 +0100	[thread overview]
Message-ID: <6883721.WJZ4dBXcaH@diego> (raw)
In-Reply-To: <CAJF2gTSwousS4DHWuqprkkckbRa-J=M_a5vSVJ5CiAjDvqGh9w@mail.gmail.com>

Am Mittwoch, 24. November 2021, 07:42:17 CET schrieb Guo Ren:
> On Wed, Nov 24, 2021 at 3:33 AM Heiko Stübner <heiko@sntech.de> wrote:
> >
> > Hi Guo,
> >
> > Am Dienstag, 23. November 2021, 02:57:14 CET schrieb guoren@kernel.org:
> > > From: Guo Ren <guoren@linux.alibaba.com>
> > >
> > > The firmware of riscv (such as opensbi) occupy 2MB(64bit) /
> > > 4MB(32bit) in Linux. It's very wasteful to small memory footprint
> > > soc chip such as Allwinner D1s/F133. The kernel parameter gives a
> > > chance to users to set the proper size of the firmware and get
> > > more than 1.5MB of memory.
> >
> > is this kernel parameter approach a result of the T-Head Ice-SoC
> > currently loading its openSBI from inside the main u-boot via extfs-load,
> > directly before the kernel itself [0] ?
> The patch is not related to that issue. The patch just helps users who
> put opensbi at 0~2MB paddr to save memory.

So as Anup wrote, this should just be solved by using a correct reserved memory
node in the devicetree passed to the kernel. And the firmware will know what
memory region it actually occupies ;-)


> 
> >
> > Because that approach in general looks not ideal.
> >
> > Normally you want the main u-boot already running with less privileges
> > so firmware like openSBI should've been already loaded before that.
> > Even more true when you're employing methods to protect memory regions
> > from less privileged access.
> >
> > A lot of socs set u-boot as opensbi payload, but for the example the D1
> > mainline approach uses the Allwinner TOC1 image format to load both
> > opensbi and the main uboot into memory from its 1st stage loader.
> >
> >
> > Of course the best way would be to just mimic what a number of
> > arm64 and also riscv socs do and use already existing u-boot utilities.
> >
> > U-Boot can create a FIT image containing both main u-boot, dtb and
> > firmware images that all get loaded from SPL and placed at the correct
> > addresses before having the SPL jump into opensbi and from there
> > into u-boot [1] .
> >
> > And as Anup was writing, reserved-memory should then be the way
> > to go to tell the kernel what regions to omit.
> >
> > And mainline u-boot has already the means to even take the reserved-memory
> > from the devicetree used by opensbi and copy it to a new devicetree,
> > if the second one is different.
> >
> >
> > Heiko
> >
> >
> > [0] https://github.com/T-head-Semi/u-boot/blob/main/include/configs/ice-c910.h#L46
> > [1] see spl_invoke_opensbi() in common/spl/spl_opensbi.c
> > [2] see riscv_board_reserved_mem_fixup() in arch/riscv/lib/fdt_fixup.c
> >
> > >
> > > Guo Ren (3):
> > >   riscv: Remove 2MB offset in the mm layout
> > >   riscv: Add early_param to decrease firmware region
> > >   riscv: Add riscv.fwsz kernel parameter
> > >
> > >  .../admin-guide/kernel-parameters.txt         |  3 +++
> > >  arch/riscv/include/asm/page.h                 |  8 +++++++
> > >  arch/riscv/kernel/head.S                      | 10 +++-----
> > >  arch/riscv/kernel/vmlinux.lds.S               |  5 ++--
> > >  arch/riscv/mm/init.c                          | 23 ++++++++++++++++---
> > >  5 files changed, 36 insertions(+), 13 deletions(-)
> > >
> > >
> >
> >
> >
> >
> 
> 
> 





WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: linux-riscv@lists.infradead.org
Cc: Anup Patel <anup@brainfault.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	atishp@rivosinc.com,
	linux-riscv <linux-riscv@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Guo Ren <guoren@linux.alibaba.com>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Guo Ren <guoren@kernel.org>
Subject: Re: [RFC PATCH 0/3] riscv: Add riscv.fwsz kernel parameter to save memory
Date: Wed, 24 Nov 2021 13:16:13 +0100	[thread overview]
Message-ID: <6883721.WJZ4dBXcaH@diego> (raw)
In-Reply-To: <CAJF2gTSwousS4DHWuqprkkckbRa-J=M_a5vSVJ5CiAjDvqGh9w@mail.gmail.com>

Am Mittwoch, 24. November 2021, 07:42:17 CET schrieb Guo Ren:
> On Wed, Nov 24, 2021 at 3:33 AM Heiko Stübner <heiko@sntech.de> wrote:
> >
> > Hi Guo,
> >
> > Am Dienstag, 23. November 2021, 02:57:14 CET schrieb guoren@kernel.org:
> > > From: Guo Ren <guoren@linux.alibaba.com>
> > >
> > > The firmware of riscv (such as opensbi) occupy 2MB(64bit) /
> > > 4MB(32bit) in Linux. It's very wasteful to small memory footprint
> > > soc chip such as Allwinner D1s/F133. The kernel parameter gives a
> > > chance to users to set the proper size of the firmware and get
> > > more than 1.5MB of memory.
> >
> > is this kernel parameter approach a result of the T-Head Ice-SoC
> > currently loading its openSBI from inside the main u-boot via extfs-load,
> > directly before the kernel itself [0] ?
> The patch is not related to that issue. The patch just helps users who
> put opensbi at 0~2MB paddr to save memory.

So as Anup wrote, this should just be solved by using a correct reserved memory
node in the devicetree passed to the kernel. And the firmware will know what
memory region it actually occupies ;-)


> 
> >
> > Because that approach in general looks not ideal.
> >
> > Normally you want the main u-boot already running with less privileges
> > so firmware like openSBI should've been already loaded before that.
> > Even more true when you're employing methods to protect memory regions
> > from less privileged access.
> >
> > A lot of socs set u-boot as opensbi payload, but for the example the D1
> > mainline approach uses the Allwinner TOC1 image format to load both
> > opensbi and the main uboot into memory from its 1st stage loader.
> >
> >
> > Of course the best way would be to just mimic what a number of
> > arm64 and also riscv socs do and use already existing u-boot utilities.
> >
> > U-Boot can create a FIT image containing both main u-boot, dtb and
> > firmware images that all get loaded from SPL and placed at the correct
> > addresses before having the SPL jump into opensbi and from there
> > into u-boot [1] .
> >
> > And as Anup was writing, reserved-memory should then be the way
> > to go to tell the kernel what regions to omit.
> >
> > And mainline u-boot has already the means to even take the reserved-memory
> > from the devicetree used by opensbi and copy it to a new devicetree,
> > if the second one is different.
> >
> >
> > Heiko
> >
> >
> > [0] https://github.com/T-head-Semi/u-boot/blob/main/include/configs/ice-c910.h#L46
> > [1] see spl_invoke_opensbi() in common/spl/spl_opensbi.c
> > [2] see riscv_board_reserved_mem_fixup() in arch/riscv/lib/fdt_fixup.c
> >
> > >
> > > Guo Ren (3):
> > >   riscv: Remove 2MB offset in the mm layout
> > >   riscv: Add early_param to decrease firmware region
> > >   riscv: Add riscv.fwsz kernel parameter
> > >
> > >  .../admin-guide/kernel-parameters.txt         |  3 +++
> > >  arch/riscv/include/asm/page.h                 |  8 +++++++
> > >  arch/riscv/kernel/head.S                      | 10 +++-----
> > >  arch/riscv/kernel/vmlinux.lds.S               |  5 ++--
> > >  arch/riscv/mm/init.c                          | 23 ++++++++++++++++---
> > >  5 files changed, 36 insertions(+), 13 deletions(-)
> > >
> > >
> >
> >
> >
> >
> 
> 
> 





_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2021-11-24 12:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23  1:57 [RFC PATCH 0/3] riscv: Add riscv.fwsz kernel parameter to save memory guoren
2021-11-23  1:57 ` guoren
2021-11-23  1:57 ` [RFC PATCH 1/3] riscv: Remove 2MB offset in the mm layout guoren
2021-11-23  1:57   ` guoren
2021-11-23  3:56   ` Anup Patel
2021-11-23  3:56     ` Anup Patel
2021-11-23  6:18     ` Guo Ren
2021-11-23  6:18       ` Guo Ren
2021-11-23 13:37     ` Alexandre Ghiti
2021-11-23 13:37       ` Alexandre Ghiti
2021-11-24 11:58       ` Guo Ren
2021-11-24 11:58         ` Guo Ren
2021-11-24 15:09         ` Alexandre ghiti
2021-11-24 15:09           ` Alexandre ghiti
2021-11-23  1:57 ` [RFC PATCH 2/3] riscv: Add early_param to decrease firmware region guoren
2021-11-23  1:57   ` guoren
2021-11-23  3:44   ` Anup Patel
2021-11-23  3:44     ` Anup Patel
2021-11-23 11:53     ` Jessica Clarke
2021-11-23 11:53       ` Jessica Clarke
2021-11-23 13:37       ` Alexandre Ghiti
2021-11-23 13:37         ` Alexandre Ghiti
2021-11-23  1:57 ` [RFC PATCH 3/3] riscv: Add riscv.fwsz kernel parameter guoren
2021-11-23  1:57   ` guoren
2021-11-23  2:34   ` Randy Dunlap
2021-11-23  2:34     ` Randy Dunlap
2021-11-23  3:21     ` Guo Ren
2021-11-23  3:21       ` Guo Ren
2021-11-23  3:45   ` Anup Patel
2021-11-23  3:45     ` Anup Patel
2021-11-23 19:33 ` [RFC PATCH 0/3] riscv: Add riscv.fwsz kernel parameter to save memory Heiko Stübner
2021-11-23 19:33   ` Heiko Stübner
2021-11-23 20:01   ` Atish Patra
2021-11-23 20:01     ` Atish Patra
2021-11-23 21:50     ` Heiko Stübner
2021-11-23 21:50       ` Heiko Stübner
2021-11-24  6:49     ` Guo Ren
2021-11-24  6:49       ` Guo Ren
2021-11-24 12:13       ` Heiko Stübner
2021-11-24 12:13         ` Heiko Stübner
2021-11-24 14:25         ` Guo Ren
2021-11-24 14:25           ` Guo Ren
2021-11-24  6:42   ` Guo Ren
2021-11-24  6:42     ` Guo Ren
2021-11-24 12:16     ` Heiko Stübner [this message]
2021-11-24 12:16       ` Heiko Stübner

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=6883721.WJZ4dBXcaH@diego \
    --to=heiko@sntech.de \
    --cc=anup@brainfault.org \
    --cc=atishp@rivosinc.com \
    --cc=guoren@kernel.org \
    --cc=guoren@linux.alibaba.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=philipp.tomsich@vrull.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.