ZynqMP APU RAM Start

Kinsey Moore kinsey.moore at oarcorp.com
Tue May 14 15:11:40 UTC 2024


On Tue, May 14, 2024 at 1:28 AM Chris Johns <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.



> > 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.

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240514/c4f4dcc4/attachment.htm>


More information about the devel mailing list