<levd>
Hi all, I'm currently in the process of porting the mainline U-Boot to roc-rk3399-pc, but got stuck. This device has 4 GiB LPDDR4 ram, and I'm using the latest added LPDDR4 feature. The U-Boot is happily loaded, yet the kernel hangs at the beginning. Here's the log: https://0x0.st/zp6G.txt
<levd>
To contrast, I manage to boot the kernel successfully with another v2019.01 U-Boot with some vendor provided LPDDR4 patches. Here's the log: https://0x0.st/zp6d.txt
<levd>
Obviously the U-Boot play a import role here. But it's not obvious for me to spot how this happens and what makes the difference.
<EmilKarlson>
is it good enough for simple use aready?
<EmilKarlson>
like browser+mpv
<TheCycoONE>
EmilKarlson: the archlinux alsaumc for kevin doesn't seem to be working for me anymore.
<EmilKarlson>
heh
<wens>
EmilKarlson: chromium's gpu process will crash with src/panfrost/midgard/midgard_compile.c:990:emit_alu: Assertion '0' failed.
<EmilKarlson>
I guess that's no
ayaka has quit [Ping timeout: 245 seconds]
matthias_bgg has quit [Ping timeout: 244 seconds]
ayaka has joined #linux-rockchip
Putti has quit [Remote host closed the connection]
return0e has quit [Ping timeout: 248 seconds]
Putti has joined #linux-rockchip
mystictot has quit [Ping timeout: 248 seconds]
mrjay has quit [Remote host closed the connection]
return0e has joined #linux-rockchip
Greyztar has joined #linux-rockchip
yann has quit [Ping timeout: 245 seconds]
<EmilKarlson>
wens: does it work with LIBGL_ALWAYS_SOFTWARE=1 ?
<wens>
EmilKarlson: it does, but I doubt anyone would want that. it's really slow
<EmilKarlson>
wens: because you can then use the Xorg with glamor possbily
<EmilKarlson>
I would assume it should be no slower than it's without panfrost
<wens>
I meant chromium would be utterly slow, worse than just turning off gpu compositing
<EmilKarlson>
how would it?
<EmilKarlson>
you have sw rendering even with panfrost
<wens>
EmilKarlson: chromium on Debian buster has --enable-gpu-rasterization on by default
<wens>
that with LIBGL_ALWAYS_SOFTWARE=1 means chromium is using softpipe for rasterization, which is slow compared to just software rasterization in chromium itself
putti_ has joined #linux-rockchip
<EmilKarlson>
are you 100% sure that logic escapes me
<EmilKarlson>
sure you could implement software like that, but seems a bit silly
Putti has quit [Ping timeout: 272 seconds]
<wens>
EmilKarlson: well if you tell chromium to use GL to do rasterization, it will happily do it
<wens>
EmilKarlson: I'm simply telling you what chrome://gpu is telling me, and what the experience is like
<wens>
if you don't believe me you could play around with the flags
<EmilKarlson>
does this work without panfrost?
<EmilKarlson>
in general on normal terms LIBGL_ALWAYS_SOFTWARE=1 is telling things to mesa, not the main part of the program
<wens>
LIBGL_ALWAYS_SOFTWARE=1 tells mesa to use softpipe or llvmpipe, right?
<EmilKarlson>
yes
<wens>
and that's what mesa would be using if there were no panfrost
<EmilKarlson>
yes
<wens>
are you asking what chromium would do if there were no panfrost or glamor?
<wens>
I can just turn off glamor and take a look
<EmilKarlson>
that's not the point
<EmilKarlson>
I wanted to leave panfrost for glamor and use LIBGL_ALWAYS_SOFTWARE=1 for all other software
<EmilKarlson>
if the glamor parts work without crashes, you can get benefits of glamor even before the other parts are fixed
<wens>
that would work for sure
<wens>
I'm just saying LIBGL_ALWAYS_SOFTWARE=1 + gpu (GL) rasterization in Chromium sucks, better off just disabling gpu rasterization
<EmilKarlson>
sure
<EmilKarlson>
but I assume LIBGL_ALWAYS_SOFTWARE=1 does not enable anything in chromium
<EmilKarlson>
which was the original point of confusion here
putti_ is now known as Putti
aalm has quit [Quit: xyz 2.3]
<wens>
I'm just happy glamor works now
<EmilKarlson>
agreed
<EmilKarlson>
wens: can you tell me if you notice any crashes?
<EmilKarlson>
also does mpv work faster with just glamor without enabling any fancy backends?
<wens>
EmilKarlson: I'm not using it for anything really
<wens>
I bought the unit for fun to see if I could get mainline working on it
<EmilKarlson>
ok
<wens>
I suppose it would be worth checking if WebGL crashes
<EmilKarlson>
maybe I should bother, though it's tempting to just wait until debian gets it packaged
<EmilKarlson>
in general I prefer crashing webgl
<EmilKarlson>
makes sure I don't accidentally enable it
<EmilKarlson>
though sandboxed software opengl might be ok
<wens>
EmilKarlson: you might have to wait a while for the next major mesa release, then packaging
<wens>
if you want I have precompiled tarballs
<EmilKarlson>
for debian?
<EmilKarlson>
buster?
<wens>
yeah
<EmilKarlson>
the thing is, I would not want to install it on my rootfs without making it a package
<wens>
it's in /usr/local
<wens>
though you do have to do symlinks into /usr/lib/${platform}/dri
<EmilKarlson>
I guess I need to overwrite the old mesa libraries?
<EmilKarlson>
or can I just add files without overwrites?
<eballetbo[m]>
If anyone is interested I have debian packages but for sid, and I can also provide an debian image ready to flash for kevin (5.3-rc1+panfrost+gnome+mesa)
<EmilKarlson>
eballetbo: sounds nice
<EmilKarlson>
maybe I could upgrade to bullseye at some point
<wens>
EmilKarlson: only the dri libraries need to be overwritten, or you could divert the original ones and make symlinks to /usr/loca/lib/
<eballetbo[m]>
you can flash the image to a usb or sdcard and give it a try, just need to upload somewhere, but that will be tomorrow
<wens>
EmilKarlson: which was what I did
<EmilKarlson>
wens: ok, please share
<EmilKarlson>
eballetbo: if I go that way, I'll just make a new subvolume
<EmilKarlson>
getting usb drive is probably more work than bootstrapping a new system
<wens>
EmilKarlson: you want armhf or arm64?
<EmilKarlson>
arm64
<EmilKarlson>
eballetbo: btw. do you use panfrost to any extent other than quick testing?
<eballetbo[m]>
I only did a quick testing tbh, just created the image today
<eballetbo[m]>
so I'd say the image is for test only