On 13/04/2023 12:05, yanhong wang wrote:
On 2023/4/13 17:03, Torsten Duwe wrote:
On Thu, 13 Apr 2023 10:05:28 +0800
yanhong wang <yanhong.w...@starfivetech.com> wrote:
the definition of DT refers to Linux and is consistent with the definition
framework of Linux.
This is one of the desired goals, to avoid confusion, usually. But note there
are already the
-u-boot.dtsi files; in this case it would be vice-versa: U-Boot could be
simple, the kernel
required a different treatment. As long as the resulting tree matches the
hardware!
The difference between 1.2A and 1.3B is the PHY type and phy clock delay
configuration,
which are reflected in DT, and the difference in defconfig is the configuration
of the DT file.
Is defconfig defined separately or merged?
You are the implementer, this is your decision. You make a proposal, and it
will get accepted
or not. We only make suggestions, with the intention to improve the code.
Thanks. A defconfig matches a piece of hardware, which is more
developer-friendly and less confusing,
so defconfig is better defined separately.
My opinion isIn my opinion user-friendlyness is more important then developer
friendly that from an end-user point of view it's much easier to have one binary
that works on all different board versions. If not users will have to know which
board version they have to flash the correct U-Boot.
For the RaspberryPi we even went further and put effort into U-Boot development
to have one U-Boot binary which can boot RPi3 and RPi4 boards.
In that sense I would advise you to revisit your decision to put a
developer-friendly approach over an end-user-friendly one.
As Torsten said, it shouldn't be too difficult to update the device-tree at boot
time to fit the actual board you are running U-Boot on.
Just my thoughts about the issue :)
Best regards,
Matthias
The EEPROM is being prepared and will be submitted as soon as possible. Is it
necessary to
incorporate EEPROM into this submission?
When eeprom is supported, the MAC address will be read from eeprom. The board
reversion
can be read from eeprom, but phy clock delay configuration cannot be read from
eeprom, only in DT.
But the board revision number in EEPROM can be used to differentiate between
1.2 and 1.3, right?
Yes, board reversion read from eeprom can distinguish between 1.2A and 1.3B.
1.2A and 1.3B are two sets of hardware, and the differences between the
hardware are defined
by DT, which is more concise and clear.
When I look at the code and my test results, this is my proposal to pull this
in, in order to
simplify things and avoid duplication. Whether you do so is up to you, see
above. Let me recap:
* the device tree *must* match the hardware at hand.
* the differences are minor and could be patched, Copy&Waste is error prone and
causes extra work.
It is my firm conviction that this patch set does not introduce hardware
variants, and it would be
the task of the ethernet driver patch set to split the code (DT+defconfig) OR
to provide a patching
method. Maybe I find a few cycles to look at the EEPROM.
Torsten
