Talk:StarFive VisionFive 2
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~
:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 06:02, 21 January 2025 (UTC) :: Your reply ~~~~
Imagination GPU drivers exist
The GPU drivers from here appear to have made their way into the kernel. Should be able to be enabled with CONFIG_DRM_POWERVR.
It also exists in Mesa as per the cover letter.
xxc3nsoredxx (talk) 02:18, 31 August 2024 (UTC)
- Indeed we have a double challenge here: 1. The GPU IP Block which is supported by CONFIG_DRM_POWERVR according to your information and 2. the display IP Block which is a VeriSilicon DC 8200 (ref. https://doc-en.rvspace.org/VisionFive2/Developer_Guide/SDK_DG_HDMI.pdf on page 7). The code for the VeriSilicon DC 8200 seems to exists in the StarFive git repository it remains to be be integrated at the upstream level (or forked/adapted for recent kernels in the meantime.)
- Thank you for pointing this out.
- --Admnd (talk) 22:21, 25 December 2024 (UTC)
Removal of catalyst section
I am not really happy to see that a whole section of the text has been removed prior any discussion or suggestion. My original idea was to provide a linear reading (plus referencing other pages). The removal of what will be (probably) the most used way of generating stages from what exists under /usr/riscv64-unknown-linux-gnu literally kills the explanation, plus the referenced wiki page is not correct => I am not talking about Catalyst/MUSL here but how to setup Catalyst + **GLIBC** in **that** precise use case case. There is a reason I reused the the "old" text rather than removing it at all. So this section has be be present in a way or another. Thanks to not remove anything prior the completion of the work. I appreciate the collaborative work, but in that case this does not help the reader :)
--Admnd (talk) 14:55, 7 December 2024 (UTC)
- Unfortunately this whole document is a mess currently. The information inside is great, however there was clear goal to explain this to the user.
- Currently the Catalyst info is siting in a sub article as it is useful but in it's current form it is just creating the same stage3 that you download from the Gentoo mirror, and as a result falls under the "wasting users time" category.
- So, lets simplify the main document to allow new users to get involved and finally use sub articles for the fun stuff.
- All discussion of this happened in #gentoo-wiki (webchat) by the way.
- Immolo (talk) 16:29, 8 December 2024 (UTC)
- I am trying to fix the original document which had that exact problem: messy, full of information but some steps were not at their logical place. The whole thing is a work in progress, so yes, it has the same "defect" the original had for the moment. I hope to make the result more "linear" (one of my goals at least).
- I understand your approach and I think there is something to do. Perhaps the happy path would be to go directly with a pre-built stage 3, so the text could be shortened a little bit more in order keep things "straight and simple" and allow the user to quickly move on the fun part: get a fully functional system in a few steps.
- I will perhaps put some more advanced information at the end. On the other end, you have to take into account the fact that not all users are familiar with Catalyst (they will not read the wiki page nor fiddle with the configuration) so giving them a kind of very short Catalyst recipe (+ pointing to the Catalyst wiki page for more details) could be a great addition to them. Will see at a later time.
- --Admnd (talk) 17:48, 8 December 2024 (UTC)
- I think we are on same wave length. The main article should just be able getting the user up and running without wasting there time, which is currently what is happening. We can use something like Catalyst#Detailed_usage_examples to describe how to do more advanced setups for certain needs rather than just a massive blob on one page which losses the reader fast.
Functional!
I do have a functional explanation this evening but some stuff is unclear. I am definitely surprised to see a kernel panic when using the wrong DTB/DTS (I would have understood if only some devices would be missing). Isn't the RAM mapping should be the same? Is it due to a relocatable kernel? I am quite new in that kind of stuff.