Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
pseudomind has joined #linux-sunxi
gzamboni has quit [Ping timeout: 250 seconds]
gzamboni has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
jstein has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 276 seconds]
montjoie_ has quit [Ping timeout: 240 seconds]
montjoie has joined #linux-sunxi
pseudomind has quit [Quit: pseudomind]
ninolein has quit [Ping timeout: 258 seconds]
ninolein has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
amond has joined #linux-sunxi
<MoeIcenowy> Among HiKey, DragonBoard and Pine64, which one should I choose?
amond has quit [Ping timeout: 250 seconds]
kaspter has joined #linux-sunxi
pseudomind has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
OverCR has joined #linux-sunxi
IgorPec has joined #linux-sunxi
OverCR has quit [Client Quit]
IgorPec has quit [Ping timeout: 240 seconds]
pseudomind has quit [Quit: pseudomind]
_stephan has joined #linux-sunxi
Nacho has quit [Remote host closed the connection]
Nacho has joined #linux-sunxi
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
DullTube has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
pseudomind has joined #linux-sunxi
pseudomind has quit [Quit: pseudomind]
tithrion has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
pseudomind has joined #linux-sunxi
pseudomind has quit [Client Quit]
IgorPec has joined #linux-sunxi
<_stephan> has anybody experienced problems with the A20 RTC in mainline kernel? I "lose" about 45 minutes a day (device is usually off 15 a day)
dearfibonacci has joined #linux-sunxi
<_stephan> axp209 ldo1 is set up (1.3V) in the dts... maybe something is going wrong after shutdown (lipo battery then should drive it)
<_stephan> maybe I can measure the voltage and check it.
<_stephan> just asking if somebody already knows something about this :)
fire219 has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
<_stephan> okay, I even have a serious drift, while the board is running...
reinforce has joined #linux-sunxi
<mripard> MoeIcenowy: I never said it would
<mripard> _stephan: that's bad, but no idea :/
<_stephan> maybe I fried it while I've been messing with the regulators... I'll try another board... :)
<wens> afaik debian's hwclock writes back the data every hour
<wens> but i'm already getting 3 min drift on my cubietruck
<wens> nope, i was wrong, no writeback :(
<_stephan> I use a custom yocto basted distro, no writeback here either...
<wens> _stephan: if it makes you feel better, my cubie's have a lot of drift too
<_stephan> :D thank you
<_stephan> I'll see, if I can find anything interresting in the 3.4 driver, for it was working quite well before I migrated to mainline...
<_stephan> interresting... the old kernel module sets the clock to an external 32.768 khz crystal instead of an internal 32.000 khz crystal...
<_stephan> 2.5% drift...
<_stephan> that'd be about 90 seconds per hour
<wens> i guess that's a bug
<_stephan> I'll investigate it further
<wens> mripard: it looks like the bananapi-m1-plus dts is indented with 4 spaces instead of tabs
matthias_bgg has quit [Quit: Leaving]
<wens> mripard: i'm doing some bananapi cleanups to get my boards up
<wens> mripard: since you already sent a pull request, i'll do a follow up patch re-indenting stuff before i add more?
zuikis has joined #linux-sunxi
<mripard> wens: yes, please
<MoeIcenowy> mripard: what the pity
<MoeIcenowy> it's currently the only way to get my large-page MLC to work...
<mripard> MoeIcenowy: MLC work is on-going
<MoeIcenowy> mripard: after the work is done I can get CHIP use all the 8GB MLC space?
<jelle> just got my CHIP, it works quite nicely
<jelle> now wondering though how I can create my own nand image :-)
<MoeIcenowy> (but my CHIP is still in transit
<TheLinuxBug> IgorPec: you should add ' svn co https://subversion.assembla.com/svn/smplayer/smplayer/trunk/ smplayer' to armbian for H3 and config it to use mpv w/ vdpau -- would provide a video player with full working OSD, was originally contributed by ikeeki for A10/A20 but also works for H3 it looks like since you are using vdpau + mpv (you can search this channels log for more info)
<TheLinuxBug> MoeIcenowy: mine is too should be here in next 2 days
<TheLinuxBug> IgorPec: I have compiled it on your Jessie for Orange Pi Plus 2E and its working well.
<MoeIcenowy> the shipment is tooooooooo slow, in the time that is cost now I can walk to Hong Kong
<MoeIcenowy> :-(
<TheLinuxBug> MoeIcenowy: I was bitching to a friend about it because they promised delivery in June and instead 'shipped' it in June, as far as I am concerned it arrived late.
<TheLinuxBug> MoeIcenowy: Mine has made it to the US, but it still probably 1-2 days away
<TheLinuxBug> MoeIcenowy: I am hoping sinceI have a priority package coming through the same post office where the package is currently located that maybe it will hitch a ride on the same transport and get here at the same time ;p
<jelle> I was quite happy by the CHIP's performance
<TheLinuxBug> I will be happy to test it out when it finally arrives lol
<MoeIcenowy> I'm at Canton China! only one hundred kilometers away from HK! And it have took 14 days now!
<MoeIcenowy> So slooooooooow
<TheLinuxBug> IgorPec: You do need to install qt4-qmake, libqt4-dev, libqt4-dev-bin, qt4-dev-tools to compile it I believe but that was easy enough
<mripard> MoeIcenowy: you'll have to reflash, but yeah
<MoeIcenowy> mripard: thus... how is SPL and U-Boot flashed on CHIP now?
dearfibonacci_ has joined #linux-sunxi
<jelle> MoeIcenowy: I used the chrome extension
<mripard> you have fastboot support as well
<MoeIcenowy> chrome extension... What the hell
<jelle> MoeIcenowy: yeah what the hell, but it works lol
<MoeIcenowy> mripard: CHIP U-Boot supports fastboot?!
dearfibonacci has quit [Ping timeout: 250 seconds]
<mripard> yes
<mripard> why is that surprising?
<mripard> mainline u-boot supports fastboot
dearfibonacci_ has quit [Client Quit]
<MoeIcenowy> mripard: wow
dearfibonacci has joined #linux-sunxi
<_stephan> okay... adjusted the code... now I'm curious, if it fixes the bug :)
<MoeIcenowy> mripard: oh the mainline fastboot support can be used on A10/13/20/23/31/33 now?
<mripard> MoeIcenowy: if it has writable storage, yes
vagrantc has joined #linux-sunxi
<_stephan> I'll let watch -n1 'date && hwclock -r' run for some time and see if there is still a drift.
IgorPec has quit [Ping timeout: 276 seconds]
Andy-D_ has joined #linux-sunxi
DullTube has quit [Quit: Leaving]
<MoeIcenowy> mripard: is there any official support channel of CHIP on freenode or somewhere else?
Andy-D has quit [Ping timeout: 246 seconds]
<_stephan> 0 seconds drift within the last 10 minutes... looks good.
<_stephan> sorry for the noob question... should I base my patch on https://github.com/linux-sunxi/linux-sunxi branch sunxi-next or sunxi-devel or rather on kernel.org git?
Andy-D_ is now known as Andy-D
<wens> sunxi-devel is dead
<wens> sunxi-next is a subset of linux-next, with only sunxi related -next stuff
<wens> the "normal" way is to base patches off the subsystem tree the patch is for
<_stephan> okay, thank you :)
russell-- has joined #linux-sunxi
rZZZr is now known as RzR
<mripard> MoeIcenowy: you have the forums, and #chipsters, there's a bunch of NTC employees
yann|work has quit [Ping timeout: 240 seconds]
<MoeIcenowy> mripard: thx
<wens> mripard: do you think we should remove "sinovoip" from the compatible and board model strings?
<mripard> from the model, if that's relevant, we can
<mripard> but we can't for the compatible
<MoeIcenowy> for compatible, it shouldn't exist twice
<MoeIcenowy> sinovoip, bpi-m2+ is ok
<MoeIcenowy> but I think dt file name should be "sun8i-h3-bpi-m2-plus.dts"
apritzel has joined #linux-sunxi
<wens> where does everyone (outside of asia) go to for bananapi info/vendors anyway?
<wens> MoeIcenowy: i'm renaming it to sun8i-h3-bananapi-m2-plus.dts
<wens> just realized there's no bpi-m3 dts in the kernel tree
<wens> i must've forgotten to submit it
<mripard> wens: renaming DT is not ok
<mripard> if we have a poorly chosen name, then it's too late
<wens> :(
<MoeIcenowy> but I found there's no standard for dts name to have or not have vendor name...
<MoeIcenowy> For example, there're "qcom-apq8064-asus-nexus7-flo.dts", "qcom-msm8974-sony-xperia-honami.dts", but we all know Nexus7 Gen2 is produced by Asus, and Xperia is the trademark of Sony
<wens> every platform has different rules
<wens> rockchip has a bunch of chromebook codenames
<MoeIcenowy> I think in the sunxi platform
<MoeIcenowy> provide the vendor's name is a good idea
<MoeIcenowy> sometimes devices' vendor name are not easy to find out
<wens> for sunxi, if it's a popular, well known series, then the vendor is left out
vagrantc has quit [Quit: leaving]
<wens> or if the vendor is unknown
<MoeIcenowy> wens: for example bpi?
<wens> MoeIcenowy: cubieboards
<MoeIcenowy> But I think some famous vendor's not-so-famous products should also contain vendor name
<MoeIcenowy> for example MSI Primo 81 (Although MSI is stripped out now
<wens> probably
<MoeIcenowy> (Here's also an A31s tablet's dts by me to submit
<MoeIcenowy> (It's vendored by Viewsonic
<wens> as mripard said, it's too late to change them
<MoeIcenowy> The model number is ViewPad 133Q
<MoeIcenowy> I think if I stripped "Viewsonic" out none will know it's a product by Viewsonic
<MoeIcenowy> (But I'm still waiting for proper A31 dual-role OTG code to be merged, then I will submit the dt
<TheLinuxBug> KotCzarny: finally testing Orange Pi Plus 2E in Debian, have compiled smplayer for a player with OSD and it runs pretty smooth, about to test out 1080p to see if we freeze and I need to tune.
matthias_bgg has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 240 seconds]
apritzel1 has joined #linux-sunxi
<wens> mripard: i wanted to rename sun8i-h3-sinovoip-bpi-m2-plus.dts since it was just added for 4.8
Shirasaka-Hazumi has quit [Ping timeout: 246 seconds]
Shirasaka-Hazumi has joined #linux-sunxi
jrg has quit [Ping timeout: 272 seconds]
yann|work has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<russell--> apritzel: i'm about to kick off a native build of your a64-v5 branch on a pine64+, is that likely to build/boot?
ricardocrudo has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
<apritzel1> russell--: yes, that should work
<apritzel1> I suggest you start with defconfig
<russell--> yes, just did that
kaspter has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
<apritzel1> it should be more robust now against changed .configs, though, but you should do the first try with defconfig
<russell--> what is the build time likely to be? /me is about to go to sleep (also making sure the batteries in the smoke alarm are fresh!)
kaspter has joined #linux-sunxi
jrg has joined #linux-sunxi
<apritzel1> russell--: tbh, I never tried a native _kernel_ build, it probably takes ages
<apritzel1> do you *run* the a64-v5 kernel?
<apritzel1> then you wouldn't need to care about the smoke alarm, but can have a much longer rest ;-)
<apritzel1> because it runs at 816MHz and I measured 3MB/s for the SD performance
<akaWolf> apritzel1: what is the current status of DRM at A64?
<wens> none?
<apritzel1> akaWolf: what do mean with DRM? Linux graphics?
<akaWolf> yeah
<MoeIcenowy> I remembered a driver is worked out for disp2
<MoeIcenowy> but it do not support HDMI
<apritzel1> as wens said: kind of non existing with the mainline stack atm
<apritzel1> though some bits and pieces should the very similar to the H3
<apritzel1> *be*
<russell--> apritzel1: i should have some information for you tomorrow ;-)
<apritzel1> MoeIcenowy: right, thanks for the link
<akaWolf> yeah, thta's H3
<apritzel1> akaWolf: so you may enjoy a virtual framebuffer ;-)
<MoeIcenowy> enjoy a virtual framebuffer :-)
<MoeIcenowy> maybe you can try a SPI-connected FBTFT L-)
<MoeIcenowy> :=)
<MoeIcenowy> :-)
<apritzel1> akaWolf: as far as we know, the DE2 is the same between A64 and H3
<apritzel1> though HDMI seems to be a bit different
Andy-D__ has joined #linux-sunxi
IgorPec has quit [Ping timeout: 272 seconds]
Andy-D_ has quit [Ping timeout: 250 seconds]
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<montjoie> akaWolf: you can check the wonderfull matrix at http://linux-sunxi.org/Linux_mainlining_effort for DRM you can see WIP
<montjoie> apritzel1: mripard for the feature matrix, do you think adding border color for visual "same IP block" could be usefull ?
<mripard> I'm not sure what you mean
<mripard> same IP block is dark green
apritzel1 is now known as apritzel
cptG_ has joined #linux-sunxi
<montjoie> mripard: we dont have the information "same with what ?"
<montjoie> so for example make a black border color between emac for h3/a64
<montjoie> when possible
cptG has quit [Ping timeout: 250 seconds]
<akaWolf> montjoie: I saw, thanks, WIP isnt very describe something
<mripard> montjoie: then instead of "?", simply put the name of the SoC it shares the block with
<apritzel> montjoie: that would require to cleverly group the SoC rows, which eventually is a NP-complete problem? ;-)
<MoeIcenowy> If I want to buy a Pine64
enrico_ has joined #linux-sunxi
<MoeIcenowy> Should I buy the MIPI DSI screen now?
<MoeIcenowy> apritzel: although it's NP-complete, the dataset is very small to be dealt even with human's brain
popolon has joined #linux-sunxi
SMDhome has quit [Ping timeout: 240 seconds]
SMDhome has joined #linux-sunxi
<apritzel> MoeIcenowy: agreed, I just procrastinated to the graph coloring Wikipedia page ;-)
<apritzel> MoeIcenowy: if you want to do the enablement ;-) Seems to be "sold out" atm, though
<MoeIcenowy> is there any document for A64's HDMI?
enrico__ has joined #linux-sunxi
<wens> not in manual 1.0
<apritzel> MoeIcenowy: jemk should know
enrico_ has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 252 seconds]
gzamboni has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
IgorPec116 has joined #linux-sunxi
leio_ is now known as leio
Da_Coynul has joined #linux-sunxi
IgorPec116 has quit [Quit: Nettalk6 - www.ntalk.de]
dantob has joined #linux-sunxi
aballier has quit [Ping timeout: 240 seconds]
aballier has joined #linux-sunxi
* jonkerj should probably ask this megi, but maybe someone can point me in the right direction..
Andy-D_ has joined #linux-sunxi
<jonkerj> I'm trying megi's THS patches on Opi+, which should be the same as OpiPC
<jonkerj> most of the stuff work, including the sy8106a regulator (it seems)
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jonkerj> but when I enable the 'CPU operating points' (see [1]), the kernel crashes/panics on an assertion in CFQ schedular
<jonkerj> it dies with "kernel BUG at block/cfq-iosched.c:1479", which seems to have something to do with the number of items in the cf-queue
<jonkerj> seems kind of random and unrelated to me, but kernel works without that DT block, and dies with exact same message with that block
<jonkerj> I'm a bit lost on how to approach this
Andy-D__ has quit [Ping timeout: 250 seconds]
<jonkerj> the boards have the regulator tied to the same r_twi bus (S_TWI) at the same address (0x65), the rest is H3 internal so should not be board specific
apritzel has quit [Read error: Connection reset by peer]
aballier has quit [Quit: leaving]
aballier has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Client Quit]
formruga has quit [Quit: Konversation terminated!]
Mr__Anderson has quit [Ping timeout: 258 seconds]
dantob has quit [Ping timeout: 246 seconds]
apritzel has joined #linux-sunxi
<MoeIcenowy> jonkerj: I met the same problem on A33
<MoeIcenowy> @wens this may be the issue
<MoeIcenowy> (I have no accessible UART except MicroSD breakout
<jonkerj> it really puzzles me, since I do not see any connection between those kernel areas
<MoeIcenowy> jonkerj: so do I
<mripard> MoeIcenowy: again, that @nick syntax doesn't work on IRC
<mripard> jonkerj: do you have the full logs?
<jonkerj> not sure what you mean by that
<mripard> (and the scheduler is tied to cpufreq)
<mripard> you say it dies with a message
<mripard> do you have the rest of the logs around that message
<jonkerj> yeah, let me put that on a gist, one moment
ssvb has quit [Remote host closed the connection]
<jonkerj> hmm, this is new, it does not die anymore
<jonkerj> I've enabled USB/OTG in the meanwhile
<jonkerj> spam:
<jonkerj> [ 3.385350] WARNING: CPU: 3 PID: 168 at drivers/clk/clk-divider.c:130 divider_recalc_rate+0x90/0xa4
<jonkerj> [ 3.385356] ths: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set
<jonkerj> and it just lives on
popolon has quit [Ping timeout: 246 seconds]
<jonkerj> I'm going to try and crash it, let me revert USB/OTG
<mripard> again, context :)
<jonkerj> there is really nothing related around that message, but I'll put the whole dmesg online
Worf has joined #linux-sunxi
<jonkerj> mripard: this is THS failing not very hard (context of my last messages): https://gist.github.com/jonkerj/4e942797d1e96e55d208257b1d9ec3b1
<jonkerj> I get it to crash again, but the message is different now: https://gist.github.com/jonkerj/8aade0b3a61ca669023a81df9054f28d
<jonkerj> I'll try to reproduce the (previously reproducable) CFQ bug
<mripard> it can be entirely random too.
<jonkerj> yeah
<jonkerj> it is
<MoeIcenowy> maybe I should also debug my A33 cpufreq issue
<mripard> that's bad
<MoeIcenowy> I tried to add cpufreq support to A33
<MoeIcenowy> but got a random freeze
<jonkerj> when I reboot without changing kernel/dtb, it dies with a similar but different address/hexdump
<jonkerj> I'll repeat a few times
<jonkerj> it is very very random
<jonkerj> sometimes I'm able to log in
<jonkerj> sometimes it dies with the paging request
<jonkerj> kernel BUG at mm/slub.c
<jonkerj> etc
<MoeIcenowy> jonkerj: maybe your issue is connected to mine
<mripard> welcome to cpufreq debugging
<jonkerj> could be
<MoeIcenowy> mripard: cpufreq debugging is full of traps?
<mripard> no
<jonkerj> feels to be that something very central (clock?) becomes unstable, wrecking a bunch of other stuff
<mripard> but it can generate random bugs
<mripard> clock or OPP
<jonkerj> could also be that the voltage regulation does not work, and the cpu is underpowered, thus unstable
<mripard> if the frequency is set too high compared to the voltage, it can generate various issues
<jonkerj> that
<mripard> such as this ones
<jonkerj> when I'm at home with some spare time, I'll try if I can verify this theory with a multimeter/scope
<jonkerj> good news is that my board has a test point for this
<jonkerj> tnx, mripard, you may have put me on the right thought train :-)
Worf has quit [Quit: Konversation terminated!]
popolon has joined #linux-sunxi
IgorPec116 has joined #linux-sunxi
IgorPec117 has joined #linux-sunxi
IgorPec118 has joined #linux-sunxi
IgorPec116 has quit [Ping timeout: 272 seconds]
IgorPec117 has quit [Ping timeout: 276 seconds]
IgorPec118 has quit [Ping timeout: 272 seconds]
IgorPec has quit [Ping timeout: 244 seconds]
<_stephan> just in case somebody wants to apply the rtc patch before the rtc maintainers react: http://pastebin.com/raw/0VKy9kFn
engideavr has quit [Quit: Konversation terminated!]
_stephan has quit [Quit: Ex-Chat]
nove has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
Andy-D__ has joined #linux-sunxi
Amit_t_ has joined #linux-sunxi
Andy-D_ has quit [Ping timeout: 264 seconds]
<montjoie> _stephan, you need to explain the udelay(100)
<montjoie> why 100 and not 50. perhaps a write/read memory barrier could repalce it
paulk-nyan-big has joined #linux-sunxi
fire219 has joined #linux-sunxi
afaerber has joined #linux-sunxi
<montjoie> and uint32_t must be replaced by u32
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
mkyr has joined #linux-sunxi
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
<mkyr> Hello,
<mkyr> I am building OpenWRT for orange pi pc plus,
<mkyr> and I have a orange pi pc
<mkyr> should it work on my device ? Do you have any idea ?
<mkyr> Because I simply could not boot the device using produced image.
<GeneralStupid> whats a "orange pi pc plus"?
<mkyr> H3 based board.
<GeneralStupid> nothing new? you meant orange pi plus?
<mkyr> :) I guess so
<mkyr> I have a orange pi pc
<mkyr> nothing new.
<mkyr> orange pi pc plus -> suppose to be -> orange pi plus
<GeneralStupid> The OpenWRT OS should boot on both (maybe without ethernet)
<cnxsoft> Pi PC Plus is another model based on Pi PC with 8GB eMMC and WiFi
<GeneralStupid> but you have to change the FEX file (bootloader)
Andy-D_ has joined #linux-sunxi
<mkyr> Actually I have kept the bootloader once and switched only the kernel(uImage) inside the SD. But it did not worked also.
<mkyr> I am new in this booting process o linux :S
<mkyr> I mean I have used a SD card with fully working OpenWRT image in it.
<mkyr> Changed the uImage but it did not work with the kernel that I have built for orange pi plus. But with different uImage (I mean other than in the original SD card) it did work.
SMDhome has quit [Ping timeout: 264 seconds]
Andy-D__ has quit [Ping timeout: 260 seconds]
mkyr has quit [Quit: Leaving]
ssvb has joined #linux-sunxi
<KotCzarny> daily chunk of wtf: https://support.microsoft.com/en-us/kb/3053711
<GeneralStupid> oh hes gone -.-
stephan has joined #linux-sunxi
<stephan> montjoie, I took the udelay from the linux-sunxi 3.4 driver. I'm not sure, if this is an hardware issue.
cnxsoft has quit [Quit: cnxsoft]
<stephan> meaning it might take some time for the status bit to update
stephan is now known as _stephan
<_stephan> I mean, memory barriers only prevent reordering. I assumed, the delay was a constraint from the actual piece of hardware.
<apritzel> _stephan: basing assumptions on AW code is not really a good idea ;-)
<_stephan> :D
mkyr has joined #linux-sunxi
<apritzel> _stephan: what is SUNXI_LOSC_CTRL_EXT_GSM1?
<apritzel> in the A64 and the H3 manual I see that the GSM0 and GSM1 bits must be the same
<apritzel> so either 00 or 11, but not 01 or 10
<_stephan> apritzel, in the A20 manual they seem to be allowed both
<apritzel> mmh, my copy has _nothing_ next to 01 and 10
dantob has joined #linux-sunxi
<_stephan> I'll look at it again
dearfibonacci has quit [Quit: Leaving]
<_stephan> document version 1.3 on page 127
<_stephan> it allows 11, 10, 01, 00... 00 being low, 11 being high...
<_stephan> I also took that 10 from 3.4 code, for I know it worked :)
<_stephan> err, 1.0
<apritzel> well, that's what I meant: 10 is not really documented
<apritzel> what is the patch actually trying to solve?
<_stephan> okay, I read that as "00 is low, 01 is a bit higher, 10 even more higher, 11 the highest"
<_stephan> apritzel, it switches the clock source to a 32.768 KHz crystal
<_stephan> because the 32.000 KHz crystal made the RTC go to slow
<_stephan> had a drift of about 90 seconds per hour, which is fixed now
<apritzel> what does GSM actually mean in this context?
<_stephan> I couldn't find that out either, it's named like that in the manual
<apritzel> does every board have an external 32K OSC?
<apritzel> if not, this has to go into the DT node as a property
<_stephan> external in this context means outside the module inside the chip
<_stephan> it's not on the board
<_stephan> but inside the SoC
mossroy has joined #linux-sunxi
<_stephan> I assume it's the crystal in the upper left corner of the diagram in subsection 1.5.2
aballier has quit [Ping timeout: 260 seconds]
aballier has joined #linux-sunxi
aballier has joined #linux-sunxi
paulk-nyan-big has quit [Ping timeout: 258 seconds]
<apritzel> are you sure about that being on the SoC?
<apritzel> AFAIK crystals are hard to integrate
<_stephan> I'll have another look
<_stephan> it's an olinuxino-a20-lime
<apritzel> that's why many SoC revert to having an inaccurate RC oscillator on-die
<apritzel> the Pine64 schematics shows me an external 32K crystal
<apritzel> also there are pins in the SoC data sheet for that
<mripard> there's both
<mripard> one internal, one external
<mripard> that switch is about which one you choose
<_stephan> ah, damn, found it... Q2...
<apritzel> I think that's the whole idea of that register: to allow running without an external crystal
<apritzel> mripard: right, but the external one is optional
<apritzel> so a board maker could just drop it
<mripard> not really
<mripard> the datasheet says the SoC requires both
<mripard> the 24M and 32k crystals
<apritzel> mripard: ah, OK, so then it's mandatory
<mripard> (at least on the A20)
reinforce has quit [Quit: Leaving.]
<_stephan> and rtc-sunxi is limited to sun4i and sun7i
<_stephan> so, A10 and A20
<_stephan> it's the same wording in both datasheets
<apritzel> I wonder why anyone would choose the internal oscillator then, they even say in the doc that it's "+/- 20%"
clonak has quit [Ping timeout: 240 seconds]
<_stephan> apritzel, I guess they bought the IP core and didn't change it's defaults
<mripard> apritzel: so that you can shut down the external one ?
<mripard> I don't know, are you really trying to make sense of an hardware engineer decision ? :)
<_stephan> some hardware engineers make good decisions... let's replace that with allwinner hardware engineers :)
<_stephan> and I'm pretty sure, most integrated peripherals are bought IP cores or opencores...
<_stephan> rather glued together
paulk-nyan-big has joined #linux-sunxi
clonak has joined #linux-sunxi
<_stephan> but I'll check if a memory barrier will do instead of the udelay when I'm back in office tomorrow
<apritzel> so that affects the other RTCs as well (sun6i), AFAICT
<apritzel> _stephan: writel has a memory barrier already
<_stephan> ok... so I'll try without the udelay...
<apritzel> yeah, may just be AW snake oil
<_stephan> maybe snake oil, but it made sense to me... though of course a good idea to try without
<apritzel> like some other delay operation (I think in the U-Boot DRAM init), which the compiler actually optimized out ;-)
<_stephan> okay, thanks for the feedback. I'll check that tomorrow in office.
_stephan has quit [Quit: Ex-Chat]
<wens> GeneralStupid: orange pi pc plus is orange pi pc + rtl8189 wifi, same form factor
<wens> apritzel: we share the rtc driver over all the soc variants iirc
<apritzel> wens: but there is rtc_sun6i.c and rtc_sunxi.c, at least
<apritzel> I just checked _sun6i (which is used for the A64), and the LOSC ctrl reg is only read there
<apritzel> so it defaults to the internal oscillator
IgorPec has joined #linux-sunxi
<wens> apritzel: i remembered wrong
<apritzel> I dimly remember seeing the RTC begin quite off after a day, but had more important things to worry about then ...
<wens> my boards are always on, and the ones that aren't don't have rtc backup batteries :(
<wens> no wonder i never noticed
<russell--> apritzel: make -j4 Image took ~35 minutes
<apritzel> russell--: mmh, not too bad
<apritzel> 1GB RAM?
<russell--> 2GB
<apritzel> still a different figure compared to the 2 minutes cross compile I usually deal with ;-)
<russell--> lol, make -j4 modules went much faster ... i ran out of disk space after 2 minutes ... /me was wondering if it was going to fit in 8GB uSD.
<TheLinuxBug> KotCzarny: so what am I missing here, I can't get full screen 720p or 1080p to work on my Orange Pi Plus 2E w/ Armbian which has vdpau support. I can do it in small windows but as soon as I full screen it just starts jerking around and half loading.. :(
Netlynx has joined #linux-sunxi
<apritzel> russell--: which config? defconfig doesn't have many modules ...
reinforce has joined #linux-sunxi
<TheLinuxBug> KotCzarny: interesting just found something I didn't expect - while smplayer use mpv (compiled with vdpau support) it seems it has issues providing full screen for it. While mpv direct seems to not have this issue with 720p/1080p hmmmm
<TheLinuxBug> ahhhhhh figured it out
<TheLinuxBug> (doh)
IgorPec has quit [Ping timeout: 252 seconds]
<TheLinuxBug> somehow had old smplayer binary in the way
<wens> seems like exporting a syscon/regmap is not as easy as i thought :(
<TheLinuxBug> while I thought I remvoed it I guess I didn't
<TheLinuxBug> removing manually and make install on compiled version and things work
cosm has quit [Ping timeout: 240 seconds]
paulk-nyan-big has quit [Ping timeout: 258 seconds]
<aalm> hmmph, should running "sunxi-fel spl u-boot-sunxi-with-spl.bin" load the spl at 0x10000 on A64? with "sunxi-fel uboot .." i do get into u-boot, but that's not exactly what i'm after atm., as if it wouldnt return to FEL after having ran the spl..
<apritzel> aalm: try: sunxi-fel spl sunxi-spl.bin
<apritzel> (or whatever this file from the spl/ directory is exactly called
<apritzel> your file is far too big for the 32K A1 SRAM
<NiteHawk> iirc, the "spl" command should load only the SPL portion into SRAM - it's smart enough to know about those combined images. nevertheless the U-Boot portion is just dead weight, it won't get used anyway
dantob has quit [Quit: dantob]
<NiteHawk> the difference is that "spl" won't attempt to jump to the u-boot entry point - while "uboot" will
<aalm> ok, that sunxi-spl.bin was only 24kb and it loaded ok, ran too i guess; "Trying to boot from FEL" was the last line on uart
<aalm> after that it didn't reply to version anymore, so i guess it didn't get back to fel successfully
<aalm> does that make any sense?
<apritzel> don't know if that's supposed to work, I have other writes and a final reset64 at the end
<apritzel> that works for me
<apritzel> which branch is that?
<aalm> yours, pine64-spl
<apritzel> can't test that atm, will try later
<aalm> ok, i'll try to live w/the sdcard for now
gzamboni has joined #linux-sunxi
<apritzel> aalm: what do you want to do?
<apritzel> if not loading U-Boot?
jernej has joined #linux-sunxi
<aalm> load&exec my kernel
<ssvb> aalm: presumably not a Linux kernel, but some other OS?
<aalm> openbsd
<ssvb> does openbsd support PSCI?
<aalm> nope
<wens> updated a10 and added a20/a31 to the support matrix
IgorPec118 has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
<apritzel> wens: nice, thanks for that!
IgorPec118 has quit [Ping timeout: 272 seconds]
<apritzel> as PSCI is kind of mandatory for ARMv8 machines ...
<aalm> heh, i was actually just looking at it
<apritzel> aalm: you can't boot an OS directly like this
<apritzel> I guess
<aalm> for running in aarch32 too?
<apritzel> what about the DT? Isn't FreeBSD using it as well?
<aalm> DT as in device tree?
<apritzel> yes
<aalm> supported, hardly used as is atm. on anything but imx6
<ssvb> btw, is FreeBSD, OpenBSD, NetBSD and other *BSD the same thing?
<apritzel> but anyway FreeBSD should be loadable by U-Boot, no?
<aalm> no
<jmcneill> completely different
<apritzel> ssvb: they were about 1991 or so ;-)
<aalm> apritzel, sure, atleast their ubldr is
<jmcneill> on armv8 freebsd tends to prefer loader.efi over ubldr
<aalm> ic
<aalm> openbsd went for efi loader too
<apritzel> aalm: upstream U-Boot should support EFI loading
<aalm> (obv. on armv7)
<ssvb> then you probably want the whole U-Boot, not just the SPL?
<apritzel> ssvb: I think he is after a _32_ bit FreeBSD ...
<aalm> no, 32bit openbsd
<apritzel> aalm: whatever ;-)
<TheLinuxBug> sweet finally have orange Pi Plus 2E running full 1080p offload to vdpau and working without freezing
vagrantc has joined #linux-sunxi
<jmcneill> on a lot of the netbsd armv7 ports they just load the kernel directly from u-boot
<apritzel> I think one can hack the Pine64 U-Boot defconfig to build as a 32-bit binary
<apritzel> and then change one line in ATF to drop in AArch32
<aalm> i've rewritten the bootstrap code for my own kernel so many times by now that i know i don't need u-boot for anything but loading the kernel
<apritzel> ... and possibly a lot of other hacks are needed ;-)
<apritzel> aalm: ah, wait, the SPL code tries to load a uImage with U-Boot
<aalm> yeah
<ssvb> aalm: U-Boot allows to load your kernel from a huge variety of possible storage media
<aalm> at 0x4a000000 or so
<apritzel> so you may try to wrap your kernel with mkimage
<apritzel> that is the U-Boot load address
<jmcneill> there's a BSD licensed version of mkimage in NetBSD if you need to import something
BenG83 has joined #linux-sunxi
<apritzel> ssvb: he is after FEL, I guess because of heavy try and error approach ;-)
<aalm> apritzel, that's the nail i'm aiming at :)
<apritzel> so my advice: try to disguise your kernel as U-Boot, also make sure that the DT is baked in (if that's needed)
<aalm> ok, will try that
<wens> also updated a33 and added a23
<wens> and my eyes hurt
<aalm> i've hardcoded pretty much everything so far, so DT would just bring in the board specifics like model and so :p
<apritzel> wens: thanks for also putting version numbers in!
<apritzel> aalm: makes sense for an initial hack
keh has quit [Quit: Wee... Chat]
Mr__Anderson has quit [Remote host closed the connection]
vagrantc has quit [Ping timeout: 276 seconds]
<montjoie> I love colors!!
lemonzest has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
apritzel has quit [Ping timeout: 244 seconds]
OverCR has joined #linux-sunxi
<buZz> yay colors :P
<buZz> montjoie: why the expression? :)
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
IgorPec has joined #linux-sunxi
popolon has quit [Ping timeout: 258 seconds]
matthias_bgg has quit [Ping timeout: 246 seconds]
vickycq- has quit [Ping timeout: 264 seconds]
vickycq- has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
mnr has joined #linux-sunxi
dantob has joined #linux-sunxi
popolon has joined #linux-sunxi
Amit_t_ has quit [Quit: Page closed]
ricardocrudo has quit [Remote host closed the connection]
dantob has left #linux-sunxi ["Good Bye"]
<KotCzarny> TheLinuxBug: :)
<TheLinuxBug> KotCzarny: that smplayer I mentioned above to IgorPec is the ticket
<TheLinuxBug> now if only I can get a version of kodi to work and source mpv as video player
<TheLinuxBug> could be half useful
<KotCzarny> i havent gathered myself to work on my desktopy pi
<KotCzarny> buZz: maybe he saw mainlining status matrix for the first time
<KotCzarny> btw. what is battery interface named in that table? is it there at all?
yann|work has quit [Ping timeout: 276 seconds]
<rellla> I like this status matrix. Green is beautiful!
afaerber has quit [Quit: Ex-Chat]
<montjoie> and for valentine day, we can replace all by small to big pink heart according to love(work) for each
<KotCzarny> pink might mean 'works, with love'
IgorPec has quit [Ping timeout: 250 seconds]
yann|work has joined #linux-sunxi
afaerber has joined #linux-sunxi
apritzel has joined #linux-sunxi
cosm has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
zuikis has left #linux-sunxi [#linux-sunxi]
mosterta has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
aalm has quit [Ping timeout: 244 seconds]
Netlynx has quit [Quit: Leaving]
mossroy has quit [Quit: Quitte]
nove has quit [Quit: nove]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 246 seconds]
iamfrankenstein1 is now known as iamfrankenstein
OverCR has quit [Quit: Leaving.]
reinforce has quit [Quit: Leaving.]
BenG83 has quit [Quit: Leaving]
willmore has quit [Ping timeout: 240 seconds]
willmore has joined #linux-sunxi
willmore has quit [Max SendQ exceeded]
willmore has joined #linux-sunxi
xalius has joined #linux-sunxi
apritzel has joined #linux-sunxi
willmore has quit [Ping timeout: 276 seconds]
willmore has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
iamfrankenstein has quit [Quit: iamfrankenstein]
willmore has quit [Remote host closed the connection]
Andy-D_ is now known as Andy-D
<russell--> apritzel: my defconfig build of your a64-v5 branch on a pine64+ doesn't have an eth0 interface
Mr__Anderson has quit [Remote host closed the connection]
<apritzel> russell--: right, you have to manually enable the driver in the .config
<apritzel> this driver is still somewhat experimental, so I didn't dare to include it in the defconfig yet
<apritzel> russell--: it's CONFIG_SUN8I_EMAC
<russell--> apritzel: when i built the driver as a module, i got this:
<russell--> Jul 06 20:29:49 alarm kernel: Generic PHY 1c30000.ethernet:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=1c30000.ethernet:01, irq=-1)
<russell--> Jul 06 20:29:49 alarm kernel: sun8i-emac 1c30000.ethernet: EMAC reset timeout
<apritzel> mmh, never tried a module build
<apritzel> can't you just quickly reco... oh wait, native build ;-)
<russell--> it's actually pretty fast, considering
<russell--> i'll try building it in
fire219 has quit [Read error: Connection reset by peer]
<apritzel> I take it that Ethernet worked before for you? so you are using my firmware image, which enables the PHY power supply?
<russell--> it works on the archlinux image i'm using with 3.10.65-7-pine64-longsleep
<apritzel> russell--: that's a totally different story
<apritzel> so how do you boot? From a longsleep based image and that U-Boot?
<russell--> apritzel: yeah
<russell--> i get the same message with the ethernet driver built in
<apritzel> Yeah, you need my firmware image, which enables the PHY power in ATF
<apritzel> I think the BSP driver does this itself
<russell--> what is ATF?
<apritzel> ARM Trusted Firmware
<russell--> where do i find your boot infrastructure?
<apritzel> the instructions are outdated (will fix this ASAP)
<apritzel> just grab images/pine64_firmware-20160601.img.xz
<apritzel> then xzcat <filename> | dd of=/dev/sdx bs=512k
<apritzel> (which nukes your SD card)
Da_Coynul has joined #linux-sunxi
<russell--> apritzel: can i use my own rootfs?
<apritzel> sure
<apritzel> actually you have to ;-)
<apritzel> you can use any arm64 rootfs, can copy one from another image
<apritzel> just the firmware and kernel are different
<russell--> okay, cool
<apritzel> the whole BSP firmware and kernel stack is so broken that I can't be bothered with providing compatibility with that
* russell-- is a newbie to sunxi, i'm used to openwrt/lede and building my own images, just getting oriented
<apritzel> you can rebuild the firmware part, if you like: https://gist.github.com/apritzel/68941c29c77955f1daa45b50d36c5425
<apritzel> that will be part of the new README shortly
<russell--> nice, thanks!
aalm has joined #linux-sunxi
fire219 has joined #linux-sunxi
Nacho_ has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Nacho has quit [Ping timeout: 276 seconds]
Da_Coynul has joined #linux-sunxi
uwe_ has quit [Ping timeout: 260 seconds]
uwe_ has joined #linux-sunxi
mosterta has quit [Ping timeout: 244 seconds]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mnr has quit [Quit: leaving]
jernej has quit [Ping timeout: 244 seconds]
<lennyraposo> hey ssvb
<lennyraposo> or apritzel