ZynqMP APU RAM Start

Sebastian Huber sebastian.huber at embedded-brains.de
Tue May 14 15:38:58 UTC 2024


On 14.05.24 17:11, Kinsey Moore wrote:
> On Tue, May 14, 2024 at 1:28 AM Chris Johns <chrisj at rtems.org 
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 14/5/2024 4:04 pm, Sebastian Huber wrote:
>      > Hello,
>      >
>      > the ZynqMP APU RAM start addresses are far away from 0x0:
>      >
>      > cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
>      > SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>      > actions:
>      > - get-integer: null
>      > - assert-uint32: null
>      > - env-assign: null
>      > - format-and-define: null
>      > build-type: option
>      > copyrights:
>      > - Copyright (C) 2020 On-Line Applications Research (OAR)
>      > default:
>      > - enabled-by:
>      >   - aarch64/xilinx_zynqmp_lp64_a53
>      >   - aarch64/xilinx_zynqmp_ilp32_zu3eg
>      >   - aarch64/xilinx_zynqmp_lp64_cfc400x
>      >   - aarch64/xilinx_zynqmp_lp64_zu3eg
>      >   value: 0x10000000
>      > - enabled-by: true
>      >   value: 0x40018000
>      > description: |
>      >   base address of memory area available to the BSP
>      > enabled-by: true
>      > format: '{:#010x}'
>      > links: []
>      > name: BSP_XILINX_ZYNQMP_RAM_BASE
>      > type: build
>      >
>      > What is the rationale for doing this? Any objections to change
>     the start address
>      > to 0x0?
>     Not from me but existing workflows will break. Some things to keep
>     in mind:
> 
>     What is the default address used by Linux on this board and what
>     uboot expects?
> 
>     What do the Xilinx tools default to?
> 
> The load addresses here were taken from other examples when I was first 
> writing this port.
> 
> The QEMU load address is largely irrelevant since it reads it from the 
> ELF headers and locates it appropriately without other constraints.
> 
> The address used on hardware is due to u-boot typically loading at 
> 0x8000000, the RTEMS ELF being initially loaded in lower RAM space, and 
> then u-boot unpacking RTEMS into 0x10000000. Everything can be moved 
> around, of course.

Since the RPU cannot access the DDR RAM at 0x0, I suggest to locate the 
APU RAM at 0x0 and use half the size of the DDR RAM for the APU by 
default in the linker command file.

> 
>      > What is the MMU page size used by the BSPs? Would it be possible
>     to add a NULL
>      > pointer protection page?
> 
>     I am not sure.
> 
> 
> The MMU translation table page size is 4KB (0x1000) and the granularity 
> is also 4KB. This will likely need to become more flexible for modern 
> chips that drop 4K page size support as 16KB and 64KB become more 
> common. The 0x0 area is unmapped by default and so throws data aborts on 
> attempted access.

Since these boards usually have lots of DDR RAM available, I would 
switch to a 64KiB page size to reduce the amount of page table reloads 
from RAM. This would waste 64KiB for the NULL pointer protection and up 
to 128KiB at the text/read-only and read-only/read-write boundaries.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


More information about the devel mailing list