<lennyraposo>
I also have custom artwork for the pine DE builds this round ;)
<lennyraposo>
oops
<ssvb>
lennyraposo: hi, sounds like you are doing something cool :)
<lennyraposo>
just a couple of themes for the pine
<lennyraposo>
but what I wanted to let you know about is the Mali 64bit drivers
<lennyraposo>
next week on the 15th they are gonna release
<lennyraposo>
that's the latest
<lennyraposo>
they working with Arm in it's development for the pine
<ssvb>
together with their new drm/kms display driver that they promised or just the mali blob?
<lennyraposo>
as soon as I get word I will pass on all info and links to where they are keeping it
<lennyraposo>
with the drm/kms
<lennyraposo>
and the of course the mali binaries for 64bit builds
<ssvb>
ok, that's good to know
<lennyraposo>
hopefully this can open things for the board
<lennyraposo>
also saw the recent status on the mainline effort
<lennyraposo>
noticed we have ethernet working now
<lennyraposo>
usb display and audio to go
<lennyraposo>
if I read things correctly
<lennyraposo>
miss alot in 2 weeks
<lennyraposo>
lol
<lennyraposo>
quick question ssvb
<lennyraposo>
as I am still learning a few things here and ther ein my spare time
<lennyraposo>
when binaries are released part of the BSP
<lennyraposo>
are those binaries locked to that specific kernel version or can they be implemented into future versions?
<lennyraposo>
I guess what I am asking is if a new binary set is necessary for inclusion into later kernel versions
<ssvb>
they are locked to a specific mali kernel driver version
<ssvb>
but the kernel driver can be used with different kernel versions (the kernel part of mali is open source and can be adapted if necessary)
<lennyraposo>
that includes other soc functionality I assume too
<lennyraposo>
that further explains the BSP versus mainline
<lennyraposo>
BSP you are locked down to whatever binaries they included for what ever kernel versioning scheme
<lennyraposo>
while mainline you can make the necessary changes for future kernel renditions without the worry of something breaking in the process to outdated binaries
<lennyraposo>
which brings me to the next question
<lennyraposo>
mripard was talking about the the inclusion of mali binaries into mainline
<lennyraposo>
for the later mali vpu/gpu
<ssvb>
there are no mali binaries in the kernel, it's all open source
<lennyraposo>
so later mali models have been open sourced?
<ssvb>
it has been open source since a long time ago
<lennyraposo>
I was under the impression that they only released the binaries
<lennyraposo>
wonder why the 4xx series was never open sourced
<ssvb>
still the open source mali kernel driver keeps changing the API/ABI in every release, and the binary blob from the userpace uses this API/ABI
<ssvb>
for example the (incomplete) open source lima driver is compatible with the mali kernel driver interface up to r3p2
<ssvb>
but not with anything newer
<ssvb>
mainlining the mali kernel driver makes no sense because of this, there is simply no stable interface
<ssvb>
and nobody will accept it until there is some open source userland code using this interface
<lennyraposo>
that makes perfect sense
<ssvb>
maybe mripard was talking about supporting basic clock and irq details about the mali gpu in the dts?
<lennyraposo>
I have to check the logs cause there was a mini discussion about it here on irc
<lennyraposo>
in reference to the link provided
<ssvb>
is there some kind of video or presentation document?
<ssvb>
I have seen this abstract, but not real content
<lennyraposo>
I am checking the logs to see the discussion
<lennyraposo>
he did tlak about it abit
Keziolio has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
ninolein has quit [Ping timeout: 264 seconds]
ninolein has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<wens>
maz: fixed the __mdelay issue... turns out my mdelay was calculating ticks the wrong way, and it was calling __udivsi3, which is not in the secure section and not relocated :(
tomcheng76 has joined #linux-sunxi
tomcheng76 has quit [Quit: leaving]
tomboy64 has quit [Quit: Uhh ... gotta go.]
ganbold_ has quit [Ping timeout: 258 seconds]
ganbold has joined #linux-sunxi
reev has joined #linux-sunxi
<wens>
mripard: luoyi: it seems the bananapro and bpi m1+ aren't that similar
<wens>
looking at the schematics, a number of pins are different, such as the peripheral interfaces exposed on the header
<wens>
also, bananapro has BT, while bpi m1+ doesn't
ganbold has quit [Ping timeout: 250 seconds]
ganbold has joined #linux-sunxi
orly_owl has joined #linux-sunxi
<dave0x6d>
what's that Pi board with wireless for like $15?
<lvrp16>
pi lite
<dave0x6d>
thanks, Orange Pi Lite looks like it.
zuikis has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 244 seconds]
cnxsoft1 is now known as cnxsoft
Michal has quit [Changing host]
Michal has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
IgorPec has joined #linux-sunxi
engideavr has joined #linux-sunxi
solarnetone has quit [Read error: No route to host]
<wens>
yeah, they did not fix up the pinctrl nodes...
Vaik5eij has joined #linux-sunxi
<tkaiser>
wens: I compared their .dts with their fex for conflicts but since both were just copy&paste from Banana Pro and then search&replace to eliminate the 'Pro' wording they show the identical glitches.
<wens>
glitches?
<tkaiser>
wens: wrong pin mappings. I tried to buy a M1+ but since the European distributor seems as confused as 'Team BPi' I failed and so gave up on this board over half a year ago
IgorPec has quit [Ping timeout: 240 seconds]
<wens>
tkaiser: i did one from scratch based on the schmatics (if they are to be trusted)
<wens>
u-boot seems to have difficulty reading newer ext4 fs...
IgorPec has joined #linux-sunxi
<tkaiser>
wens: Where can we found your BPi M1+ dts?
<tkaiser>
s/found/find/ (need coffee)
<wens>
tkaiser: let me test it before i push it
<tkaiser>
wens: Ah, you have a BPi M1+ at hands?
<wens>
yes
yann|work has quit [Ping timeout: 244 seconds]
hansg has joined #linux-sunxi
hansg has quit [Remote host closed the connection]
lemonzest has joined #linux-sunxi
premoboss has joined #linux-sunxi
RzR has quit [Changing host]
RzR has joined #linux-sunxi
<NiteHawk>
wens: is that the one that Luo Yi submitted to the ML, or yet another variant of the .dts?
<wens>
NiteHawk: one done from scratch, mainly for comparison against banana pro
<NiteHawk>
ah, okay
solarnetone has quit [Read error: Connection reset by peer]
phipli has quit [Ping timeout: 264 seconds]
massi has joined #linux-sunxi
yann|work has joined #linux-sunxi
premoboss has quit [Ping timeout: 240 seconds]
IgorPec has quit [Ping timeout: 244 seconds]
massi has quit [Ping timeout: 258 seconds]
Andy-D has joined #linux-sunxi
<wens>
crap... hit upper limit of SPL
apritzel has joined #linux-sunxi
massi has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<apritzel>
montjoie: wow, just skimmed over Florian's review, _now_ you got work ahead ;-)
arete74_ has quit [Read error: Connection reset by peer]
<NiteHawk>
wens: how big are the differences with Banana Pro? does it make sense to base one of those .dts on the other (or even both on a common .dtsi), as asked before on the ML?
<montjoie>
apritzel: yes lots of work
premoboss has joined #linux-sunxi
IgorPec has joined #linux-sunxi
<wens>
NiteHawk: differences are in the GPIOs used to toggle various power supplies, and what uarts are available on the header
<wens>
then again, same goes for all the other boards
<wens>
the designs don't vary that much
fdcx has quit [Ping timeout: 246 seconds]
<wens>
pretty much everyone is taking allwinner's reference design, and tweaking bits here and there
<NiteHawk>
i see.
premoboss has quit [Ping timeout: 246 seconds]
<tkaiser>
wens: Thx
massi has quit [Ping timeout: 260 seconds]
scream has joined #linux-sunxi
fdcx has joined #linux-sunxi
premoboss has joined #linux-sunxi
<tkaiser>
wens: Did you test led functionality? The blue one?
<Amit_T>
For pine64 emac what device bindings are used ?
<wens>
tkaiser: it's green & red, no blue one
<tkaiser>
wens: Yes, just seen. And does the red work?
<tkaiser>
wens: Since you chose PH25 but .dts and SinoVoip's fex used PG02 instead. So if PH25 is the correct one you would be the first person seeing this led lighting?
massi has joined #linux-sunxi
<wens>
both work :)
<wens>
the schematics say PH24 & PH25 for the leds
<wens>
and the shutdown_pa pin doesn't exist, as there's no external amp anyway
<tkaiser>
wens: So the red is a real power led that can't be controlled from user space then?
<wens>
tkaiser: it can. it's just pulled-by externally, so by default it is on, and you have to drive the gpio pin low to turn it off
<tkaiser>
wens: Sorry for the dumb question. But when using the old (wrong) value PG02 then this should _not_ work from user space since the wrong gpio pin will be pulled low?
<wens>
correct, though i did not try that
<tkaiser>
wens: Ok, since I wondered that no one noticed the wrong mapping so far. But this explains it.
hansg has joined #linux-sunxi
hansg has quit [Client Quit]
maz has quit [Remote host closed the connection]
maz has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
<KotCzarny>
can random gpio pins be pulled up/down without damage?
<wens>
KotCzarny: if you use the right voltage and a proper resistor, it should be fine
<wens>
but i'm not a hardware designer, nor do i have a ee background
<KotCzarny>
wens, for example, if one would be searching for red led mapping
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
mpmc has quit [Ping timeout: 244 seconds]
enrico_ has joined #linux-sunxi
nove has joined #linux-sunxi
<igraltist>
plaes: no
cnxsoft has quit [Quit: cnxsoft]
dearfibonacci has quit [Quit: Leaving]
IgorPec has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
The_Loko has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
luoyi has joined #linux-sunxi
<luoyi>
wens: the m1+'s pinout and pro's pinout is very different, but I don't found anything in the dts file have relation with the pinout
nixdork has quit [Remote host closed the connection]
nixdork has joined #linux-sunxi
apritzel1 has quit [Ping timeout: 244 seconds]
<Amit_t_>
Hello, I do see these messages when I insert USB stick on opi from u-boot, scanning bus 2 for devices... EHCI timed out on TD - token=0x80008c80
jernej has joined #linux-sunxi
<KotCzarny>
amit, power issue maybe?
luoyi has quit [Quit: Page closed]
<KotCzarny>
scratch that
vagrantc has joined #linux-sunxi
<Amit_t_>
KotCzarny: You mean to say,I should use regular power adapter
<KotCzarny>
nah, reread, its just usb drive
<KotCzarny>
right?
<wens>
what tree are you using?
zuikis has joined #linux-sunxi
<Amit_t_>
wens: Its mainline
<Amit_t_>
its compile against the head b733c278d7adc48c71bd06faf359db3d9e385185
<wens>
i do not have that commit in my local tree
<Amit_t_>
Its upstream u-boot source
<wens>
missed 'u-boot' :(
<Amit_t_>
ohk
<Amit_t_>
KotCzarny: I just insert USB stick to USB slot.
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 272 seconds]
iamfrankenstein1 is now known as iamfrankenstein
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
tkaiser has quit [Ping timeout: 244 seconds]
maz has quit [Ping timeout: 250 seconds]
reinforce has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
<MoeIcenowy>
ssvb: should I use fbturbo on mainline kernel with simplefb?
<ssvb>
MoeIcenowy: yes, you can
<MoeIcenowy>
(seems that it will automatically fallback to AccelMethod CPU
<ssvb>
what kind of hardware is that?
<MoeIcenowy>
ssvb: a33
<MoeIcenowy>
q8-a33-tablet
<ssvb>
yes, but AccelMethod CPU is still working fine
<MoeIcenowy>
(but I'm now suffering GNOME Terminal scrolling lags under both fbdev and fbturbo...
<MoeIcenowy>
(seems that it's not so terrible in SDK kernel with fbturbo + AccelMethod CPU
<MoeIcenowy>
(a33 have no g2d
<ssvb>
yes, this is strange, there should be no real difference between running on the SDK and on the mainline kernel
<ssvb>
unless some clocks are set wrong
<MoeIcenowy>
as it have no g2d?
<MoeIcenowy>
(I also think so
<ssvb>
yes
<ssvb>
also A23 and A33 only have 16-bit dram bus width, which makes them much slower for graphics tasks than their bigger full 32-bit dram width brothers
<MoeIcenowy>
ssvb: en... (but under different distros the performance is different
tkaiser has quit [Ping timeout: 272 seconds]
<MoeIcenowy>
(maybe it's the fault of userspace compliation optimization
<ssvb>
do you have compositing enabled?
IgorPec has quit [Ping timeout: 258 seconds]
apritzel has joined #linux-sunxi
IgorPec has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
Nyuutwo has quit [Ping timeout: 240 seconds]
yann|work has joined #linux-sunxi
VargaD has quit [Ping timeout: 260 seconds]
Nyuutwo has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
VargaD has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 276 seconds]
IgorPec has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
yann|work has quit [Ping timeout: 276 seconds]
<longsleep>
Why is everyone using wiringPi library even if it is so horrible?
apritzel has joined #linux-sunxi
yann|work has joined #linux-sunxi
staplr has quit [Ping timeout: 272 seconds]
tkaiser has joined #linux-sunxi
<diego71>
longsleep: probably because everyone is using it. Cargocult programming.
<longsleep>
diego71: Yes but even for on platforms than the RPi people hack their own version of wiringPi and the upstream authors keep adding checks to prevent just that ..
<longsleep>
well there are others, but essentially most of the stuff out there uses wiringPI and the author does not seem to be interested in opening it up for other platforms and thus its all a total mess
<diego71>
longsleep: but it's orrible because they support only rpi, or for other reasons?
<longsleep>
diego71: well, for RPi it is fine, horrible is the result for other platforms which have some hacked adapted version of it in various states
<longsleep>
diego71: and the wiringPI installation and setup scripting and gear is also very strange - it will just silently sudo if your session allows it and change your system
<diego71>
longsleep: terrible
tkaiser has quit [Ping timeout: 244 seconds]
<willmore>
That is never acceptable.
<longsleep>
and the script people are supposed to run is named ./build
<longsleep>
it had a makefile in the past but it was removed so installation is easier ...
<KotCzarny>
jrg: it should be sent to debian bugtracker
<jrg>
KotCzarny: ah ok. blah. heh
<jrg>
wonder if i can just build a newer version
<KotCzarny>
hehe
<KotCzarny>
you should
<KotCzarny>
its just normal debian
<KotCzarny>
(armhf one)
<jelle>
how do you figure out what accel meter you have, if you can check android? android driver calls itself dmard09, but with the drivers I find it doesn't seem to be that one
<jrg>
KotCzarny: i'm trying it now
<jrg>
KotCzarny: it's just such a pain with creating startup scripts
<KotCzarny>
jrg: what startup scripts?
<jrg>
KotCzarny: the startup scripts required to make a homebuilt samba run automatically
<jrg>
i figured pkgs typically come with these things. but not building it yourself
<vagrantc>
jrg: for what it's worth, there have been at least three versions with additional patches on that samba version ... presumably they'e backported the relevent security patches
<oliv3r>
ssvb: i've been playing with some code in u-boot for the a20 and it works fine, now i've recompiled the code for a10-lime1 and on one of the boards, the spl keeps resetting with timeout initializing dram. the spl that still resides on the flash works however ...
<jrg>
vagrantc: ya my problem is with cifs-utils anyways tho
<jrg>
so probably won't even help much to upgrade samba
<jrg>
mount.cifs is what is driving me up the wall but i guess smbmount is deprecated
<KotCzarny>
jrg, grab debian files, copy to newer samba, done
<tkaiser>
jrg: So you're not talking about Samba at all but mount.cifs?
bonbons has quit [Quit: Leaving]
<ssvb>
oliv3r: maybe try to bisect U-Boot on this board?
<jrg>
tkaiser: i guess. i'm not sure where the problem is. could be samba on the freenas box, could be mount.cifs or samba on the opi
<tkaiser>
jrg: grep Version /proc/fs/cifs/DebugData
<tkaiser>
jrg: You're still using a crappy 3.4.x Allwinner/Android kernel ;)
iamfrankenstein has quit [Quit: iamfrankenstein]
<tkaiser>
jrg: You could try mainline kernel. BPi M2+ image works flawlessly on OPi+ 2E (only one 'missing' led and one USB port since not defined in .dts): http://linux-sunxi.org/Banana_Pi_M2%2B#OS_images
<jrg>
root@opi:~/samba-4.4.4# grep Version /proc/fs/cifs/DebugData
<jrg>
CIFS Version 1.78
<tkaiser>
jrg: cifs fs is not related to Samba
<jrg>
cifs is kernel driven isn't it?
<KotCzarny>
client, yes
<jrg>
there is no longer a smbmount? to run in userspace?
<jrg>
Linux opi 3.4.112-sun8i #10 SMP PREEMPT Wed Jun 1 19:43:08 CEST 2016 armv7l GNU/Linux
<jrg>
tkaiser: armbian doesn't come default with a mainline kernel when possible?
<KotCzarny>
and those boards arent meant to be performance achievers
<jrg>
it's an embedded x64 intel :P
<jrg>
with emmc
<KotCzarny>
i think i prefer opi+2e
<jrg>
KotCzarny: can't be any worse than a xpi
<jrg>
4 core 1.83GHz w/32GB emmc and 2GB ram
<jrg>
4 core x64 heh
<KotCzarny>
its not 1.83, its 1.33
<jrg>
ah you're right. my mistake
<KotCzarny>
and its 3x more expensive
<KotCzarny>
i know it might be quite a bit faster, but its also more power hungry i bet
<KotCzarny>
and expensive
<jrg>
wonder what kind of power it draws
<jrg>
i should get one just to get one .. but i doubt i'd find a case for it
<jrg>
maybe i'll look for one later and buy one
<tkaiser>
jrg: There exist plenty of such boards with Atoms. Even some that mimic RPi form factor (eg. 'UP board', I already fried one while testing thermal behaviour and now they send me another with 4GB)
<jrg>
lol
<jrg>
tkaiser: i haven't noticed any. just came across this thing wondering if maybe the arm build might be the culprit with my little samba/cifs debacle
<jrg>
i'll just have to suck it up and make a vm to test with for x86 arch to see if i have the same issue
Mr__Anderson has joined #linux-sunxi
<jrg>
tbh. i think i give up on this. i've already given it quite a bit of time already. just going to wipe the opi and set it up as a mini web-server etc. maybe set up docker on it and see how far it can go
<tkaiser>
jrg: Nope, you should start to understand that you used both your BPi M3 and now OPi+ 2E with a crappy kernel
<jrg>
tkaiser: raspberry pi has the same issue :)
<jrg>
and those things are a bit farther ahead for the most part with their development
<KotCzarny>
jrg, just wait till h3 gets mainline
<KotCzarny>
as tkaiser says
<KotCzarny>
you are using quite ancient kernel now
<KotCzarny>
if you really want to test, install vm with 3.4.112 kernel too
<tkaiser>
jrg: I don't care at all what the RPi people do. Simply give the BPi M2+ image with kernel 4.6-rc1 a try and look whether that helps. Then you know.
<jrg>
tkaiser: this is for the opi tho
<jrg>
i gave up on the bpi heh
<tkaiser>
jrg: BPi M2+ is H3 based and just a clone of Orange Pi PC/Plus
<jrg>
ah ok
<KotCzarny>
crappy clone
<KotCzarny>
keep that in mind too ;)
<jrg>
i'll try that out later if i have time. maybe it will work. guess all i really need is the lan
<tkaiser>
If you take an OS image for OPi+ 2E you can boot a BPi M2+ and everything works expect of the camera module. And the other way around you just 'loose' 1 USB port and one led as already written. Since it's missing in the device tree definition.
<jrg>
everything else doesn't matter
<ssvb>
jelle: was it you who is working on the u-boot display driver for h3/a64?
<KotCzarny>
if you can get rid of samba (ie. all *nix boxes) you can switch to nfs maybe?
<jelle>
ssvb: and I've basically overwritten the old sunxi video code so that needs to be changed when it works, but it probably needs to go into another file anyway.
cosm has joined #linux-sunxi
<ssvb>
does just setting some fixed resolution work if you ignore EDID?
<jelle>
ssvb: I haven't tried that actaully
IgorPec2 has quit [Ping timeout: 276 seconds]
<jelle>
sounds like a good plan
<ssvb>
NiteHawk: about the uEnv.txt support for FEL boot, would you want to discuss this on IRC?
nove has quit [Quit: nove]
<NiteHawk>
ssvb: sure, why not
<ssvb>
NiteHawk: I just want to understand what's your plan, you mentioned something other than uEnv.txt and I don't see how it fits the whole picture
<NiteHawk>
well, for now I have uEnv-style environment overrides in mind - as you already concluded. this is also what lends itself to a relatively straightforward implementation (or "use case") in U-Boot, as the existing himport_r() can be used on this type of data
<ssvb>
ok, just post a complete patch which does the job on the U-Boot side
<ssvb>
a matching sunxi-tools update would be also interesting to see (and test), but is not strictly necessary
<jrg>
KotCzarny: the problem is when you want to share between all the different operating systems
<jrg>
share the same files that is. you run into problems sharing nfs and smb in the same place
reinforce has quit [Quit: Leaving.]
<NiteHawk>
ssvb: okay. i'll first work out a v2 U-Boot patch (which basically i have code for already), and then create and link an experimental sunxi-tools branch. if the latter is approved, we can turn it into a pull request later
<ssvb>
NiteHawk: sounds like a good plan, thanks
<jrg>
well. i guess i can use smbnetfs
<jrg>
but it won't be as clean as mount.cifs using pam_mount
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein1 is now known as iamfrankenstein
jbrown has quit [Ping timeout: 276 seconds]
jbrown has joined #linux-sunxi
lvmc has joined #linux-sunxi
<lvmc>
How can I use compile.sh when I changed some files?