Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overwriting dtbs on storage devices #49

Open
vali-um opened this issue May 2, 2023 · 1 comment
Open

Overwriting dtbs on storage devices #49

vali-um opened this issue May 2, 2023 · 1 comment

Comments

@vali-um
Copy link

vali-um commented May 2, 2023

Hello,

As discussed in the forum the current u-boot setup in many cases overwrites the dtb on mmc. This seems to be done to support the different memory sizes and ethernet variations.
While it might be beneficial to do this for the in-memory dtb upon boot overwriting it on the storage medium itself is really bad. This file might be supplied by the user or distro and editing it will lead to confusion and issues.

The relevant code parts are https://github.com/starfive-tech/u-boot/blob/JH7110_VisionFive2_devel/include/configs/starfive-visionfive2.h#L151 and https://github.com/starfive-tech/u-boot/blob/JH7110_VisionFive2_devel/include/configs/starfive-visionfive2.h#L155

I'd suggest removing the write commands.
While looking at this i noticed the two branches do the same thing so the if statement could be removed to simplify the command.

Thanks,
Valentin

@MichaIng
Copy link
Contributor

MichaIng commented May 2, 2023

I totally agree with you, thanks for bringing this up here.

The only issue is that for 8 GiB and VisionFive 2 A1.2 Ethernet support, another solution would then need to be applied. If there is no way around adjusting the device tree nodes, then the best I could come up with are device tree overlays. With #44 they can be generally added via extlinux.conf.

  • For 8 GiB support this is no big issue, I think, as having the SBC limited to 4 GiB does not cause issues.
  • The Ethernet part however is nasty if one wants to access it via SSH right from the start. Of course another first boot service/script could read the serial number, derive revision and RAM size form it, and then apply the overlays automatically. However, no so great for distros to rely on such manual hacks.
  • Another way is a boot.scr instead of extlinux.conf, which gives more flexibility on applying device trees or overlays based on model. But it feels like a step backwards.

See also short discussion here: http://forum.rvspace.org/t/loading-device-tree-overlays-on-vf2/2585/7?u=michaing

While looking at this i noticed the two branches do the same thing so the if statement could be removed to simplify the command.

I was recognising the same 👍.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants