From: Yao Zi <me@ziyao.cc>
To: Andrei Lalaev <andrey.lalaev@gmail.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>, Chen Wang <chen.wang@linux.dev>,
Inochi Amaoto <inochiama@gmail.com>
Cc: devicetree@vger.kernel.org, sophgo@lists.linux.dev,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
Yao Zi <me@ziyao.cc>
Subject: Re: [PATCH] riscv: dts: sophgo: sg2000-milkv-duo-s: reserve memory for RTOS
Date: Wed, 16 Sep 2026 18:34:46 +0000 [thread overview]
Message-ID: <aqrhRic7Ww6fPhxg@pie> (raw)
In-Reply-To: <20260916-milkv-duo-s-rtos-memory-v1-1-6ca72d5a3924@gmail.com>
On Wed, Sep 16, 2026 at 06:06:30PM +0200, Andrei Lalaev wrote:
> The FSBL loads the coprocessor firmware into the last 2 MB of RAM.
> Reserve this region to prevent Linux from using it.
What if the coprocessor changes the load address, e.g., in a new
release, and how could we support other bootloader implementations
with this modification? Wouldn't the part of memory be wasted if no
coprocessor firmware is loaded at all?
It seems to me the best solution is to modify the FSBL to fix up the
devicetree to reserve memory where the coprocessor firmware is loaded
instead.
Anyway, this reserved region isn't defined by the hardware, thus we
shouldn't include it in the upstream Linux devicetree, since it should
describe the hardware.
> Signed-off-by: Andrei Lalaev <andrey.lalaev@gmail.com>
Best regards.
Yao Zi
prev parent reply other threads:[~2026-09-16 18:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 16:06 Andrei Lalaev
2026-09-16 17:10 ` Samuel Holland
2026-09-17 2:02 ` Inochi Amaoto
2026-09-17 3:27 ` Andrei Lalaev
2026-09-16 18:34 ` Yao Zi [this message]
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=aqrhRic7Ww6fPhxg@pie \
--to=me@ziyao.cc \
--cc=alex@ghiti.fr \
--cc=andrey.lalaev@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=chen.wang@linux.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=inochiama@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robh@kernel.org \
--cc=sophgo@lists.linux.dev \
/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
all inboxes | Powered by JetHome®