On 14.05.24 17:11, Kinsey Moore wrote:
On Tue, May 14, 2024 at 1:28 AM Chris Johns <chr...@rtems.org
<mailto:chr...@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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
