<longsleep>
aha at the end it is just a simple int overflow .. they are returning dma addresses as int while they are unsinged long really - if its loo large booom!
<ssvb>
longsleep: I will probably also add aarch64 assembly to xf86-video-fbturbo and tag a new release today or tomorrow
<longsleep>
ssvb: that would be awesome - i still have not managed to compile mali-drm - does xf86-video-fbturbo make sense without that module? I can certainly test when you have a new release.
<ssvb>
longsleep: pixman aarch64 assembly + xf86-video-fbturbo should provide decent 2D graphics performance in X11 on 64-bit ARM systems :-)
<scream>
montjoie, it helped with rtl_tcp. no more lockups there
<ssvb>
longsleep: mali is only useful for 3d games, but not for general purpose linux desktop
<scream>
iperf -d still triggers it reliably, so we have a good test case :D
<ssvb>
longsleep: if you want mali, we can also get it without too much problems
<longsleep>
ssvb: how can i benchmark this, to compare the current state and after your changes?
<scream>
locked up again, but after some 5min :)
<longsleep>
ssvb: no i do not care about mali much, but i saw some checks in fbturbo not continuing if the mali-drm module is not there.
<ssvb>
I forked glmark2 a long time ago when it was hosted in bzr on ubuntu's lunchpad and added support for the framebuffer mali backend
<longsleep>
as i have the mali kernel module just fine
<ssvb>
now glmark2 is hosted on github, so I might try to contribute something upstream :-)
Wizzup has quit [Ping timeout: 248 seconds]
<ssvb>
ok, it may be worth trying then
p1u3sch1 has quit [Ping timeout: 276 seconds]
<longsleep>
yeah, but what is the use case for framebuffer only mali?
<ssvb>
fullscreen applications, such as .... games?
jernej has joined #linux-sunxi
<longsleep>
mhm sounds something one should try who is interested in games :)
<longsleep>
Maybe non-X11 Kodi
p1u3sch1 has joined #linux-sunxi
<ssvb>
yep
<longsleep>
if Kodi would have cedrus integration that is
Wizzup has joined #linux-sunxi
<jernej>
longsleep: Kodi is indeed such user of framebuffer based driver on OpenELEC
<longsleep>
jernej: yes i know
<longsleep>
jernej: so maybe OpenELEC might be interested on porting to Pine64 at some point
<ssvb>
longsleep: but that's good point about chromium, maybe I'll try it with GLES on my laptop
<ssvb>
longsleep: and if it works fine, then that's a good justification to try to do something with mali blobs
<jernej>
longsleep: I think that only true blocker for that are codecs
<ssvb>
longsleep: I mean, it is not a difficult job, but we need a good justification to spend efforts on it :-)
<longsleep>
ssvb: yes that would be really nice, but Chromium has its own issues on aarch64 - i have not looked into whatever Hardkernel did to make it work
<longsleep>
jernej: not really, cedrus works fine
<jernej>
longsleep: I tried to enable cedrus on Kodi for H3
Wizzup has quit [Ping timeout: 250 seconds]
<longsleep>
jernej: yeah, Kodi and cedrus very outdated and unmaintained last time i checked
<jernej>
longsleep: main problem is that is tied to special NV interop functions which rellla tries to implement them
<ssvb>
longsleep: basically it means that mali r3pX blobs (the ones used on 32-bit sunxi devices) are bad for chromium
<longsleep>
ssvb: Chromiums has OpenGL ES as well via some commandline flags
<longsleep>
ssvb: cant tell if it works in aarch64 though.
<ssvb>
longsleep: the r3pX mali blobs are reportedly just horribly slow in chromium :-) and it means that testing chromium with mali on A20 or H3 is not very meaningful
<ssvb>
but I really would prefer to avoid doing anything mali blob related as an unpaid job :-)
<longsleep>
ssvb: +1
Wizzup has joined #linux-sunxi
<longsleep>
i am also not sure if its worth any effort at all
<longsleep>
who is going to use these devices as desktop, its a mali400 after all only
<ssvb>
the blobs have a horrible EULA
<ssvb>
well, desktop usage does not need 3D drivers
<longsleep>
2GB arm64 cluster for virtualization, compiling and networking - i think it can shine there and mali can be forgotten
<longsleep>
ssvb: true, but web surfing with GL support is much nicer
xenoxaos has joined #linux-sunxi
<ssvb>
longsleep: I'm not so sure about this
<longsleep>
ssvb: eg, try video conferencing, full screen camera rendering at 1080p
<ssvb>
longsleep: hmm, is it something that is accelerated by gles?
<longsleep>
ssvb: yes, all the media rendering is
<longsleep>
ssvb: <video> element
<longsleep>
ssvb: also all the effects, like fading, mirroring, transitions
<ssvb>
don't they hook something like gstreamer or whateve other stuff which makes use of the VPU?
<ssvb>
are you running video conferencing in the browser on your desktop pc?
* ssvb
is not very familiar with this use case
<longsleep>
ssvb: only for playback of static files, sourcing media from local or remote streams
<longsleep>
ssvb: sure, hangouts and stuff
<longsleep>
ssvb: i mean its 2016 and we have WebRTC which is awesome and not working very good so far on any Linux ARM device i have here
<longsleep>
ssvb: at the same time works nice on the same platform on Android
<ssvb>
Android has its own media frameworks, so it is not directly comparable
<longsleep>
ssvb: well its Google Chrome i compare.
<longsleep>
ssvb: fully accellerated in Android, not so much accellerated in Linux
<longsleep>
ssvb: even on the Odroid-C1 with OpenGL ES its not as good as on Android
<longsleep>
ssvb: there is much room for improvment in this area
<ssvb>
as I said, I'm not very familiar with the current states of affairs, but I would assume the use of something like gstreamer which hooks the Cedar VPU acceleration
<ssvb>
but I can't imagine GLES being useful for anything other than scaling
<longsleep>
ssvb: if you open up about:gpu in Chromium/Chrome on Linux you will see a whole lot of Problems detect, ad 2D accell is most likely disabled as
<longsleep>
ssvb: try the same on your Android Chrome :)
reinforce has joined #linux-sunxi
<ssvb>
are you saying that GLES drivers will fix video support in web browsers in linux?
avph has quit [Ping timeout: 246 seconds]
<longsleep>
ssvb: no, it will allow Chromium to try to accellerate things via GLES whatever that means. I does improve 2D rendering framerate a lot making video much more useful
<longsleep>
Chromium can be started like this: chromium-browser --use-gl=egl
<ssvb>
that's cool
<longsleep>
ssvb: on Odroid-C1 this gives full mali hardware accelleration, including Compositing, Rasteriszation, Video Decode, Video Encode and WebGL
<ssvb>
still the fundamental problem is that people get mali drivers, then they try something (the chromium thing or whatever) and appears that just the GLES drivers alone are not enough for perfect experience they have in Android
jernej has quit [Quit: Page closed]
<ssvb>
thanks, that's a good point about Odroid-C1
<longsleep>
ssvb: yeah i know - a good benchmark for the GL capabilities of your browser is http://www.fishgl.com/
<ssvb>
still I doubt that "Video Decode, Video Encode" features are provided by mali
<ssvb>
yes, I'm well aware about webgl
<ssvb>
mali is indeed useful for it
avph has joined #linux-sunxi
<ssvb>
compositing and rasterizations are usually rather easy jobs for software rendering
<longsleep>
ssvb: yes, i do not know what Google is doing with egl but i think it all starts with having EGL in X11 in the first place. Not important for me right now, but if its easy to get ..
<ssvb>
in fact, hardware accelerating them to outperform software rendering used to be hard
<ssvb>
but maybe things have changed now
<longsleep>
well, i dont know - but having a Linux platform which can do decent video conferencing in a web browser could be a game changer
<ssvb>
longsleep: there is now #cedrus channel here :) about getting proper VPU support in the mainline linux and probably integrated into userland frameworks
<longsleep>
ssvb: ah thats cool - maybe that can trigger OpenELEC to make a cedrus variant
<ssvb>
it's hard to expect decent multimedia support when all of this stuff is still basically at the prototyping stage in the mainline kernel (if I understand it correctly)
<longsleep>
well, i guess the 30000 or so Pine64 boards will stay around for a while
<ssvb>
if there were already usable frameworks, then the Cedar VPU would have been probably mainlined long ago
<zuikis>
i wonder what would happen if you would remove "console=ttyS0,115200 " from the bootargs, since it says kernel to output to the serial console instead of framebuffer
avph has joined #linux-sunxi
<TheCageyBee>
Cool. I'll try that. Should the <partion> bit be replaced by a partion number?
<zuikis>
yes
<TheCageyBee>
Right. Back in a few minutes
IgorPec has joined #linux-sunxi
<zuikis>
tbh i used extlinux.conf instead of boot.cmd and i liked it more
cosm has quit [Ping timeout: 260 seconds]
<zuikis>
oh, i think i found your problem, in at the end of simplefb chapter:
<zuikis>
>Don't forget to change your console in your boot.cmd/boot.scr to console=tty1 to enable the simple framebuffer driver.
nieuwbie has joined #linux-sunxi
<nieuwbie>
Hi guys - I have problem with new sunxi-fel - it can't find my tablet via uart even if it is in FEL mode and I can read the output via serial
hulu1522 has quit [Remote host closed the connection]
deskwizard has joined #linux-sunxi
deskwizard has quit []
cosm has joined #linux-sunxi
<TheCageyBee>
Stupid question maybe. I just copy the boot.scr to root of first partion right?
dev1990 has joined #linux-sunxi
<NiteHawk>
nieuwbie: sunxi-fel and FEL mode are related to USB, not serial - what exactly are you trying to do?
<nieuwbie>
NiteHawk: I used to have linux on my tablet - then couple months ago I tried to install mainline uboot and mainline kernel
tipo has joined #linux-sunxi
<nieuwbie>
Tried to put it on sdcard but u boot stopped booting from sdcard and is booting from nand which is broken
selsinork has quit [Quit: Quit]
<zuikis>
TheCageyBee: yes
<nieuwbie>
NiteHawk: I can't see the ID mentioned in wiki, but I can read the output and it is in fel mode
<NiteHawk>
nieuwbie: first thing to check is if your tablet enters FEL mode at all (see the link above). do you see the 1f3a:efe8 device from the host side? (lsusb)
<nieuwbie>
NiteHawk: on my serial I have "jump to fel"
<NiteHawk>
ah, you're entering via boot0?
<nieuwbie>
Do you think it can be related to outdated uboot?
<nieuwbie>
Yes
<nieuwbie>
boot0 .3.0
<nieuwbie>
boot1: 1.3.0
<nieuwbie>
Or do I enter via boot1 then?
<NiteHawk>
actually both :)
<nieuwbie>
My appologies then
<wens>
ssvb: someone mentioned waiting for rockchip to mainline theirs, and use their framework
<nieuwbie>
*apologies
<NiteHawk>
nieuwbie: what does "./sunxi-fel -v ver" tell you?
<nieuwbie>
Nite that it can't find the USB FEL device
<NiteHawk>
hmm... admittedly i've never taken that route (boot0/1), but my understanding is that starting FEL should cause the device ID to appear. apparently that's not the case for you, so it's no surprise that sunxi-fel doesn't find anything
laga has quit [Quit: Changing server]
<NiteHawk>
you have a USB cable attached to the OTG port, right?
<nieuwbie>
Nope, UART
<NiteHawk>
UART only?
<nieuwbie>
Yes.
<TheCageyBee>
K. so tried changing boot.cmd to partition 1 and changed console to tty1. No difference
<NiteHawk>
that's not how it works! FEL is a USB-based protocol
<nieuwbie>
I have iNet 3f
<TheCageyBee>
What do I do with the boot.scr? Just copy to root of boot partition?
<nieuwbie>
True, but I have jumpers connected to cp210x
<nieuwbie>
TheCageyBee: boot partition I believe.
<NiteHawk>
nieuwbie: i think you have found a way to enter FEL correctly, but without the usb connection there's nothing useful you (or rather: the sunxi-fel tool) could do with it
<NiteHawk>
oh, our Inet 3f wiki page sucks. big time... :D
<TheCageyBee>
Am I right in thinking that with mainline u-boot + kernel I shouldn't have a script.bin
<nieuwbie>
NiteHawk: Really? I haven't noticed
<nieuwbie>
NiteHawk: So you are telling me that I need to have usb and uart connected?
<NiteHawk>
no, nevermind - there's a broken/blanked page that should be a redirection instead. (http://linux-sunxi.org/Inet_3f) i'll fix that later
<NiteHawk>
nieuwbie: yes. how else would you make use of the USB-based FEL mode?
<nieuwbie>
via cp210x?
<NiteHawk>
no way. sunxi-fel definitely expects a suitable USB device to be present (visible from the host side)
<nieuwbie>
ok, so basically where should I plug usb cable connecting my tablet with my pc? to host port or to usb port?
<NiteHawk>
the otg port (the one that's capable of exposing the tablet as slave / in "device" mode). i suspect that's what you refer to as "usb" port
<zuikis>
TheCageyBee: there should be .bin file. you are supposed to dd it to the beginning of the card
<nieuwbie>
NiteHawk: Damn, it's working. Thank you so much.
<NiteHawk>
:D
<NiteHawk>
you're welcome. small cause, big effect ;)
Andy-D has quit [Ping timeout: 276 seconds]
<TheCageyBee>
zuikis: I dd'ed the u-boot-sunxi-with-spl.bin. That's definately working cause I'm getting some output to the screen.
doppo has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<TheCageyBee>
I think the dtb replaced the script.bin in the mainline kernel. Is that right?
doppo has joined #linux-sunxi
<zuikis>
yes
tkaiser has joined #linux-sunxi
<zuikis>
what type is first partition? is it fat?
<TheCageyBee>
yes
tsuggs has joined #linux-sunxi
<TheCageyBee>
from the boot.cmd in the line 'setenv bootargs console=tty1 [earlyprintk] root=/dev/mmcblk0p1 rootwait panic=10 ${extra}' should the ${extra} be removed?
<tkaiser>
longsleep: Please forget about my EDID related forum posts regarding A64. I defined 720p and DVI mode in the pine64.dts, rebuilt u-boot and wrote it to the card, rebooted. Settings are valid in u-boot but as soon as kernel takes over the display will be detected correctly and EDID information is taken into account.
<TheCageyBee>
In other places in the wiki that syntax is used to denote changing that part with your system particulars. Not sure it should be there
<longsleep>
tkaiser: ok good, what exactly is the problem them?
<tkaiser>
longsleep: With active DVI mode you will get black as green and screen0_output_mode = <0x00000005>; is 720p, but the kernel detects 1080p display and non DVI mode.
<tkaiser>
longsleep: The problem is that people using HDMI to DVI converter either get no display or wrong colors (black will be purple)
<longsleep>
tkaiser: ok, and that can be changed how?
<tkaiser>
longsleep: So maybe defining hdmi_cts_compatibility = <0x00000001>; by default might be an idea (since when HDMI displays will be detected then EDID should 'win').
<tkaiser>
longsleep: Has to be changed in the .dts prior to building u-boot
<longsleep>
tkaiser: yeah u-boot initialized hdmi very early
<tkaiser>
longsleep: And the kernel obviously relies on EDID correctly. Hmm... am I bit lazy but I will try a DVI display shortly.
<longsleep>
tkaiser: is the DVI mode really a use case we should care about?
Andy-D has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 246 seconds]
<zuikis>
TheCageyBee: do you have 2 partitions? one for boot and one for kernel/rootfs? in that case it should be root=/dev/mmcblk0p2
<zuikis>
because it tells where kernel should search its files
<tkaiser>
longsleep: Nope, since on my DVI display I get now still 1080p/HDMI (black == purple). So somethings happening and it doesn't work as expected (BSP kernel for A83T and H3)
<TheCageyBee>
Ahh.Yep two partitions. That makes sense.
<tkaiser>
longsleep: Maybe the code relies on bits inside sysconfig.fex stuff. So better stay away ;)
IgorPec9 has joined #linux-sunxi
<longsleep>
tkaiser: sysconfig.fex is empty, all things HDMI are from the FTD
<tkaiser>
longsleep: I know. But the kernel ignores both screen0 mode and the DVI setting.
IgorPec9 has quit [Client Quit]
<longsleep>
tkaiser: mhm there are two settings, boot_disp and screen0_output
<tkaiser>
longsleep: And on the display I'm now using (2560x1920 or something like that) obviously also EDID (but we won't get larger resolution than 1080p anyway)
<tkaiser>
longsleep: I only changed screen0_output
<tkaiser>
longsleep: But better we stay away from that since the next question will be: 1024x768 possible? They ask for DVI for a reason ;)
<tkaiser>
To use their 14" LCD back from 1990
<longsleep>
tkaiser: yeah - i stopped the moment i got 1080p/60Hz running :)
sirblackheart has joined #linux-sunxi
<longsleep>
tkaiser: the BSP sysconfig.fex examples have some docs regarding all the possible values for the various display related things
<tkaiser>
longsleep: I know but basically it's just the usual 11 different HDMI modes we already know from other Allwinner SoCs?
<tkaiser>
Exactly. So everyone coming from RPi with their 12.000 or so display settings might be a bit disappointed ;)
<longsleep>
but i think there are more above 1080p60 as the thing can do 4K
apritzel has joined #linux-sunxi
<longsleep>
tkaiser: but 4K framebuffer need more memory for CMA which i currenty configure in kernel
<longsleep>
tkaiser: i have the minimal amount there for 1080p 32bbp with double buffering
<tkaiser>
longsleep: ok, but someone else should then look into with some knowledge and a 4K display. At least for me here tested with 2 displays it seems like 1080p60 is somewhat hardcoded. And I don't care that much especially now (time for Biergarten ;) )
<longsleep>
tkaiser: i am sitting in one with 4G connection :)
<TheCageyBee>
Well that didn't help either. But my sdcard has just died, so I guess that's the end of playing for now. :(
<longsleep>
essentially all the releases from today were powered by Biergarten
<TheCageyBee>
Thanks for your help anyway guys
<tkaiser>
longsleep. Good to know and cheers :)
<longsleep>
tkaiser: Maybe its the beer - but i cannot see any other LED on the Pine64 board :{
<zuikis>
TheCageyBee: np, m8. If you will need to kill another sd card, I'll be here to help :D
<longsleep>
tkaiser: and cheers!
<TheCageyBee>
lol
<tkaiser>
longsleep: LOL, I can't see any either. Maybe it's really only about the possibility to connect those to the Exp connector