<_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 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
<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'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.
<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