On 16:27 Thu 21 Aug , Edgar E. Iglesias wrote: > On Thu, Aug 21, 2025 at 03:02:59PM +0200, Luc Michel wrote: > > v3: > > - Dropped qemu_get_cpu() usage in the machine code. Added an getter on > > the SoC interface to retrieve the boot CPU instead. [Phil] > > - Cleaned the mp_affinity logic. Drop the mask attribute and assume > > it's always 0xff (the Affx fields in MPIDR are 8 bits long). Use the > > ARM_AFFx_SHIFT constant instead of hardcoded values in .mp_affinity > > description. [Phil] > > - Avocado test renaming in patch 41 instead of 47. [Phil] > > - Documentation tweak. [Phil] > > > > v2: > > - Addressed formatting/typo issues [Francisco] > > - Patch 23: GICv3 first-cpu-idx: addressed the KVM case by bailing > > out if not 0 at realize. I chose this path as I don't have a clear > > view of what it means to implement that for KVM. It seems to make > > sense anyway as this property is meant to be used for modeling of > > non-SMP systems. [Peter] > > - Patch 39: added a comment to clarify cortex-a78ae != cortex-a78 [Peter] > > > > Hello, > > > > This series brings support for the AMD Versal Gen 2 (versal2) SoC in > > QEMU. This SoC is the next iteration of the existing Versal SoC. > > > > It is organized as follows: > > - The first and biggest part of the series performs refactoring of the > > existing versal SoC implementation. This consists in: > > - splitting existing device types into base/concrete classes, > > - moving from an in-place to dynamic device creation approach in > > the SoC code for flexibility, > > - describing the SoC using a new structure called VersalMap, > > - moving the DTB creation logic in the SoC code itself alongside > > device creation. > > Patches are split such that each device is individually converted to > > use this new approach. Behaviour changes are minimal and are > > emphasised in the commit messages. This gets the SoC code ready for > > versal2 addition and leverage the fact that Versal family SoCs are > > quite similar in term of architecture. > > > > - versal2 SoC support is then added by adding the corresponding > > VersalMap description. This allows to reuse the existing code > > without duplication and almost no special case. > > > > - The amd-versal2-virt machine is finally added, following the same > > idea as amd-versal-virt. The documentation and tests are updated > > accordingly. > > > > Note that the xlnx-versal-virt machine is renamed amd-versal-virt to > > follow current branding guidelines and stay coherent with the new > > amd-versal2-virt machine. The xlnx-versal-virt name is kept as an alias > > to amd-versal-virt for command line backward compatibility. > > > Hi Luc, > > I run with this command-line: > qemu-system-aarch64 -M xlnx-versal-virt -m 2g -serial stdio -display none > -net nic,model=cadence_gem,netdev=n0 -netdev user,id=n0 -kernel Image -device > virtio-blk-device,drive=d0 -drive > format=qcow2,if=none,file=rootfs.qcow2,id=d0 -append "root=/dev/vda1 > console=ttyAMA0" > > Before these patches, ethernet comes up fine but with this series > applied, ethernet stops working. The kernel finds device and the > driver comes up but it looks like it can't receive packets: > > eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:57 > inet6 addr: fe80::5054:ff:fe12:3457/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > --> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:4988 (4.8 KiB) > Interrupt:17 >
It seems that eth0 and eth1 have been swapped, because of the FDT node ordering. This is the issue of the non-predictable naming scheme, used by default by the kernel. I tried fixing it using aliases properties as I did for the UARTs. Unfortunately whether this works or not is driver dependent, and it does not work for the Cadence GEM driver. So my only option is to create the nodes in the same order as before, to stay backward-compatible. I'll introduce a small hack to do so in v4. Please note though that the FDT node order brings no guarantee of any kind regarding the device probing order in the kernel. Thanks Luc
