<thefossguy>
I need help. Have been going crazy for the last few hours because of this.
<thefossguy>
I have 2 VF2 boards, one is 4gb and one is 8gb, both are 1.3b
<thefossguy>
No clear identification on the board about which is 4gb and which is 8gb so I relied on the firmware output
<thefossguy>
Now, the board whose firmware reports that it is 8gb boots linux with `free -h` reporting 3.72 GiB, applying [this DTSI fix](https://github.com/starfive-tech/VisionFive2/issues/20) doesn't change the value on this board
<thefossguy>
Now, the board whose firmware reports that it is 4gb boots linux with free -h reporting 3.8GiB. Then, applying the above DTSI fix, I get 8-ish GiB in free -h
zsun has joined #fedora-riscv
<thefossguy>
edit: ~8-ish~~
<thefossguy>
edit: ~~8-ish~~ 7.7
<thefossguy>
Well, this is a mess. I'll do a few more things
<davidlt[m]>
That should be patched in uboot at least after reading eeprom.
<davidlt[m]>
I don't recall what was the plan for the linux side.
<thefossguy>
Well, its a mess because I confirmed that uboot's readings align with the chip number on board
<davidlt[m]>
If you use DTB provided by the firmware (that is Uboot) it should be fine. We'll not today.
<thefossguy>
I verified for both boards that the serial number for DDR chips are as per here and uboot reports correctly
<thefossguy>
davidlt[m]: vendor firmware (v2.11.5 or something) and vendor kernel (5.15.0; not the 6.3-rc4 that they are currently working on)
<davidlt[m]>
Another thing is how you get DTB for the Linux.
<davidlt[m]>
Ah, they had tons of stuff in their uboot environment.
<thefossguy>
I tested both vendor kernels, 5.15.0 and 6.3-rc4, the generic dtb works on former and board specific dtb is needed in the newer one
<thefossguy>
Yep, that could be an issue too
<davidlt[m]>
The upstream stuff will work differently.
<thefossguy>
To it boots, just not how I wish :D
<davidlt[m]>
We discussed that with Conor some weeks ago how this should work, but its too early to remember.
<davidlt[m]>
The problem is that with extlinux you most likely loading DTB outside Uboot. UBOOT will not patch it.
<davidlt[m]>
Linux should fix DTB in that case.
<davidlt[m]>
To fix memory node.
<thefossguy>
In the middle of trying something. Will reply soon
zsun has quit [Quit: Leaving.]
<thefossguy>
Update:
<thefossguy>
I confirmed that the firmware is reading the correct data from EEPROM, so the value provided by uboot is indeed correct. But the vendor kernel (that I compiled) has the issue of RAM size being capped at 3.78 GiB on both boards. Applying [this fix](https://github.com/starfive-tech/VisionFive2/issues/20) raises the RAM size for both boards lmao.
<davidlt[m]>
That's because DTS provided to the kernel at boot time is not patched.
<thefossguy>
I'm coming to that conclusion but I have too many things changed in my image too XD
<davidlt[m]>
So the official reply was:
<davidlt[m]>
> linux startup, we will change this property in dtb through u-boot to
<davidlt[m]>
> The VisionFive 2 board only has 4GB version and 8GB version now. Before
<davidlt[m]>
> make sure the board can boot up with the correct memory size.
<thefossguy>
Ah, I think I now have to build the mainline uboot now
<thefossguy>
That's the only way to test if "upstream" works
<thefossguy>
+ compile linux too
<thefossguy>
Guess I'll wait until Monday so I can have 6.4-rc1
<davidlt[m]>
There is one thing you can do.
<davidlt[m]>
Do you use extlinux for boot?
<thefossguy>
Yeah
<davidlt[m]>
You can use `fdtoverlays` and tell users to pick the "right one".
<davidlt[m]>
This should work if your U-Boot is compiled with CONFIG_OF_LIBFDT_OVERLAY
<davidlt[m]>
Basically you can cook small DT fragments and apply them on top of the main DT.
<davidlt[m]>
For example, if there are some HATs or something.
<davidlt[m]>
I think it was part of VF2_DISTRO_BOOTENV
<davidlt[m]>
I think what they were doing was to load fdt, modify memory and write it out to /boot.
<cwt[m]>
thefossguy: One dtb but the uboot will patch it at the boot time to match board A or B
<davidlt[m]>
Right now if you use EXTLINUX the only way DTB changes is if you use overlays.
<davidlt[m]>
The problem is that U-Boot can only fixup built-in DTB, not the one loaded by EXTLINUX (which usually loads the one from the kernel tree).
<davidlt[m]>
If you boot with "firmware DTB" (I.e. U-Boot) it will be patched.
<cwt[m]>
davidlt[m]: That is why uboot write the patched file back to filesystem
<davidlt[m]>
Typically that DTB is outdated and kernel one contains a lot more HW enabled.
<davidlt[m]>
Yeah, but that will not be the case in upstream U-Boot :)
<davidlt[m]>
I would be surprised to see that land :)
<cwt[m]>
Right upstream uboot needed upstream kernel
<davidlt[m]>
I pinged Conor to see what plan is there for this.
<thefossguy>
Thanks :)
<davidlt[m]>
But in general users right now (with everything upstream) would need to modify their DTB or write an overlay.
<thefossguy>
Same with grub?
<davidlt[m]>
What vendor U-Boot does is hacky. It modifies DTB shipped by the kernel in /boot/dtbs*, which is not OK.
<davidlt[m]>
I don't think GRUB patches DTB, but not sure.
<thefossguy>
Do the riscv images for fedora use grub or extlinux?
<davidlt[m]>
EXTLINUX, but we should go to GRUB EFI ASAP.
<thefossguy>
On that note, I've never figured out why the password on the fedora image keeps resetting :(
<davidlt[m]>
I am mostly waiting for a new GRUB release for this.
<thefossguy>
What about trying systemd-boot?
<davidlt[m]>
I think, it should work, but untested.
<thefossguy>
thefossguy: Yes I know that fedora rocks! but let me also asdf so that its quicker to login 😭
<thefossguy>
davidlt[m]: One more thing to do on Monday
<thefossguy>
Does anyone even use EFI on RISC-V yet? I thought that was supported but still a bit WIP
<thefossguy>
I assume the Unmatched uses efi boot?
<davidlt[m]>
It works since FPGA / FU540 days via TianoCore EDKII.
<davidlt[m]>
But not in a production level.
<thefossguy>
So not via uboot yet
<davidlt[m]>
Initial code was produced by HPE. I think they are still working on it.
<davidlt[m]>
U-Boot also works, and it was showed years ago.
<davidlt[m]>
If you don't use GRUB2 :)
<thefossguy>
EDKII support was merged upstream, but only for QEMU if I recall correctly
<davidlt[m]>
You can directly boot U-Boot [EFI] -> kernel, but that's not how it's done in distros.
<thefossguy>
davidlt[m]: So eifstub?
<davidlt[m]>
You would need to test what works today. I have been waiting for GRUB2 for way too long thus don't know what works properly anymore.
<thefossguy>
Well, the whole reason of using grub (at least for me) is that I don't have to manually modify a config file that I only read half a year ago to test this new kernel
<davidlt[m]>
There is more reasons for us at least.
<davidlt[m]>
We get the same bootflow. Also BLS (BootLoader Spec) is also implemented in GRUB2.
<thefossguy>
So what would your ideal boot flow for Fedora look like, if everything were to have upstream support?
<thefossguy>
The change in uboot, where it is 0X2 is exactly what made me go crazy a few hours ago
<davidlt[m]>
It''s better to have default set with lowest possible memory capacity, just in case.
<davidlt[m]>
And anyways, this DT still needs to be patched before passing to the kernel so technically not a big issue.
<thefossguy>
But it doesn't work... Using 0x2 just reports a false 8gb size even on 4gb board
<davidlt[m]>
But it's definitely a better idea to boot with 4GB memory enabled on 8GB system instead 8GB enabled on 4GB system ;)
<davidlt[m]>
I never tried, but attempt to do a large memory allocation and see what happens :)
<davidlt[m]>
Try to fill those fake 8GB of RAM on a 4GB RAM baord.
<thefossguy>
davidlt[m]: Its the other way around XD
<thefossguy>
davidlt[m]: I'll write a simple c program to malloc then
<thefossguy>
Didn't think of doing it in the first place because well, swap
<davidlt[m]>
I just pinged StarFive folks to also sync up DTs from kernel -> u-boot once RC1 (or later) is out, but before U-Boot is released.
<davidlt[m]>
This will be a typical story for the next ~1 year or so.
<davidlt[m]>
Also if there is predefined layout for SPI-NOR Flash (e.g. incl. u-boot environment partition). Someone should check if you can read it from the user-space. Those must be aligned to NOR Flash erase block size IIRC.
<davidlt[m]>
Otherwise you cannot read/write U-Boot environment (which is also a place where UEFI variables are stored IIRC).
zsun has joined #fedora-riscv
<thefossguy>
<davidlt[m]> "Also if there is predefined..." <- Do you mean the output of `cat /proc/mtd`?
<davidlt[m]>
Now, fw_printenv and fw_setenv.
<davidlt[m]>
s/Now/No/
<thefossguy>
You mean reading uboot vars in linux? Yeah, haven't looked into that yet
aurel32 has quit [Quit: leaving]
aurel32 has joined #fedora-riscv
<thefossguy>
Well I just `dd`-ed `/` XD
<thefossguy>
Good thing its on the VF2, which I can re-image
dgilmore has quit [*.net *.split]
drewfustini has quit [*.net *.split]
jbowen has quit [*.net *.split]
pjw has quit [*.net *.split]
pbrobinson has quit [*.net *.split]
pbrobinson has joined #fedora-riscv
pjw has joined #fedora-riscv
dgilmore has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
drewfustini has joined #fedora-riscv
jbowen has joined #fedora-riscv
dgilmore has joined #fedora-riscv
dgilmore has quit [Changing host]
jbowen has joined #fedora-riscv
jbowen has quit [Changing host]
<thefossguy>
Good thing: upstream u-boot and opensbi work
<thefossguy>
Bad thing: reading from EEPROM doesn't work at the moment
<davidlt[m]>
Yeah, it didn't land yet.
<davidlt[m]>
Things should get better at ~v6.5 time :)
<thefossguy>
I was going to look at the commits made in the uboot tree for it because rvspace.org doesn't have a section for EEPROM :/