Hi,
As a proud of putting my SBCs headless, I’m still kinda interested how now they boot graphically. (By now I mean NOW, and not these expired YT unboxing-booting vids).
My old 720p TV set which has hdmi but never draw to screen anything from VF2. I suspect there is bootup logo already from U-Boot and maybe you now can control bootloader from screen? Dunno.
I’m guessing from this you want to know what you would see with a supported monitor.
With the 202303 release the console hdmi support is partly working, but not great.
The current display mode used by u-boot is fixed at 1080p, there is a splash screen (white with a logo) that appears once u-boot is started. But no console display of u-boot progress, or ability to select which kernel or device to boot from. Just the white logo.
Once the kernel loads you then see the kernel boot log complete with color highlights just as you would expect on other Debian systems. Eventually GDM starts and you can login.
Gnome is running really fluidly and is very responsive, the compositor support is good. Simple apps and games start quickly and work as expected. But running big apps can still bog the system down, ffox is sluggish, and Stellarium ran at 0.08 FPS! (though at least it did run…)
2 Likes
I suspect that we will get proper u-boot console support asap, since u-boot upstream has support for framebuffer displays.
It’s probably just a case of knocking the u-boot framebuffer driver into good enough shape to support it. And adding USB-HID support if you want users to interact with it… and I2C touchscreen support for tablets etc.
3 Likes
Good, thank you. Well, I’ll just wait then for things to settle down, all the fun is just ahead!
1 Like
I wonder what build options they (SF) used when they built their closed source graphics stuff. Well, I’ll just sit down and gaze into disassembly.
1 Like
The only closed bit is the GPU firmware, the DC8200 based video driver itself is open source. See u-boot/drivers/video/starfive at JH7110_VisionFive2_devel · starfive-tech/u-boot · GitHub
Edit: also this: Introduction
No no, I meant img-gpu-1.17 userspace GLES part for which there is no source code yet.
Ok, I realise that. But the GPU does not need to be used during boot! All we need is a traditional framebuffer for displaying the u-boot progress and console, and that is what the DC2800 code provides.
You only need to access the closed source GPU bits once you start a compositor based GUI, want to encode/decode streams, or run a kiosk display app etc. u-boot does not need these things.
So it really depends on what you want to achieve, if all you want to do is make u-boot have a proper console where you can edit the config, select different kernels, etc. you do not need to mess with the closed source nightmares.
3 Likes
Yeah, I got it, sorry for being inspecific, I stuck to But running big apps can still bog the system down, ffox is sluggish, and Stellarium ran at 0.08 FPS! statement and continued talk from there, silly me 
So, now I have to get 1080p monitor.
1 Like
Just a note: I quickly looked at their userspace binaries and nowhere I found insns like sh1add or ror, and while latter is not required to appear in ordinary code (it usually good for cryptography), the former is additional bonus. Also, their .comment sections suggest they just used quite dated GCC and probably default CFLAGS were applied.
Some digging reveals things like:
$ strings -a staging/usr/lib/libfftb.a | fgrep march=
GNU C99 10.3.0 -march=rv64imafd -mabi=lp64d -g -O2 -std=gnu99 -fstack-protector-strong -flto -fno-strict-aliasing -fPIC
'-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-g' '-march=rv64imafd' '-mabi=lp64d' '-O2' '-Wno-error=implicit-fallthrough' '-fstack-protector-strong' '-flto' '-fno-strict-aliasing' '-fdiagnostics-show-option' '-fPIC'
Looking at disassembly of any library there, I suspect these were applied, because literally no any library uses C extension compressed instructions - all instructions are of static 32bit length, as per -march=rv64imafd.
Pretty generic, if you’ll ask me.
Summary: with source code drop, hoping GPU will perform better when being built with recent GCC with suitable platform C{,XX}FLAGS or clang.
2 Likes
@strlcat I already did a video on the 202303 image. 202303 Debian Update VisionFive2 RISC-V SBC - YouTube
You can try to compile GL4ES and see if that improves the performance.
Here is a video running a game with Box64 and GL4ES.
2 Likes
Hi,
I already seen this vid!
But I dont get how a translation library will solve underlying unoptimized code problem. Does GL4ES talk directly to hardware?
3 Likes