On Wed, 29 Mar 2023 18:16:20 +0800 yanhong wang yanhong.wang@starfivetech.com wrote:
On 2023/3/29 17:41, Torsten Duwe wrote:
On Wed, 29 Mar 2023 11:42:07 +0800 Yanhong Wang yanhong.wang@starfivetech.com wrote:
v5:
[...]
- Splitted starfive_visionfive2_defconfig into starfive_visionfive2_12a_defconfig and starfive_visionfive2_13b_defconfig.
Is this really necessary? It puts another burden on people building U-Boot, distribution networks, and last but not least users, who will need to pick the correct binary blob, after trying to find out which board they actually have.
Even past versions can detect the installed RAM correctly and will modify the DT accordingly, I assume? Why not make an inquiry on GMAC1_MDIO to tell whether it's a YT8512C (->v1.2A) or another YT8531C (->v1.3B), in the ethernet patch set, and likewise update the device tree dynamically then?
At a second look, this is a bit tricky: a device tree is already needed for the network initialisation. That one would need to be good enough to get at the PHYs, and flexible enough to be patched into shape later. But see below...
There is only one defconfig in V4, and dts is separate for versions 1.2a and 1.3b. Andreas Schwab suggested that defconfig is also defined separately, so the definition of defconfig in V5 is also separated.
The discussion process as follows:
https://patchwork.ozlabs.org/project/uboot/patch/20230316025332.3297-18-yanh...
Do you have any better suggestion on whether defconfig is defined separately?
Andreas' concern is the match between the device tree and the actual hardware, as far as it matters for (driver) software. So, different hardware => different DT.
However, AFAICT there is no difference until network comes into play, right? And even then, it is only the types of PHYs and their wiring, correct?
From the other thread: can we enable the EEPROM reading code first, to get the proper MAC addresses for the hardware, and also read the board revision, similar to get_pcb_revision_from_eeprom() from the HiFive unmatched? And then use fixup functions from common/fdt_support.c to adapt the device tree details to the detected board?
Torsten