<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 10:39 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</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.05.24 17:11, Kinsey Moore wrote:<br>
> On Tue, May 14, 2024 at 1:28 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
> <br>
> 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<br>
> the start address<br>
> > to 0x0?<br>
> Not from me but existing workflows will break. Some things to keep<br>
> in mind:<br>
> <br>
> What is the default address used by Linux on this board and what<br>
> uboot expects?<br>
> <br>
> What do the Xilinx tools default to?<br>
> <br>
> The load addresses here were taken from other examples when I was first <br>
> writing this port.<br>
> <br>
> The QEMU load address is largely irrelevant since it reads it from the <br>
> ELF headers and locates it appropriately without other constraints.<br>
> <br>
> The address used on hardware is due to u-boot typically loading at <br>
> 0x8000000, the RTEMS ELF being initially loaded in lower RAM space, and <br>
> then u-boot unpacking RTEMS into 0x10000000. Everything can be moved <br>
> around, of course.<br>
<br>
Since the RPU cannot access the DDR RAM at 0x0, I suggest to locate the <br>
APU RAM at 0x0 and use half the size of the DDR RAM for the APU by <br>
default in the linker command file.<br></blockquote><div><br></div><div>So the default RAM would be 256MB instead of the current 512MB. This seems reasonable and should be sufficient for any tests I'm aware of.</div><div><br></div><div>Regarding moving the code to 0x0, that would break null pointer detection. The vector table is currently mapped RWX due to AArch64 leaving room for 32 instructions per vector entry and the vector target being stored in that space alongside the vector entry preamble. This could be made RX, but that is work to be done.<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">
> <br>
> > What is the MMU page size used by the BSPs? Would it be possible<br>
> to add a NULL<br>
> > pointer protection page?<br>> The MMU translation table page size is 4KB (0x1000) and the granularity <br>
> is also 4KB. This will likely need to become more flexible for modern <br>
> chips that drop 4K page size support as 16KB and 64KB become more <br>
> common. The 0x0 area is unmapped by default and so throws data aborts on <br>
> attempted access.<br>
<br>
Since these boards usually have lots of DDR RAM available, I would <br>
switch to a 64KiB page size to reduce the amount of page table reloads <br>
from RAM. This would waste 64KiB for the NULL pointer protection and up <br>
to 128KiB at the text/read-only and read-only/read-write boundaries.<br></blockquote><div><br></div><div>The page table reloads required depend on how granular the mappings are. Large block mappings will only consume a few upper level entries instead of mapping each individual 4KB granule. RTEMS doesn't generally modify mappings, so mappings generated by translation table walks will only rarely be invalidated from the TLB. That said, supporting 64KB translation granules is worth the effort given the direction newer chips are going.</div><div><br></div><div>Be aware that we can't move everything over to 64KB blindly as there is no guarantee of support for any particular translation granule size; 4KB, 16KB, and 64KB are optionally and independently supported so any combination could exist. ZynqMP in particular supports 4KB and 64KB translation granules and I'm aware of at least 1 chip that only supports 16KB for practical purposes. QEMU's support for Cortex-A53 cores contradicts the Cortex-A53 TRM on many points of MMU support suggesting support of all granule sizes, wrong ASID size, and other issues though I'm sure QEMU does actually support those modes of operation.</div><div><br></div><div>If support for dynamic detection and configuration of granule size is desired, operation on QEMU will be even less representative of the ability to run on real hardware.</div><div><br></div><div>Kinsey<br></div></div></div>