[GIT PULL] arm64: AMD/Xilinx SOC changes for v7.2

[Michal Simek]

út 2. 6. 2026 v 15:00 odesílatel Arnd Bergmann <arnd at arndb.de> napsal:
>
> On Tue, Jun 2, 2026, at 14:29, Michal Simek wrote:
> > po 1. 6. 2026 v 22:39 odesílatel Arnd Bergmann <arnd at arndb.de> napsal:
> >>
> >> What type of userspace would access those, and why can't
> >> this be done in a portable way?
> >
> > multiboot is useful for A/B updates when used. It is also pointing to
> > where the boot image exactly is.
>
> That sounds like it should use a reboot-mode driver. There is
> a patchset that streamlines the reboot parameter passing that
> will hopefully get merged soon, see:

not really. When you ask for a reboot you could reuse this mechanism
to boot to a different
image but in A/B which would be a very hard way to do it. We do use
ARM DEN0118 spec
with mdata for it. It means actual change in multiboot is done by low
level firmware where
different values are read based on mdata structure.

> https://lore.kernel.org/all/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@oss.qualcomm.com/
>
> If you can't fit this into PSCI reboot arguments, you can
> add a custom driver here that picks the A/B update etc

A/B in our way will be handled via capsule update/u-boot via ESP partition.

Maybe it was misleading to point to A/B. Even when you have a single image
it is useful to know which offset was used for boot. Because you can
have fallback images
if the first one is broken/corrupted.
I was more thinking that maybe useful would be to share it via nvmem
like it is done for some other options
drivers/nvmem/zynqmp_nvmem.c.

> > idcode/pcap for fpga programming case. That your bitstream matches the device
> > you use.
> > Scripts or user programs can use them.
>
> You already have an fpga driver, right? Why is that not part of
> its user interface?

The fpga driver is just loading the boot image and providing a way to
firmware to do it.
There are different types of bitstreams/formats. Bitstream in bit
format has header which you can validate,
bitstream in bin format don't have this header. Then you have also
encrypted bitstreamed, compressed one, etc.

When you have support for more silicons (different PL sizes) you
should know which bitstreams need to be loaded,
passed to be programmed.

Maybe at the end of a day instead of creating a custom driver with a
custom sysfs interface we can create a nvmem driver
which can dynamically create cells based on firmware interface.

>
> > IDcode could be the part of SMCCC_ARCH_SOC_ID but we can't change what
> > we have done in the past
> > but we plan to implement plat_get_soc_name() which will also contain
> > IDcode. That's the one where a standard interface could be used.
>
> I'm not sure what plat_get_soc_name() does, I don't see that in
> the current sources, but can have multiple soc_device drivers
> and use soc_device_match() in drivers to compare the ID
> string from the platform with a known lists for things like
> driver quirks.

Sorry that's function name from TF-A
In Linux kernel you have smccc_soc_name_init()

in our case version/revisions are defined (and to be fair to say our
firmware messes up with version/revision)
but SOC_NAME is unused today for us and that can be used for passing more
information about system/chip.

> If there is a hardware interface to find out the ID, just add
> a driver that registers another soc_device in addition to the
> SMCCC one, and soc_device_match() will attempt to match each
> one separately.

yep.

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs