Hi Felix,
Is this commit meant to fix an error you are seeing, or are you trying to eliminate a warning. This devicetree has been in use for a long time and with many versions of PetaLinux.

The Ultra96-V2 schematics have a 1.8V (VCC_PSAUX) to 3.3V translator between the MPSOC and the SD card cage. This 'no-1-8-v' is meant to tell the SD controller that 1.8V is not supported in the hardware when, actually, that is exactly how it is connected.
https://elixir.bootlin.com/linux/v4.4/source/Documentation/devicetree/bindings/mmc/mmc.txt
"no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is."

If you look at the schmatic of the V1 board [1], it has the same level shifter setup. Yet, when you look in the device tree, you will see the no-1-8-v setting. [2]

Also have a look at this Xilinx Answer Record about SD booting [3].

The Reference Manual for the SoC [4] (Page 745) states that for 50 MHz operation (which is what I think we are doing), only 3.3 V is supported. Obviously, the SoC is not actually putting out 3.3V, it just puts it in that 3.3 mode, so it will even work. This is what is meant with "denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is", because 1.8V card voltage is not supported at 50 MHz.

[1] https://www.96boards.org/documentation/consumer/ultra96/ultra96-v1/hardware-docs/files/ultra96-schematics.pdf
[2] https://github.com/Xilinx/device-tree-xlnx/blob/master/device_tree/data/kernel_dtsi/2019.2/BOARD/avnet-ultra96-rev1.dtsi
[3] https://www.xilinx.com/support/answers/69006.html
[4] https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf

Hi Tom,

what's your stance on this, on a more general scale I mean: Do you think that the ultra96 V2 should have it's own device tree without depending on any files from the first board?

I think that makes sense from a logical standpoint: They are different boards and they should each be configured indivudually and completely. It also makes sense when we think about the yocto users: They basically get an incomplete device tree without going through the effort of including the device tree of the first board.

Also, please have a look at how the device tree of the Ultra96V2 is set up (example [1]).
Instead of defining our own hardware according to the Ultra96V2 Board, we use "half a configuration" of the old board by removing incompatible parts from the V1 device tree (see also lines 17, 64, 68, ...). This sounds like a very backwards approach to me.

It's setup almost in kind of an inheritance pattern of the V2 inheriting from the V1 and then removing the incompatible parts. Does this make sense? If the V1 were to change (hypothetically), should this influence the V2?

Maybe you can also relay this question to someone at avnet who knows about the reason for this setup. My recommendation would be to create a proper bsp device-tree for the V2.

[1]https://github.com/Avnet/meta-avnet/blob/2020.2/recipes-bsp/device-tree/files/u96v2-sbc/system-bsp.dtsi#L90