<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2024 at 1:28 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14/5/2024 4:04 pm, Sebastian Huber wrote:<br>
> Hello,<br>
> <br>
> the ZynqMP APU RAM start addresses are far away from 0x0:<br>
> <br>
> cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml<br>
> SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause<br>
> actions:<br>
> - get-integer: null<br>
> - assert-uint32: null<br>
> - env-assign: null<br>
> - format-and-define: null<br>
> build-type: option<br>
> copyrights:<br>
> - Copyright (C) 2020 On-Line Applications Research (OAR)<br>
> default:<br>
> - enabled-by:<br>
>   - aarch64/xilinx_zynqmp_lp64_a53<br>
>   - aarch64/xilinx_zynqmp_ilp32_zu3eg<br>
>   - aarch64/xilinx_zynqmp_lp64_cfc400x<br>
>   - aarch64/xilinx_zynqmp_lp64_zu3eg<br>
>   value: 0x10000000<br>
> - enabled-by: true<br>
>   value: 0x40018000<br>
> description: |<br>
>   base address of memory area available to the BSP<br>
> enabled-by: true<br>
> format: '{:#010x}'<br>
> links: []<br>
> name: BSP_XILINX_ZYNQMP_RAM_BASE<br>
> type: build<br>
> <br>
> What is the rationale for doing this? Any objections to change the start address<br>
> to 0x0?<br>
Not from me but existing workflows will break. Some things to keep in mind:<br>
<br>
What is the default address used by Linux on this board and what uboot expects?<br>
<br>
What do the Xilinx tools default to?<br>
<br></blockquote><div>The load addresses here were taken from other examples when I was first writing this port.</div><div><br></div><div>The QEMU load address is largely irrelevant since it reads it from the ELF headers and locates it appropriately without other constraints.</div><div><br></div><div>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.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> What is the MMU page size used by the BSPs? Would it be possible to add a NULL<br>
> pointer protection page?<br>
<br>
I am not sure.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Kinsey<br></div><div> </div></div></div>