Skip to content
Snippets Groups Projects
Commit 77a93ae6 authored by Simon Glass's avatar Simon Glass Committed by Tom Rini
Browse files

doc: Move the generic memory-documentation to doc/


Move this section of the README into doc/ with some minor updates to
mention SPL and user lower-case hex.

Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
Acked-by: default avatarHeinrich Schuchardt <heinrich.schuchardt@canonical.com>
parent b03b2a45
No related branches found
No related tags found
No related merge requests found
......@@ -2516,51 +2516,6 @@ On RISC-V, the following registers are used:
==> U-Boot will use gp to hold a pointer to the global data
Memory Management:
------------------
U-Boot runs in system state and uses physical addresses, i.e. the
MMU is not used either for address mapping nor for memory protection.
The available memory is mapped to fixed addresses using the memory
controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical memory banks.
U-Boot is installed in the first 128 kB of the first Flash bank (on
TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
booting and sizing and initializing DRAM, the code relocates itself
to the upper end of DRAM. Immediately below the U-Boot code some
memory is reserved for use by malloc() [see CONFIG_SYS_MALLOC_LEN
configuration setting]. Below that, a structure with global Board
Info data is placed, followed by the stack (growing downward).
Additionally, some exception handler code is copied to the low 8 kB
of DRAM (0x00000000 ... 0x00001FFF).
So a typical memory configuration with 16 MB of DRAM could look like
this:
0x0000 0000 Exception Vector code
:
0x0000 1FFF
0x0000 2000 Free for Application Use
:
:
:
:
0x00FB FF20 Monitor Stack (Growing downward)
0x00FB FFAC Board Info Data and permanent copy of global data
0x00FC 0000 Malloc Arena
:
0x00FD FFFF
0x00FE 0000 RAM Copy of Monitor Code
... eventually: LCD or video framebuffer
... eventually: pRAM (Protected RAM - unchanged by reset)
0x00FF FFFF [End of RAM]
System Initialization:
----------------------
......
......@@ -13,6 +13,7 @@ General
codingstyle
designprinciples
docstyle
memory
patman
process
release_cycle
......
.. SPDX-License-Identifier: GPL-2.0-or-later
Memory Management
-----------------
.. note::
This information is outdated and needs to be updated.
U-Boot runs in system state and uses physical addresses, i.e. the
MMU is not used either for address mapping nor for memory protection.
The available memory is mapped to fixed addresses using the
memory-controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical-memory banks.
U-Boot is installed in XIP flash memory, or may be loaded into a lower region of
RAM by a secondary program loader (SPL). After
booting and sizing and initialising DRAM, the code relocates itself
to the upper end of DRAM. Immediately below the U-Boot code some
memory is reserved for use by malloc() [see CONFIG_SYS_MALLOC_LEN
configuration setting]. Below that, a structure with global Board-Info
data is placed, followed by the stack (growing downward).
Additionally, some exception handler code may be copied to the low 8 kB
of DRAM (0x00000000 ... 0x00001fff).
So a typical memory configuration with 16 MB of DRAM could look like
this::
0x0000 0000 Exception Vector code
:
0x0000 1fff
0x0000 2000 Free for Application Use
:
:
:
:
0x00fb ff20 Monitor Stack (Growing downward)
0x00fb ffac Board Info Data and permanent copy of global data
0x00fc 0000 Malloc Arena
:
0x00fd ffff
0x00fe 0000 RAM Copy of Monitor Code
... eventually: LCD or video framebuffer
... eventually: pRAM (Protected RAM - unchanged by reset)
0x00ff ffff [End of RAM]
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment