<deathmist>
hey, attempting to use U-Boot v2023.10-rc3 on my VisionFive 2 to boot a distro with mainline kernel (6.5.0-next-20230828), but it appears starfive_visionfive2_defconfig forces the device tree to be jh7110-starfive-visionfive-2.dtb while in my case it needs to be jh7110-starfive-visionfive-2-v1.3b.dtb
<deathmist>
is there any solution for it to automatically pick it based on the board? there's 2 variants (v1.2a and v1.3b) and I don't feel like it's the job of distributions to deal with something like this
<mps>
some scripting to set proper dtb? I also thought about same problem you have, I have VF2 board
<mps>
I didn't looked yet how to add such script
<Tartarus>
Yes, it should do some of the various things arm boards do to pick the right one
<mps>
bdinfo doesn't show anything which I think could be used
prabhakarlad has joined #u-boot
<mps>
Tartarus: could you point to example
<Tartarus>
git grep findfdt
<Tartarus>
This assumes there is some reliable way to determine the revision of the hardware
goliath has quit [Quit: SIGSEGV]
<deathmist>
fwiw my UART shows "Model: StarFive VisionFive 2 v1.3B" while booting, not sure if it's hardcoded somehwre to that variant tho
<mps>
aha, thanks
<deathmist>
and to clarify that log is from U-Boot
<xypron>
deathmist: The version should be determined from the EPROM.
<mps>
I think some u-boot command have to be used to read some board info
<mps>
eeprom show show this 'PCB revision: 0xb2'
<mps>
and 'data version: 0x2'
<xypron>
deathmist: The right place to set the chosen device-tree is in SPL. The itb file with main U-Boot should have different configurations from which SPL should choose based on the EPROM.
<Tartarus>
Yes, there's examples that read eeprom
<Tartarus>
The TI platforms have a whole set of frameworks for handling those on their ref platforms
<xypron>
Wandboard too?
<mps>
what command is used to read eeprom from u-boot
<mps>
'eeprom read' loads eeprom
<Tartarus>
Do you mean parse?
<mps>
eeprom read <bus> <devaddr> addr off cnt
<mps>
yes, something to parse would be useful
<Tartarus>
That's up to the board stuff to implement
<Tartarus>
There's no real standard for them
<mps>
I see, just looking at board/ti/common/cape_detect.c
<deathmist>
in any case if you need anything from me or there's something to test I'd be very interested! I'll idle around here so feel free to ping me ^^
<mps>
nice, board/starfive/visionfive2/visionfive2-i2c-eeprom.c and there is 'struct eeprom_header header'
<Tartarus>
There's examples of reading the eeprom and setting an env var, from board_late_init or what-have-you, too
<mps>
simplest would be to set CONFIG_DEFAULT_DEVICE_TREE to desired board/dtb
<mps>
err, CONFIG_DEFAULT_FDT_FILE
<deathmist>
mps: that's the hack I'll be doing tomorrow, but let's say a distribution wants to support the board and people happen to have the v1.2a while it defaults to v1.3b, then what? they don't have a second working ethernet port at least until manually messing with stuff
<deathmist>
I know 1.2 is a super early model with slightly different hw but it does exist in people's hands
<mps>
well, then we are out of luck if vendor didn't do right things for this
ezulian has quit [Ping timeout: 246 seconds]
<mps>
then distro have to try to make combined dtb
<deathmist>
what would be the right things for vendor to do?
<mps>
to set proper fdtfile name in 'firmware' they install on board
<deathmist>
mps: on the SPI flash or?
<mps>
in some of first tries I simply renamed dtb to one u-boot expect
prabhakarlad has quit [Quit: Client closed]
<mps>
it could be set in u-boot source or on flash
<mps>
this is on the vendor
<mps>
and I think debian created unified dtb file name
<mps>
but didn't looked how they did
<mps>
deathmist: don't take my words seriously, I'm just contemplating aloud
<deathmist>
isn't that all downstream stuff tho? I'm trying to run zero downstream things; I've got mainline OpenSBI, U-Boot and Linux kernel where things may differ from what vendor did; I've just flashed it all on SD card similar to as described on https://u-boot.readthedocs.io/en/latest/board/starfive/visionfive2.html and haven't touched SPI
<mps>
this could be task for u-boot contributors
<mps>
as you know you can put u-boot on e/mmc
<mps>
so, distro can hack u-boot which they ship to solve this problem
<mps>
for example, I already hacked some things for my personal testing
<mps>
in include/configs/starfive-visionfive2.h I added nvme in boot targets