[PATCH 4/4] configs: starfive: default to jh7110-starfive-visionfive-2-v1.3b
E Shattow
e at freeshell.de
Sun Feb 9 22:55:11 CET 2025
Hi Heinrich, I re-send my reply w/ CC's as you ask off-list :)
On 2/9/25 12:52, Heinrich Schuchardt wrote:
> E Shattow <e at freeshell.de> schrieb am So., 9. Feb. 2025, 21:43:
>
>>
>> On 2/9/25 07:23, Heinrich Schuchardt wrote:
>>> We use starfive_visionfive2_defconfig to generate a FIT image supporting
>>> all JH7110 boards in U-Boot. Make jh7110-starfive-visionfive-2-v1.3b the
>>> default configuration that is used if no other configuration fits.
>>>
>>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
>>> ---
>>> configs/starfive_visionfive2_defconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/configs/starfive_visionfive2_defconfig
>> b/configs/starfive_visionfive2_defconfig
>>> index c3f2142ae1b..ed077886436 100644
>>> --- a/configs/starfive_visionfive2_defconfig
>>> +++ b/configs/starfive_visionfive2_defconfig
>>> @@ -78,7 +78,7 @@ CONFIG_CMD_WDT=y
>>> CONFIG_CMD_TFTPPUT=y
>>> CONFIG_CMD_BOOTSTAGE=y
>>> CONFIG_OF_BOARD=y
>>> -CONFIG_OF_LIST="starfive/jh7110-milkv-mars
>> starfive/jh7110-pine64-star64 starfive/jh7110-starfive-visionfive-2-v1.2a
>> starfive/jh7110-starfive-visionfive-2-v1.3b"
>>> +CONFIG_OF_LIST="starfive/jh7110-starfive-visionfive-2-v1.3b
>> starfive/jh7110-milkv-mars starfive/jh7110-pine64-star64
>> starfive/jh7110-starfive-visionfive-2-v1.2a"
>>> CONFIG_MULTI_DTB_FIT=y
>>> CONFIG_ENV_OVERWRITE=y
>>> CONFIG_ENV_IS_IN_SPI_FLASH=y
>>
>> Please keep CONFIG_OF_LIST sorted. Fall-through case should instead be a
>> failure to boot, or at least a warning to the user that something
>> unexpected is happening and inform that an assumption of a generic set
>> of parameters or arbitrary board Fdt is being substituted. Implicit
>> fall-through selection that un-orders the list is NAK. -E
>>
>
>
> Binman always creates a default and it is always the first configuration.
>
> With current U-Boot you can not boot a Mars CM board which used to work in
> v2025.01.
>
> What is good about a failure to boot?
>
> Best regards
>
> Heinrich
>
Two topics here of my concern are:
1. Silent and arbitrary selection of Fdt in fall-through case
Mars CM (and CM Lite) are known to have a production batch containing
wrong EEPROM information from the factory. Booting some configurations
of Mars CM Lite with the VisionFive 1.3b Fdt may lead to data corruption
(and possibility of destroying hardware). Failure to boot would inform
that situation, or at least boot with the very minimums to avoid such
assumptions while yet able to select the intended Fdt search path. That
is the practical reason why a fall-through to silently using VisionFive2
1.3b is arbitrary and not the ideal situation. In the fall-through case
I would want to see a U-Boot specific target that has the very minimums
to get to a serial console and inform the user what is wrong, with
access only to things that are totally consistent over all known board
configurations (excluding MMC and non-default CPU core clock speeds for
example). Failure to boot may allow the user access to fix the failure
(with EEPROM tools) or at least understand what has happened instead of
silently proceeding with the wrong configuration.
2. Preserving ordered lists for easy to commit and follow git history
As for the ordering, is there not some way to explicitly write the
fall-through case for OF_UPSTREAM as another config variable? I
appreciate the historical context and it's naming and so on is the
VisionFive2 1.3b but what we're really looking at is a generic board
target for things that are JH7110 CPU users, which for the moment mostly
derive from the VisionFive2 reference board(s). It happens to be named
starfive visionfive2 and otherwise I already read that as "starfive
jh7110 generic board target" in U-Boot.
Anyhow thanks for taking this on, I am glad that we can simplify this
even further in U-Boot. I interact with people that are beyond-confused
why their Mars CM Lite or Star64 is able to "almost boot Linux" but with
weird timeout warnings and so on... it is usually that the "default" or
visionfive2 1.3b U-Boot Fdt was selected from a fall-through condition.
That really needs to be better handled in U-Boot with an actual failure
and opportunity for the user to fix it.
-E
More information about the U-Boot
mailing list