From: Devarsh Thakkar <devarsht@ti.com>
To: <u-boot@lists.denx.de>, <sjg@chromium.org>, <agust@denx.de>,
<trini@konsulko.com>, <bmeng.cn@gmail.com>, <msuchanek@suse.de>,
<rasmus.villemoes@prevas.dk>, <yangshiji66@outlook.com>
Cc: <praneeth@ti.com>, <nm@ti.com>, <vigneshr@ti.com>,
<a-bhatia1@ti.com>, <j-luthra@ti.com>, <nsekhar@ti.com>,
<n-jain1@ti.com>, <devarsht@ti.com>
Subject: [PATCH v5 8/8] doc: spl: Add info regarding memory reservation
Date: Tue, 5 Dec 2023 21:25:23 +0530 [thread overview]
Message-ID: <20231205155523.721784-9-devarsht@ti.com> (raw)
In-Reply-To: <20231205155523.721784-1-devarsht@ti.com>
Add details regarding scheme which need to be followed in SPL and
further stages for those regions which need to be preserved across
bootstages.
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
Reviewed-by: Simon Glass <sjg@chromium>
---
V1->V3:
No change.
V4:
Split this to separate patch and add more details regarding
memory reservation scheme that needs to be followed at SPL.
V5:
Add Reviewed-By
---
doc/develop/spl.rst | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst
index 814530d348..0a3e572310 100644
--- a/doc/develop/spl.rst
+++ b/doc/develop/spl.rst
@@ -173,3 +173,31 @@ cflow will spit out a number of warnings as it does not parse
the config files and picks functions based on #ifdef. Parsing the '.i'
files instead introduces another set of headaches. These warnings are
not usually important to understanding the flow, however.
+
+
+Reserving memory in SPL
+-----------------------
+
+If memory needs to be reserved in RAM during SPL stage with the requirement that
+the SPL reserved memory remains preserved across further boot stages too
+then it needs to be reserved mandatorily starting from end of RAM. This is to
+ensure that further stages can simply skip this region before carrying out
+further reservations or updating the relocation address.
+
+Also out of these regions which are to be preserved across further stages of
+boot, video framebuffer memory region must be reserved first starting from
+end of RAM for which helper function spl_reserve_video_from_ram_top is provided
+which makes sure that video memory is placed at top of reservation area with
+further reservations below it.
+
+The corresponding information of reservation for those regions can be passed to
+further boot stages using a bloblist. For e.g. the information for
+framebuffer area reserved by SPL can be passed onto U-boot using
+BLOBLISTT_U_BOOT_VIDEO.
+
+The further boot stages need to parse each of the bloblist passed from SPL stage
+starting from video bloblist and skip this whole SPL reserved memory area from
+end of RAM as per the bloblists received, before carrying out further
+reservations or updating the relocation address. For e.g, U-boot proper uses
+function "setup_relocaddr_from_bloblist" to parse the bloblists passed from
+previous stage and skip the memory reserved from previous stage accordingly.
--
2.34.1
next prev parent reply other threads:[~2023-12-05 15:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 15:55 [PATCH v5 0/8] Move framebuffer reservation for SPL to RAM end Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 1/8] spl: Enforce framebuffer reservation from end of RAM Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 2/8] arm: mach-k3: common: Reserve video memory from end of the RAM Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 3/8] board: ti: am62x: evm: Remove video_setup from spl_board_init Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 4/8] common/board_f: Catch bloblist before starting reservations Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 5/8] video: Skip framebuffer reservation if already reserved Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 6/8] video: Fill video handoff in video post probe Devarsh Thakkar
2023-12-05 15:55 ` [PATCH v5 7/8] doc: spl: Add info for missing Kconfigs Devarsh Thakkar
2023-12-05 15:55 ` Devarsh Thakkar [this message]
2023-12-13 14:56 ` [PATCH v5 0/8] Move framebuffer reservation for SPL to RAM end Devarsh Thakkar
2023-12-26 9:47 ` Simon Glass
2024-01-08 8:02 ` Devarsh Thakkar
2024-01-29 16:11 ` Devarsh Thakkar
2024-01-30 1:54 ` Tom Rini
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=20231205155523.721784-9-devarsht@ti.com \
--to=devarsht@ti.com \
--cc=a-bhatia1@ti.com \
--cc=agust@denx.de \
--cc=bmeng.cn@gmail.com \
--cc=j-luthra@ti.com \
--cc=msuchanek@suse.de \
--cc=n-jain1@ti.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=praneeth@ti.com \
--cc=rasmus.villemoes@prevas.dk \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.com \
--cc=yangshiji66@outlook.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