From: Peter Maydell <[email protected]>To: Chao Liu <[email protected]>On Mon, 7 Oct 2024 at 12:25, Chao Liu <[email protected]> wrote:>> Hi, maintainer,>> Following the reference from the chip manualug585-Zynq-7000-TRM manual> B.3 (Module Summary), placeholders have been added for all unimplemented> devices, including the AXI and AMBA bus controllers that interact with> the FPGA.>> We can check against the manual by printing the address space of the> zynq board with the following qemu command:>     ${QEMU_PATH}/qemu-system-aarch64 \>     -M xilinx-zynq-a9 \>     -display none \>     -monitor stdio -s>     (qemu) info mtree -f>> The testing methodology previously discussed in earlier email exchanges> will not be repeated here.>> Chao Liu (3):>   xilink_zynq: Add various missing unimplemented devices>   xilink-zynq-devcfg: Fix up for memory address range size not set>     correctly>   xilink-zynq-devcfg: Avoid disabling devcfg memory region during>     initializationI've left comments for patches 2 and 3. I have taken patch 1into target-arm.next, with the ignore_memory_transaction_failuresline reinstated.I'm all in favour of our being able to get rid of thatlegacy flag setting for this board, but as I've said onprevious versions of this patchset, we need to haveconfidence that it's not going to break existing guestcode, which means the patch removing it needs to comewith a description of the testing that's been done(which should be more than "Linux still boots").thanks-- PMM

Unlock Register: This register is used to protect the DEVCI configuration registers from ROM code corruption. The boot ROM will unlock the DEVCI by writing 0x757BDF0D to this register. Writing anything other than the unlock word to this register will cause an illegal access state and make the DEVCI inaccessible until a system reset occurs.

Hi, maintainer,Following the reference from the chip manualug585-Zynq-7000-TRM manualB.3 (Module Summary), placeholders have been added for all unimplementeddevices, including the AXI and AMBA bus controllers that interact withthe FPGA.We can check against the manual by printing the address space of thezynq board with the following qemu command:    ${QEMU_PATH}/qemu-system-aarch64 \    -M xilinx-zynq-a9 \    -display none \    -monitor stdio -s    (qemu) info mtree -fThe testing methodology previously discussed in earlier email exchangeswill not be repeated here.Chao Liu (3):  xilink_zynq: Add various missing unimplemented devices  xilink-zynq-devcfg: Fix up for memory address range size not set    correctly  xilink-zynq-devcfg: Avoid disabling devcfg memory region during    initialization hw/arm/xilinx_zynq.c              | 71 ++++++++++++++++++++++++++++++- hw/dma/xlnx-zynq-devcfg.c         |  9 +++- include/hw/dma/xlnx-zynq-devcfg.h |  2 +- 3 files changed, 78 insertions(+), 4 deletions(-)

Hi all,Following the Zynq-7000 SoC Data Sheet's "Memory Map" section (referenced at [1]),We have identified the need to create placeholders for unimplemented devicesacross the entire range of Zynq-7000 series boards.This effort aims at ensuring maximum compatibility with different modelswithin the series.The following table summarizes the relevant memory map addressesfor the Zynq-7000:    Start Address  Size (MB)       Description    0x0000_0000    1,024           DDR DRAM and on-chip memory (OCM)    0x4000_0000    1,024           PL AXI slave port #0    0x8000_0000    1,024           PL AXI slave port #1    0xE000_0000    256             IOP devices    0xF000_0000    128             Reserved    0xF800_0000    32              Programmable registers access via AMBA APB bus    0xFA00_0000    32              Reserved    0xFC00_0000    64 MB - 256 KB  Quad-SPI linear address base address (except                                   to 256 KB which is in OCM), 64 MB reserved,                                   only 32 MB is currently supported    0xFFFC_0000    256 KB          OCM when mapped to high address spaceFor the purposes of this patch, we will not be creating placeholders forDRAM and any reserved regions of the address space.A test script has been developed that covers the most common board types ofthe Zynq-7000 series.The test script obtained all linux binary images of the zynq-7000 series boardsfrom xilinx-wiki for script testing(referenced at [2]).The steps to run the test are as follows:    a) Clone the repository.    git clone -b xilinx-zynq-test https://github.com/gevico/qemu-board.git    b) Apply the patch attached to this email and compile QEMU.    c) Set the environment variable for the path to your QEMU.    export QEMU_PATH=<your qemu path>    d) Execute the testing script.    ./qemu-zynq-test    e) Check the results.    If successful, the output should resemble the following:    Test Project: <your path>/qemu-board/hw/arm/xilinx-zynq        Start 1: xilinx-zynq.zc702    1/3 Test #1: xilinx-zynq.zc702 ......................   Passed        Start 2: xilinx-zynq.zc706    2/3 Test #2: xilinx-zynq.zc706 ......................   Passed        Start 3: xilinx-zynq.zed      3/3 Test #3: xilinx-zynq.zed   ......................   Passed    All tests passedSee:[1]: https://www.amd.com/content/dam/xilinx/support/documents/data_sheets/ds190-Zynq-7000-Overview.pdf[2]: http://www.wiki.xilinx.com/Zynq+2016.2+Release

There are two things we can do:(1) We can leave the ignore_memory_transaction_failuresflag set. This is safe (no behaviour change) but not theright (matching the hardware) behaviour. The main reasonto do this is if we don't feel we have enough access toa range of guest code to test the other approach.(2) We can clear the flag. This is preferable (it matches thehardware). But the requirement to do this is that (a) we must make the best effort we can to be sure we've     put unimplemented-device placeholders for specific     devices we don't yet model (by checking e.g. the     hardware documentation for the SoC and board model,     the device tree, etc) (b) we do the most wide-ranging testing of guest code that     we can. This checks that we didn't miss anything in (a).I don't mind which of these we do. What I was asking in mycomments on version one of your patch was for how we weredoing on requirement 2b.