<ssvb>
longsleep: I'll try a few more tricks to make scrolling performance more competitive with the shadow framebuffer layer
<ssvb>
longsleep: if we had G2D, then scrolling would become a non-issue for A64, but I want to be sure that the generic device independent code path in xf86-video-fbturbo is also fast :-)
<lennyraposo>
kewl ssvb
<lennyraposo>
btw
<lennyraposo>
you have a pine?
<ssvb>
lennyraposo: yes
<lennyraposo>
DE installed?
<lennyraposo>
pulseaudio etc?
<lennyraposo>
gonna assume yes
<lennyraposo>
got audio working without stutters
<lennyraposo>
but I cannot pu tmy finger on what is happening
<lennyraposo>
it's definitely a pulseaudio thing
<ssvb>
I'm not into pulseaudio and don't have it installed
<lennyraposo>
no worries then
<lennyraposo>
has audio been working without stutters for you?
IgorPec has joined #linux-sunxi
<lennyraposo>
basically withou issue?
<ssvb>
haven't tried sound on my pine64 yet
<lennyraposo>
when you do let me know if oyu get any sound issues
mossroy has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
merbzt has quit [Ping timeout: 244 seconds]
<lennyraposo>
well
<lennyraposo>
mp3 wav and ogg files are playing without issues now
foudubassan has joined #linux-sunxi
<plaes>
mainline?
merbzt has joined #linux-sunxi
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 248 seconds]
cnxsoft1 has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft1 is now known as cnxsoft
<ssvb>
plaes: audio on pine64? probably not
<lennyraposo>
nope
<lennyraposo>
not mainline plaes
<lennyraposo>
bsp
<plaes>
ok
<plaes>
high hopes :)
tkaiser has joined #linux-sunxi
<tkaiser>
lvrp16: If you want to do io benchmarks then it's not about SBCs but the used storage and driver situation. So results can't be used the usual moronic Phoronix style.
<tkaiser>
lvrp16: You could choose a really cheap crap SD card, 16/32/64 GB 'middle class' (Samsung EVO) and eMMC 5.0 as used on ODROID-C2.
<lvrp16>
i'm in san diego, landed in orange county and had to drive down :(
<tkaiser>
I'm drinking my coffee ;)
<lvrp16>
tkaiser: i would only use samsung pro+
<lvrp16>
tkaiser: i have a dozen or so 64GB around
reinforce has joined #linux-sunxi
<tkaiser>
lvrp16: Anyway. These sorts of benchmarks are crap. Since they again produce only numbers without meaning. It would be important for people to learn the influence of their SD card on overall user experience (that's random I/O with small record sizes!)
<tkaiser>
Testing sequential transfer speeds is pretty useless for this purpose. Benchmarks could be used to raise awareness for these issues. But they're misused to produce numbers/graphs without meaning.
<tkaiser>
Again and again...
* plaes
agrees with tkaiser
<lvrp16>
well, sequential tests determine the bandwidth from the SoC to the SD card
<lvrp16>
you can do a seek test as well to determine the state of the IO driver
<tkaiser>
A cheap SD card and a Samsung Pro+ or SanDisk Extreme Plus might differ 100 times or even more regarding random I/O while their sequantial transfer speeds are identical.
<lvrp16>
assuming that the SD card is not the bottleneck
<tkaiser>
lvrp16: Yes, benchmarks could be used to show where the bottlenecks are: Sequential speeds: Interface from board to card, random I/O: Only card.
<lvrp16>
tkaiser: i only care about the board to card...
<tkaiser>
Who does this? No one? Larabel even produces numbers where he only tests random I/O of different SD cards and says later 'that's the board in question'. Unbelievable
<tkaiser>
lvrp16: These numbers are already known. And pretty irrelevant when it's about real world usage scenarios
<tkaiser>
It's simply wrong to use these numbers since a fast card showing high IOPS will speed 'normal use' up
<lvrp16>
well not really, some the hubs are tied to ethernet, some are not
<lvrp16>
i would cover all of the cases by maxing out all the buses
<tkaiser>
lvrp16: It's well known that you should avoid any RPi when it's about I/O or networking
<tkaiser>
That's not a benchmark case that's a 'don't use RPi if you want to...' case
<lvrp16>
i don't even care about raspberries at this point...rpi is just slow
<tkaiser>
There's nothing to test. Simply switching on the brain is enough. But since all these crap benchmarks comparing useless integer and FP algorithms people will never get that
IgorPec has joined #linux-sunxi
<lvrp16>
they are good for their expandability at this point
<lvrp16>
i plan to bundle GPU, GPIO, IO bandwidth
<lvrp16>
into one article
<lvrp16>
bought some 200mhz scopes and all
<plaes>
um.. for what?
<lvrp16>
GPIO testing
<lvrp16>
see how fast their GPIO pins can be driven
<tkaiser>
lvrp16: Good luck. I would do it differently but as long as people blindly believe in crap benchmarks the Phoronix style it's useless to try to educate them about these differences. Since people hate thinking and like looking at simple graphs telling nothing relevant
mossroy has quit [Remote host closed the connection]
<lvrp16>
tkaiser, it's not about those people. they're already lost
<lvrp16>
but some people might genuinely want to know certain performance characteristics without having to buy each board and test themselves
<lvrp16>
it's an aid, not the ends
IgorPec has quit [Ping timeout: 248 seconds]
<tkaiser>
lvrp16: But still there's nothing to test but a lot to explain. Orange Pi PC with mainline kernel, a fast SSD and an UASP capable enclosure performs way better (IOPS) as when having to rely on 3.4.x kernel
<tkaiser>
Just one example. Same things might happen when you measure 'GPIO speed'
<lvrp16>
yeah but the benchmarks are not simply a reflection of hardware capability. they are also a reflection of software capability. if i go and try to do something, i will be limited by both
<tkaiser>
Benchmarks could be used to provide _explanations_ but instead they're misused to produce numbers, rankings and a lot of other stuff that prevents people from starting to think about the 'performance issue'
<lvrp16>
yes the software capability changes, but that does not make the information about the current state irrelevant
<lvrp16>
tkaiser, you're being too logical
<tkaiser>
lvrp16: True, but then you have to explain that you now tested hardware+software and things might change next week since device xy will then be supported by mainline kernel
<tkaiser>
And so on...
<lvrp16>
and then next week, you release a new set of numbers ;)
<bwarff>
it only affects the im building my own smart-tv crowd :P
<lvrp16>
have a little faith
<tkaiser>
lvrp16: My 'problem' with benchmarks is when the results are misleading. Especially when end-users are concerned since they lack understanding. When I produce a benchmark run where all contestants perform nearly identical (25% variation) then I don't publish numbers but say 'integer performance is close enough, no numbers needed, let's focus on the things that matter' (like random I/O for example)
<tkaiser>
To produce useful numbers with today's SBC you would have to re-run each set of tests three times with each board: 1st with no heatsink, then with a 'standard' heatsink and then with heatsink and fan. Just to show what people can expect when they refrain from using an annoying fan (with A83T for example: 50%-60% of top performance compared to heatsink+fan)
<tkaiser>
And then you would have to explain that these numbers are also meaningless unless you run all the time demanding multithreaded stuff on the board. Normal workloads need most of the times only singlethreaded top performance. And so on.
<bwarff>
the kernel it comes with and the sandisk the local office supplies sells is the metric of champions
<tkaiser>
You could use benchmarks to educate people what really matters. Why a ODROID-C1+ feels faster than a Pine64 even if the usual PTS crap tells a different story.
<bwarff>
cause odroid has nice emmc and people havent learnt that yet
<tkaiser>
bwarff: Yes, that's one reason. eMMC does really matter for many use cases. And then it's about GUI acceleration.
<tkaiser>
The eMMC issue can't be 'fixed' with Pine64 (only with a new hardware rev since they use the eMMC pins already for something else), the GUI acceleration might improve over time
<bwarff>
people compare prices without comparing things like emmc, its all down to a price bullshit and people get what they deserve.
reev has joined #linux-sunxi
yann|work has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
massi has joined #linux-sunxi
IgorPec has quit [Ping timeout: 248 seconds]
<tkaiser>
bwarff: It's even worse since people are confused by benchmark numbers and 'common knowledge' they start to slow storage down on boards with onboard eMMC. Banana Pi M3 has onboard eMMC (not that fast and they use different modules on the first and subsequent production batches).
<tkaiser>
And a horribly slow USB-to-SATA bridge. Since most people believe this is 'true SATA' they try to move the rootfs to a connected disk that will be accessed multiple times slower compared to internal eMMC.
<bwarff>
yes, not knowing the real io path on the unit and which have dedicated channels and which just ram everything through usb2
<tkaiser>
bwarff: It's not just USB2.0, the GL830 used there (and on Cubietruck 5/Plus and Orange Pi Plus) is horribly slow. By avoiding the 'SATA port' on these boards and using any cheap external USB disk enclosure performance improves a lot. And with mainline kernel and an UASP capable USB-to-SATA bridge performance will be more than 2 times better compared to the 'onboard SATA'. That's something worth to mention but no benchmark
<tkaiser>
so far tests stuff like this.
ricardocrudo has quit [Ping timeout: 246 seconds]
mane has joined #linux-sunxi
gzamboni has quit [Ping timeout: 268 seconds]
gzamboni has joined #linux-sunxi
whitesn has quit [Ping timeout: 250 seconds]
Shirasaka-Hazumi has quit [Quit: ZNC 1.6.2+deb2+b1 - http://znc.in]
tsuggs has quit [Ping timeout: 250 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
camh has quit [Ping timeout: 268 seconds]
<agraf>
ssvb: there's a good chance you could just use caches for the frame buffer
<agraf>
ssvb: btw, have you managed to get hdmi working with an upstream u-boot yet?
<agraf>
ssvb: the downstream bsp de linux code seems to fail to initialize something
<ssvb>
agraf: the enabled cache would break so many assumptions in various pieces of code
jbrown has quit [Ping timeout: 268 seconds]
<agraf>
ssvb: when booted with preinitialized hdmi (downstream u-boot) everything works, when booting without initialized hdmi (upstream u-boot), i can make it show a single solid color on the screen
<agraf>
ssvb: well, you can always use a shadow fb and copy into a cached real frame buffer
<agraf>
ssvb: then all your assumptions rely on the shadow fb which stays the same as before
tsuggs has joined #linux-sunxi
<ssvb>
but yes, I have also evaluated the cached solution in the past, some ARM processors even supported write-through cache which is perfect for this task
<agraf>
all modern arm cpus support write-through, no?
jbrown has joined #linux-sunxi
whitesn has joined #linux-sunxi
whitesn has quit [Changing host]
whitesn has joined #linux-sunxi
<ssvb>
modern arm processors tend to treat write-through attribute as uncached with write combining
<maz>
agraf: as usual, write through is just a hint. it may or may not be implemented.
<agraf>
ah, ok
yann|work has joined #linux-sunxi
<agraf>
either way, with shadow fb you don't ever have to read back, no?
<agraf>
unless you want to screen capture 3d, hm
<ssvb>
the whole point is to get rid of shadow fb, because it is slow
mane_ has joined #linux-sunxi
<agraf>
oh? ok
<agraf>
also, i guess you're running with the bsp kernel (because you do have graphics at all)
<agraf>
in that case, you also have access to mali
<ssvb>
I'm more interested in high performance software rendering
<agraf>
how come?
<ssvb>
because that's what provides the best performance at the moment?
mane has quit [Ping timeout: 268 seconds]
<ssvb>
glamor has been under development since a long time ago, it is slow, buggy and requires working GL drivers
<ssvb>
maybe some day it will work fine with freedreno or vc4
<Seppoz>
where would i check out the most recent version of the sunxi kernel?
<agraf>
i see, i figured it would be the best thing to target for things like the pine
<agraf>
but then again, i can see why mali makes it hard
<agraf>
either way, i first need to get any display output at all
<ssvb>
there is work in progress drm/kms driver for h3
<agraf>
it looked like licensing fears stopped that one, no?
<ssvb>
I haven't tracked its progress lately
<agraf>
i just stumbled over the email thread a few days ago
<Seppoz>
RTL8192CU is the only one i got working here so far
<Seppoz>
but none of the more modern
<bwarff>
RTL8188CUS is the one im currently having most success in (not for bandwidth) as much as reliable up/down
ricardocrudo has joined #linux-sunxi
tkaiser has joined #linux-sunxi
<tkaiser>
Seppoz: Have you tried mt7601 instead? In Armbian we include the driver from here https://github.com/porjo/mt7601/ and it's reported to work ok.
tkaiser has quit [Client Quit]
<Seppoz>
tkaiser: actually the RTL8188CU is te one crashing
<plaes>
for mainline there's new rtl8xxxu driver for realteks
<Seppoz>
not using mainline
<ssvb>
agraf: doing framebuffer readback from two threads improves the performance only by a factor of ~1.5x, but still ~30 FPS are better than ~20 FPS
<ssvb>
I guess, adding even more threads does not make much sense
<agraf>
ssvb: so which frame buffer are you reading back from?
<agraf>
ssvb: the one that layer0 points to?
<agraf>
ssvb: because that one just resides in ram, no?
<agraf>
ssvb: I still haven't managed to fully get my head around how the display engine works
<ssvb>
just mmap of /dev/fb0, whatever it is
<agraf>
ssvb: yeah, /dev/fb0 is just an in-ram frame buffer that gets mapped to layer0
<ssvb>
yes, most ARM devices have their framebuffers stored in system memory
paulk-collins has joined #linux-sunxi
<agraf>
ssvb: which then gets associated with some mgr code and mapped onto some overlay and scaled into the actual output picture iiuc
<agraf>
ssvb: so it's at the beginning of your chain, 3d for example won't ever get written back to that fb
<agraf>
ssvb: because that comes in another layer later on
<ssvb>
the display controller scans out the framebuffer via DMA
<agraf>
ssvb: i guess you'd also implement xv through layers if you wanted to do it correctly
<agraf>
ssvb: right
mane has joined #linux-sunxi
<ssvb>
oh, in fact the display controller can scan out multiple layers and is compositing them on the fly
<agraf>
exactly
<agraf>
up to 4 i think
<agraf>
with different zorders and overlapping
<agraf>
not sure if it can do alpha blending
<agraf>
it might
<agraf>
ssvb: but that means that mapping it as cached is probably not a bad idea at all
<agraf>
ssvb: you get 64byte reads rather than your average 8-byte memcpy ones
<agraf>
ssvb: and you get readahead
<agraf>
ssvb: it should be a massive speed boost, just invalidate the dcache for the fb region before you read
<ssvb>
cached framebuffers mean coherency issues, there must be cache flushes explicitly added
<ssvb>
and such cache flushes need damage tracking, similar to shadow framebuffer
<agraf>
could you map it twice?
<agraf>
preferably WC for writes and cached for reads
<ssvb>
ARM can't make up their mind about mapping the same memory with different caching attributes
<ssvb>
they had some description in the ARMv7 architecture manual about the implications, so in theory this can be done
hansg has joined #linux-sunxi
<ssvb>
however mapping the same memory with different attributes is forbidden in the linux kernel
<ssvb>
maybe maz can say something about it
tipo has quit [Remote host closed the connection]
<ssvb>
nobody wants to deal with this stuff, because it is potentially dangerous
tipo has joined #linux-sunxi
orly_owl has quit [Ping timeout: 244 seconds]
<ssvb>
agraf: anyway, the uncached framebuffer readback using the CPU is a generic solution, which does not need anything special in the kernel and works everywhere
<Seppoz>
so if you git pull the original 104 and apply the patch series the build for this driver fails
<Seppoz>
linux-sunxi/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c:1983:7: error: 'HW_VAR_KEEP_ALIVE' undeclared (first use in this function)
<NiteHawk>
IgorPec: ^
tkaiser has joined #linux-sunxi
<Seppoz>
kaiser: ping
<tkaiser>
Seppoz: pong. Not interested in this RTL8192 crap at all and since users aren
<IgorPec>
nitehawk: uff , what was about that patch?
<tkaiser>
't complaining it obviously works
<NiteHawk>
IgorPec: dunno, ask Seppoz :) looks like he's experiencing a build breakage when cherry-picking the patch
<Seppoz>
IgorPec: i think those defines are missing
<tkaiser>
Seppoz: You should be aware that the Armbian build system applies all these patches in an automated fashion and if a patch breaks usually one of us fixes this within hours. So no need for further investigation unless you report that the patch breaks when used from within Armbian build system
jemk has quit [Quit: Lost terminal]
<Seppoz>
all i did was git pull and apply ALL the patches that are not marked disabled. as i suppose armbian does the same a build for sun7i should fail atm
<IgorPec>
and you need to apply them in this order too
<Seppoz>
i did
<IgorPec>
mmm
<Seppoz>
all succeeded
<IgorPec>
this driver is fu*** up anyway (rtl8192) and i think those were some last tries to fix it
<PietreLinux>
Hi all, because I spent the day compiling the kernel sunxi , the u- boot and tools sunxi , I created a script that sets the system to work with this. Download the dependencies to compile and tools like adb and others, anyone can use https://github.com/pietrelinux/scksunxi.git
<plaes>
uhh.. sudo
<PietreLinux>
I've just done to give me things and not have to download one or the same again , any advice or help is welcome
<PietreLinux>
I have a tablet woxter ( a10 ) where I could run Ubuntu 14.04 from the micro -sd , this added to the wiki http://linux-sunxi.org/Woxter_PC97
leio has quit [Remote host closed the connection]
leio has joined #linux-sunxi
sirblackheart has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 248 seconds]
sirblackheart has quit [Quit: sirblackheart]
tomboy64 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
premoboss has quit [Read error: Connection timed out]
premoboss has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
tomboy64 has joined #linux-sunxi
<scream>
montjoie, nice! can you share the patches?
<montjoie>
scream: yes, since it seems working for more than one hour I will release them
<scream>
cool! I'll have to reflash the card though. messed with openelec for a while. suprising how well it works :D
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
apritzel has joined #linux-sunxi
nove has joined #linux-sunxi
hansg has quit [Quit: Leaving]
premoboss has quit [Ping timeout: 276 seconds]
reinforce has quit [Quit: Leaving.]
apritzel has quit [Ping timeout: 244 seconds]
<Seppoz>
omfg
<Seppoz>
the reason why it DID NOT work was because i had both the C and the CU driver selected
<Seppoz>
i mean wtf
merbzt has quit [Ping timeout: 276 seconds]
<montjoie>
scream: I just need a final test after removing debug and some memory barrier
<jernej>
alain__: I manage to get it working on PLUS :)
<alain__>
brillant
<alain__>
by tweaking the dtsi file ?
<jernej>
just remove PD6 definition from emac_rgmii_pins
<jernej>
and then execute "gpio set PD6" in u-boot
<jernej>
ofc, this is quick workaround
<alain__>
ah ok and then the kernel does not touch it
<jernej>
yes
<jernej>
and now I'm going to test new version of driver :)
<alain__>
same here :)
<tkaiser>
jernej: alain_: First test should be an iperf -c -t60 $server -d (since if this doesn't lock up then everything's perfect from the very beginning ;)
<jelle>
nice
IgorPec has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
afaerber has quit [Quit: Ex-Chat]
<jernej>
montjoie: probably you should remove pins PD6, PD11 and PD14 from emac_rgmii_pins definition, because they don't have any functionality (RGMII_NULL) and at least PD6 is used for other stuff
<alain__>
jernej: would you happen to have a dtsi file that has both the eMMC and emac for the OPI Plus ?
<jernej>
alain__: yes, I applied emac patches on top of mripard's sunxi/for-next branch, which already has eMMC bits
<alain__>
is it accessible on github? that's exactly what I am after
<jernej>
which part? eMMC?
<jernej>
or my changes?
<alain__>
eMMC + emac merged
<jernej>
no, I didn't upload it yet
<jernej>
anyway, I'm using build system which is using patches, so to speak, changes get merged only during build
<alain__>
I'll just play around with the emac driver on a SD card for now, I guess the updated driver will somehow trickle to Hans' tree
<jernej>
but I can always put it on pastebin if you want
<jernej>
just be aware that opiplus dts is based on opi2
<alain__>
yes i've seen that change a few days ago
<alain__>
montjoie: btw I'm getting errors when building the kernel straight from your tree
<tkaiser>
IgorPec: Will you look into this if tests results reported by jernej and alain_ look already promising? Talking about adding this to vanilla for OPi+
<montjoie>
wens: sorry I misread you. Still rx errors
<montjoie>
but tx is stabble, no timeout
<plaes>
montjoie: You don't have permission to access /ethernet/0108-ARM-dts-sun8i-Add-support-for-H3-usb-clocks.patch on this server.
<plaes>
same for 109
<montjoie>
solved
iamfrankenstein1 has quit [Quit: iamfrankenstein1]
khuey is now known as khuey|away
iamfrankenstein1 has joined #linux-sunxi
<wens>
montjoie: ok
jernej has quit [Ping timeout: 244 seconds]
jernej has joined #linux-sunxi
<wens>
montjoie: updated both my a83t and h3 branches
ricardocrudo has quit [Ping timeout: 248 seconds]
<longsleep>
ssvb: Hey, does it make sense to roll a new f86-video-fbturbo deb package from your aarch64 branch already or should i wait a couple of days?
<ssvb>
longsleep: please wait, I'll push the patches to the master branch when they are ready
<longsleep>
ssvb: ok - just browsed your repository and was wondering :)
tkaiser has quit [Ping timeout: 248 seconds]
tkaiser has joined #linux-sunxi
<lennyraposo>
I will give that a try next longsleep
<longsleep>
lennyraposo: what exactly?
<lennyraposo>
longsleep
<lennyraposo>
the fbturbo stuffs ;)
<lennyraposo>
also
<lennyraposo>
audio issue is to do with alsa/pulseaudio
<lennyraposo>
config
<longsleep>
lennyraposo: well, what X11 driver do you use now?
<longsleep>
lennyraposo: yes i know, but i have no wish to learn about pulse alsa and all that to fix it :)
<lennyraposo>
would have to check
<lennyraposo>
whatever came with arm64 debian ports
<lennyraposo>
I will record video showing what I did
<lennyraposo>
and the playback
<longsleep>
lennyraposo: so you added some alsa config?
<tkaiser>
jernej: Did you succeed in testing GbE on the Plus?
<lennyraposo>
changed the default card to sndhdmi
iamfrankenstein1 has quit [Ping timeout: 250 seconds]
<longsleep>
tkaiser: dont give up on the pine64 board please, i have a lot of fun reading :)
<lennyraposo>
then in pulse disabled the audiocodec device ;)
<longsleep>
lennyraposo: hum ok
<jernej>
tkaiser: I didn't do iperf if that's what you mean
<lennyraposo>
installed pavucontrol
<lennyraposo>
to do so
<tkaiser>
longsleep: Nope, for the moment it's enough. Unless the Pine64 folks provide some sort of a FAQ it's just a waste of time and efforts (and nerves)
<jernej>
tkaiser: I'm trying to enable PD6 without u-boot
<tkaiser>
jernej: ok
<lennyraposo>
goonna write up the config manually as alsactl store seems ot do nothing and resetsw the config on reboot
<jernej>
tkaiser: through dts, but phy-supply doesn't work for some reason or I mess something up
<lennyraposo>
btw
<longsleep>
tkaiser: i have confined myself to the developer threads, especially the ones i created myself
<lennyraposo>
the only display option is 1080p for now right?
<longsleep>
lennyraposo: no, ther are other options but they have to be set in FTD
<lennyraposo>
I can ask tllim what resolutions are fully supported
<tkaiser>
longsleep: Yes, but I've been still in the 'parse collective weirdness' mode to provide you with some helpful insights what's really happening regarding the Ethernet bug. But this is solved fortunately now
<longsleep>
tkaiser: yes, not for Android though
<tkaiser>
longsleep: Who cares? They have to take their fix and deploy a new image
<tkaiser>
s/their/your/
<longsleep>
lennyraposo: well, just look into the BSP to see what is supported, with my Kernels max is 1080p@32bpp
<lennyraposo>
I can put a selection method/hierchy in there correct
<lennyraposo>
still learning as you know ;)
<longsleep>
lennyraposo: that needs testing, U-Boot is initializing HDMI very early and it is unknown if the Linux Kernel driver can change the HDMI resultion later on
<longsleep>
lennyraposo: you can change the fb resolution with fbset easily
<tkaiser>
longsleep: lennyraposo: I did some tests yesterday and modifications to the .dts worked in u-boot but kernel seemed to use 'hardcoded' 1080p60
<tkaiser>
jernej: just realized that I never saw any iperf numbers for the OPi Plus with BSP kernel. But I would suspect they should be similar to A83T (Banana Pi M3)
<longsleep>
tkaiser: mhm, i managed to get it running with 720p while getting HDMI running in February
<tkaiser>
longsleep: Did you zeroed out sysconfig.fex stuff back then already?
<longsleep>
tkaiser: mhm no idea :)
<jernej>
tkaiser: I could do it, but some other day
<tkaiser>
longsleep: Ok, will remain a miracle (or an exercise for others ;) )
<tkaiser>
jernej: No need to. SinoVoip sent a Banana Pi M2+ out (for whatever reasons) so I will have a look myself.
<tkaiser>
BPi M2+ needs config from Orange Pi Plus and only USB config has to be slightly adjusted. Pretty identical clone
<lennyraposo>
good to know guys
<lennyraposo>
btw
<jernej>
tkaiser: Ok. Which emac patchset do you plan to use on Armbian?
<lennyraposo>
longsleep have you been using gcc 4.8 for u-boot and 5.2 for kernel?
<jernej>
tkaiser: If I create patch for phy-supply, it would be nice if it would work on both systems
<tkaiser>
lennyraposo: Sure (RTFM ;) )
<longsleep>
lennyraposo: yes
<lennyraposo>
:D
<lennyraposo>
awesome
<lennyraposo>
btw
<tkaiser>
jernej: Agreed. ATM I would stay with wens' branch (since it worked out of the box and he also has Cubietruck + in his hands)
<lennyraposo>
if ther eare any resources you guys need like hosting storage feel free to ask ;)
<tkaiser>
jernej: But I do not really know. Maybe leaving it up to IgorPec since he tests with OPi + :)
<IgorPec>
i am compiling right now ,)
tomboy64 has quit [Ping timeout: 264 seconds]
foudubassan has quit [Ping timeout: 248 seconds]
apritzel has joined #linux-sunxi
<IgorPec>
tkaiser: uboot stucks at USB0
vagrantc has quit [Quit: leaving]
<tkaiser>
IgorPec: Remember the report from yesterday in the forums?
<IgorPec>
nope, i am in half sleep mode :(
<lennyraposo>
you think th e2gb model will be good enough for stand alone compiling in the future longsleep
<lennyraposo>
cause I ordered an additional for those purposes
<tkaiser>
longsleep: We had a reported issue with H3 BSP kernel that corrupted AppleTalk multicast packets. I tried it out just for fun with your Xenial image: Also broken (maybe at Allwinner nobody knows that there exist other protocols than IP? ;)
<tkaiser>
longsleep: Should I open an issue on Github? ;)
khuey|away is now known as khuey
apritzel has quit [Ping timeout: 244 seconds]
cosm has quit [Ping timeout: 246 seconds]
megi has joined #linux-sunxi
tkaiser has quit [Ping timeout: 252 seconds]
mossroy has quit [Remote host closed the connection]
<megi>
I used atalax's THS patch and cleaned it up a bit based on the mailing list review. This seems to work with an exception that on boot, some initial readouts are wrong (271°C), so I needed to disable critical temperature trip point in thermal zone, because otherwise kernel panics immediately on boot.
<megi>
OrangePI One stuff works quite well. It's just a simple GPIO based regulator. I hooked it up to cpufreq-dt and thermal_zone, and frequency/voltage changes work.
<megi>
OrangePI PC is giving me a bit of trouble. I wrote SY8106A regulator driver, and figured out how to enable TWI_R (I2C) interface on PL0/1 pins. I can set voltages correctly using this driver (verified using voltmeter).
<megi>
But I have trouble hooking this up with cpufreq-dt. Board boot fails when cpufreq should be intializing. I can see using voltmeter that cpufreq selects the 1.3GHz/1.32V mode. But then I loose UART connection to the board shortly after. It looks like some kind of a power failure.
<megi>
Any ideas on how to debug this? I'm at loss at this point. I have Orange PI PC connected to 5V/30A power supply over a good cable.