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
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
hulu1522 has quit [Ping timeout: 260 seconds]
a|3x has joined #linux-sunxi
bwarff has joined #linux-sunxi
khuey is now known as khuey|away
solarnetone has quit [Ping timeout: 276 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-sunxi
[Awaxx] has quit [Quit: "There is a *owl*"]
[Awaxx] has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hulu1522 has joined #linux-sunxi
hulu1522 has quit [Remote host closed the connection]
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1_ has joined #linux-sunxi
solarnetone has joined #linux-sunxi
abruanese has joined #linux-sunxi
<cyrozap> My Orange Pi PC isn't booting Linux (Armbian, from SD card) any more... U-Boot works fine, but the process hangs at "ion_reserve_common"--or at least it appears that way, since the Ethernet port LEDs do blink a few times. I've tried getting Linux to print its kernel messages, but it doesn't want to (which it was doing from the beginning). fsck reports no errors with the filesystem, so I'm not sure
<cyrozap> what could be going wrong or how I can even begin to debug without Kernel output.
<cyrozap> I suppose I could just reflash, but then I wouldn't learn anything.
<cyrozap> Ah, ok, I got verbose boot now.
<cyrozap> Oh, lol
<cyrozap> [ **] A start job is running for LSB: Raise network interf...37s / no limit)
<cyrozap> ...
* cyrozap pops the SD card into his laptop to edit /etc/network/interfaces
IgorPec has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
mossroy has joined #linux-sunxi
JohnDoe0 has joined #linux-sunxi
zuikis has joined #linux-sunxi
p1u3sch1_ has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has quit [Ping timeout: 268 seconds]
p1u3sch1 has joined #linux-sunxi
libv_ is now known as libv
bwarff_ has joined #linux-sunxi
bwarff has quit [Read error: Connection reset by peer]
bwarff__ has joined #linux-sunxi
bwarff_ has quit [Read error: Connection reset by peer]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
zuikis has left #linux-sunxi [#linux-sunxi]
kaspter has joined #linux-sunxi
scream has joined #linux-sunxi
Netlynx has joined #linux-sunxi
reinforce has joined #linux-sunxi
SadSmile has joined #linux-sunxi
apritzel has joined #linux-sunxi
SMDhome has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 244 seconds]
apritzel has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 244 seconds]
cnxsoft has quit [Quit: cnxsoft]
apritzel has joined #linux-sunxi
jernej has joined #linux-sunxi
nove has joined #linux-sunxi
scream has quit [Remote host closed the connection]
clonak has quit [Ping timeout: 240 seconds]
clonak has joined #linux-sunxi
al1o has quit [Ping timeout: 276 seconds]
al1o has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
SadSmile has quit [Quit: Leaving]
robogoat has quit [Ping timeout: 268 seconds]
jstein has joined #linux-sunxi
prasannatsm has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
<willmore> nove, that's cool. That $100 model looks nice. I hope they're hackable. I'd like some internal GPIO that I could tie stuff to. :)
<longsleep> $100 laptops, the screen is most certainly crap
<longsleep> haha also if i look at the pictures, the remix os launcher takes 2/3 of the screen height already - i really do not see the use case
<Wizzup> the olimex laptops will be very hackable
<Wizzup> They have stated that themselves as well
<buZz> longsleep: looked pretty good in the video
<buZz> its >200ppi res
<buZz> i'd call that sufficient
<longsleep> mhm, ok lets hope for be best
<buZz> Wizzup: i'm gonna get a Pyra :)
* buZz quite sure
<buZz> unless some more impressive wannabe-pda comes along
<longsleep> anyone knows about DBG_871X_LEVEL macro, looking to disable it without chaning too much or disabling debugging as a whole
<Wizzup> buZz: what is the price range?
<buZz> ~500 euro
<buZz> about half a neo900
<buZz> for 2-3x better specs
<Wizzup> (n900 specs are good enough for me, I don't game on those things)
<buZz> i dont game whatsoever
<Wizzup> the n900 is a good enough pda for me :)
<buZz> but i do like a processor more recent than 10 years old ;)
* Wizzup shrugs
<buZz> ^_^
tkaiser has joined #linux-sunxi
apritzel has joined #linux-sunxi
<tkaiser> buZz: The 11.6" screen has 135 ppi resolution and with 14.1" it gets even worse.
<Wizzup> are there even specs released on the olimex laptop?
<buZz> 135?
<buZz> how is that possible
* buZz mathes
<buZz> oh wow
<buZz> yeh 135.09 PPI
<buZz> same on olimex
<longsleep> urg - thats what i feared
<buZz> the 14.x has higher res i think
<buZz> hmm he said it in the video
<buZz> oh same res
<buZz> well, for seniors
<buZz> so they dont need reading glasses ;)
<buZz> thats what i tell the young kids with 6" phones
<buZz> 'you know, you can just get glasses if you have trouble reading'
<longsleep> seniors also cannot scroll and with that size it is a total scroll party
<buZz> they dont like that ;)
vishnup has joined #linux-sunxi
<longsleep> it might be good for a single terminal though :P
<tkaiser> Both A64 and A83T have max. LVDS resolution of 1366x768
vishnu_ has joined #linux-sunxi
vishnup has quit [Ping timeout: 252 seconds]
<vishnu_> jemk: any update on A80 SPL support?
vishnu_ has quit [Ping timeout: 244 seconds]
apritzel has quit [Ping timeout: 244 seconds]
vishnu_ has joined #linux-sunxi
vishnu_ has quit [Ping timeout: 250 seconds]
vishnu_ has joined #linux-sunxi
<willmore> My 14" laptop is 1366x768 and it's fine.
<willmore> The hard decision would be A64 vs A83T. Fewer 64 bit cores or more 32 bit cores....
cnxsoft has joined #linux-sunxi
vishnu_ has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Client Quit]
bwarff__ has quit [Ping timeout: 252 seconds]
vishnu_ has joined #linux-sunxi
vishnu_ has quit [Ping timeout: 268 seconds]
prasannatsm has quit [Ping timeout: 250 seconds]
paulk-collins has joined #linux-sunxi
<tkaiser> willmore: My 13" laptop is 2560x1600 and that's ok-ish ;)
<tkaiser> willmore: And why do people think about octacore CPUs when it's about laptop/desktop usage?
<longsleep> tkaiser: yes - my 13" laptop has 2560x1700 and i cannot use any other laptop any more :/
zuikis has joined #linux-sunxi
<longsleep> anyone knows about possible reasons for WARNING kernel traces in clk_disable like http://paste.ubuntu.com/16006646/
<longsleep> or how to find out which clock it actually is
apritzel has joined #linux-sunxi
<willmore> tkaiser, I can use lots of cores with what I do.
<willmore> Maybe I'm just getting old, but 1366x768 at 14" is just fine. Maybe I don't sit close enough. :)
vishnup has joined #linux-sunxi
<apritzel> montjoie: are you around? I am playing with your driver on the Pine64 ...
<apritzel> longsleep: you should add printks to clk.c, maybe replacing the WARN_ONs there, adding more information
<apritzel> montjoie: I badly hacked the a20-gmac clock to set bit 13 as well for the time being
lamer14614296952 has joined #linux-sunxi
<apritzel> montjoie: the driver seems to initialize, but bringing the interface up leads to a timeout in SOFT_RST
<apritzel> montjoie: seeing your commented readl_poll_timeout() there I wonder if you have seen issues with this before?
tkaiser has quit [Ping timeout: 250 seconds]
<longsleep> apritzel: yeah i did that, it is the audiocodec driver, made it a module for now as i do not care about it much :)
<longsleep> apritzel: btw, someone just opened up a issue on your kernel tree at my build gear tracker - https://github.com/longsleep/build-pine64-image/issues/15
<longsleep> apritzel: i can close it, with or without referring to you whatever you prefer
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
prasannatsm has joined #linux-sunxi
al1o has quit [Ping timeout: 260 seconds]
al1o has joined #linux-sunxi
<apritzel> longsleep: do you refer to any of my trees? I know of the ATF one, any others?
lamer14614296952 has quit [Ping timeout: 268 seconds]
<apritzel> btw: commented on the tracker
<longsleep> apritzel: uhm, yes in the Kernel README https://github.com/longsleep/build-pine64-image/blob/master/kernel/README.md
<longsleep> apritzel: i should probably update the section.
<apritzel> yeah, MMC works as well for quite some time
<apritzel> and I pushed a v4 yesterday, based on 4.6-rc4
<longsleep> apritzel: do you have a usable defconfig as well now?
<longsleep> updating the file now
<wens> jemk: i have an a80-pmic u-boot branch which has axp809 stuff, though not tested
lamer14614296952 has joined #linux-sunxi
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<apritzel> longsleep: yes, the arm64 "make defconfig" should enable everything you need
lamer14614296952 has quit [Client Quit]
<longsleep> apritzel: ok great will update that as well
<montjoie> apritzel: no the comment is just for replace it
tkaiser has joined #linux-sunxi
<montjoie> apritzel: each time someone speak about SOFT_RST, it was a missing regulator
<apritzel> montjoie: too bad, that means that apparently by default the PMIC does not power the PHY :-(
<apritzel> I was hoping that we get away without programming the PMIC, which I currently cannot access
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<apritzel> montjoie: OK, will push my arm64 warning fixes and the Pine64 .dts bits anyway, so people can play with it
IgorPec has joined #linux-sunxi
<jemk> vishnup: a80 spl is advancing slowly, it boots (to u-boot), but the dram code is buggy
<jemk> a real memtest fails after some seconds (which is true for boot0 too...)
<jemk> wens: thanks, i'll try it, currently i only set dcdc5
vishnup has quit [Ping timeout: 268 seconds]
<montjoie> apritzel: does "ethernet led" fire up when powering it ?
doppo has quit [Ping timeout: 250 seconds]
doppo has joined #linux-sunxi
<apritzel> montjoie: no, no LEDs at all
<apritzel> though I am wondering how a missing PHY regulator should prevent the MAC reset
ricardocrudo has joined #linux-sunxi
tkaiser has quit [Ping timeout: 276 seconds]
jbrown is now known as |jbrown|
|jbrown| is now known as jbrown
<longsleep> Pine64 pulseaudio sndhdmi fix: sudo sed -i 's/load-module module-udev-detect$/& tsched=0/g' /etc/pulse/default.pa
tipo has quit [Remote host closed the connection]
tkaiser has joined #linux-sunxi
<tkaiser> longsleep: And next week the same again based on kernel 3.18.x?
<longsleep> tkaiser: no, i am pretty happy with the current state and will certainly not work on any "newer" bsp kernel. Also i think there is none, i guess they still will use 3.10 for Android 6
<apritzel> montjoie: or does the MAC itself require some special regulator, for talking to the PHY via MDIO, for instance?
<longsleep> tkaiser: if they should release a new BSP i might pick ethernet updates (if there are any).
<apritzel> longsleep: does Gigabit Ethernet work now with the BSP kernel?
<tkaiser> longsleep: TL Lim spoke about 'BSP 2.0' and lenny mentioned 3.18 IIRC. In case there will be a newer kernel situation for Pine64 backers might get even more worse.
<longsleep> apritzel: yes
<tkaiser> apritzel: Yes, it does
<longsleep> tkaiser: i doubt they will release a newer kernel, the newer stuff is already in remix OS and that is 3.10
<apritzel> yeah, 3.18 BSP sounds like a very bad thing
<longsleep> apritzel: iGigabit worked with the very first BSP release, it was just some dts property delays which needed to change
<tkaiser> apritzel: longsleep: Pine64 'FAQ': 3.18 and later 4.2 ;)
<longsleep> tkaiser: well, dreams?
<KotCzarny> and later 'abandoned'
<apritzel> tkaiser: I remember that weird announcement ...
<longsleep> tkaiser: afaik BSP 2.0 means Android 6.0 with Kernel 3.10
<tkaiser> longsleep: Sure, there's no need to think about the relevance of any of the bits of 'information' shared by the Pine64 folks. I've never seen such a mess. They're even worse than SinoVoip at the moment regarding state of documentation (and that's kind of impossible)
<longsleep> yeah, but its only a 3 man shop or something
<KotCzarny> hw men
<apritzel> to be fair, that sounded like copied from Allwinner
<tkaiser> longsleep: True, but since we already wrote documentation, they could just take this. And warn people that for example Ethernet has to be disconnected on 1st boot when using Android/RemixOS
<apritzel> and Pine people took it for granted, not seeing that "Linux" means "Android with bash" for them
<longsleep> tkaiser: sure, but i guess they have bigger problems than documentation
<tkaiser> apritzel: Sure, that they not exactly knew what's happening in the beginning is one thing. The other how to deal with the current situation.
<KotCzarny> also, i think they are busy packaging shipments
<KotCzarny> so no time for all this sw mumbo jumbo
<tkaiser> KotCzarny: They spend time on featuring the wrong OS images, they spend time on answering the same questions again and again. There are better ways to deal with this. And if they do packaging themselves then there's something really wrong ;)
<longsleep> they should hire a serious linux developer if they would be interested in improving things. But i guess they cannot afford it yet - maybe never
<KotCzarny> hiring == 'losing' money
prasannatsm has quit [Quit: prasannatsm]
<KotCzarny> would 1000bucks get them mainline?
<KotCzarny> sure, if they had docks themselves
<KotCzarny> s/docks/docs/
<longsleep> they should have made the thing twice the price, no charge for shipping, then they would have plenty to hire software developers. But after KS ists easy to say :)
<KotCzarny> longsleep, and 1/4 of backers ;)
<longsleep> KotCzarny: good thing as well
<longsleep> KotCzarny: sales would have come with good software automatically after KS and the price could even be higher
<KotCzarny> anyway, i think no one just gets anything meaningful from allwinner themselves
<tkaiser> And it wouldn't help that much. Software for this combination (this hardware with these target audience) is hard to support. All the 'stability issues' in the forums are most likely related to powering problems (Micro USB -- as expected) or crappy SD cards.
<KotCzarny> longsleep, you are forgetting they would just lose to any other a64 board that would just 'steal' the images/sw
<montjoie> apritzel: for some opi, without regulator, it have the same symptom (rst timeout). But i dont know what do the regulator
<longsleep> KotCzarny: mhm right, but hey they just need to make their hardware better than 'any other' - easy win :)
prasannatsm has joined #linux-sunxi
prasannatsm has left #linux-sunxi [#linux-sunxi]
avph has quit [Ping timeout: 250 seconds]
<KotCzarny> not so easy, easy win is doing misleading marketing
<longsleep> KotCzarny: well, are there any 'good' A64 based boards?
<KotCzarny> olimex is experimenting with one
<KotCzarny> and i believe they are a bit better at hw design
<longsleep> well, i guess we will see how it goes
<tkaiser> KotCzarny: 2 boards, and Xunlong has also something in the works (H64)
<longsleep> i certainly hope those boards are smaller and have a heat sink
<KotCzarny> anyway, i think it's the allwinner that should be coerced into supporting open source drivers
<tkaiser> KotCzarny: Why should they? They look at Android and RemixOS. IMO that was the most interesting part in this '$100 laptop video': How Allwinners positions A83T and A64.
<KotCzarny> tkaiser: more sales?
avph has joined #linux-sunxi
<tkaiser> Of course, they sell thousand times more devices with Android than Linux.
<KotCzarny> sbc market is something many people would like
<KotCzarny> right now most htpc boxes are x86 based
<tkaiser> In the beginning of the video in the background. They see a A83T 2in1 solution as a competitor of iPad Pro and Google's Pixel C. Running RemixOS
<longsleep> lol
<longsleep> Pixel C is so nice - seriously?
<longsleep> I think they will never be able to compete with that
<KotCzarny> longsleep: price?
<tkaiser> longsleep: Yeah. My reaction as well. But maybe marketing for morons does work. If it's cheap some people will buy even if it's that bad that you can't do any serious work with it
<longsleep> KotCzarny: sure they can make it cheaper, but this is high end we are talking
<tkaiser> And people buy numbers. 'Octa core'!
<KotCzarny> :)
<KotCzarny> for a transcoder box multicore isnt that bad
<longsleep> KotCzarny: pixel C is around 600 EUR without keyboard
<KotCzarny> 600eur > 100usd
<longsleep> KotCzarny: Keyboard is another 200 EUR :)
<KotCzarny> and what tkaiser said
<KotCzarny> price is a reason enough to convince clueless people
<KotCzarny> and a little marketing as a sugar coating
<tkaiser> In a tablet or 2in1 solutions a SoC with a powerful GPU would be more useful. In this sense A31/A31s has been twice as powerful as A83T. But the target audience won't get it that GPU cores are more important than count of CPU cores.
<longsleep> mhm look at the nvidia shields, that might be a suitable competition
<longsleep> i think pixel c is way out of range
<KotCzarny> another nice thing about multicore is throwing interrupts around
<tkaiser> longsleep: Did you watched the video regarding the cheap A64 laptops and this 2in1 thingie? Display from hell (way too glossy)
<longsleep> tkaiser: yes
<longsleep> i mean its 2016, crap displays need to die if you ask me
<KotCzarny> longsleep: big res needs cpu/gpu power
<longsleep> unfortunately most people do not even know until they have seen a good screen
<KotCzarny> and mem bandwidth
<longsleep> true
<KotCzarny> so it's not going to happen in case of allwinner
<longsleep> but its not all about resolution, its also about colors, reflection, view angle
<KotCzarny> right. death to TN
<longsleep> i mean for me as developer, i cannot even imaggine to work on a screen where i cannot have 9 terminals in the default window size visible - and that works on my 13" notebook
<KotCzarny> he he he
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
<tkaiser> longsleep: macbookpro-tk:~ tk$ osascript -e 'tell app "Terminal" to get count of windows'
<tkaiser> --> 9
<tkaiser> ;)
<longsleep> of course hidpi screens use more battery, but still beeing used to a screen larger than 1080p - there is no way back
<KotCzarny> unless you are shortsighted
<KotCzarny> then it's different game
<longsleep> tkaiser: i do not us mac OS
<longsleep> tkaiser: using a Chromebook Pixel with Xenial/Unity
<longsleep> KotCzarny: sure, but even then, just change the hidpi ratio and suddenly big fonts look awesome
<tkaiser> longsleep: I'm used to OS X since that's what also 101% of customers use ;)
<longsleep> tkaiser: well, i am sure that a heavily customized OS X works well, but from version to version it sucks more if you ask me :)
<longsleep> tkaiser: also, how do you handle security, disk encryption and such?
<lvrp16> ne1 try the xenial yet?
<lvrp16> canonical confuses me...zfs???
<lvrp16> btrfs is so good already
<longsleep> lvrp16: zfs is actually really nice and not really to be compared with btrfs
<longsleep> we will see how it goes with the zfs license issue though
<KotCzarny> (ooooo) <- here is your ram
<KotCzarny> (.) <- here is your ram on zfs
<tkaiser> longsleep: Not that easy, important stuff remains on a FreeBSD based NAS (ZFS).
<tkaiser> KotCzarny: Wrong, you're repeating stuff from 2009. Unless you do dedup ZFS and RAM are pretty fine
<longsleep> tkaiser: hehe, ok but what do you do in a plane?
<tkaiser> longsleep: In planes and trains I do not that important stuff. ;)
<KotCzarny> tkaiser: just kidding, dont take it too seriously
<tkaiser> KotCzarny: I'm a ZFS fanboi! No kidding please! ;)
<longsleep> everyone would be a ZFS fanboy if the license wouldnt suck
<lvrp16> i like btrfs better
<tkaiser> longsleep: BTW: Having to rely on HFS+ is one of the most annoying things when using OS X ;)
<longsleep> i can imagine, i have used macs in the past but not with OS X
<lvrp16> but then again i don't raid much
<longsleep> lvrp16: its not about raid, its about storage for VMs, snapshots and high availability
<longsleep> lvrp16: zfs with lxd really rules hard
<lvrp16> snapshots btrfs does just as well, idk what you mean by "storage for VMs" and high availability via raid?
<tkaiser> longsleep: You can't compare MacOS and OS X at all. Two different beasts. And OS X has some nice features (and also some powerful proprietary frameworks we use all the time)
jstein_ has joined #linux-sunxi
<lvrp16> i don't see the difference between btrfs and zfs for containers
<lvrp16> if you take out the raid bits
<lvrp16> snapshots - same, copy-on-write cloning - same, continuous integrity checking against data corruption -ssame, automatic repair - same, efficient data compression- same
<longsleep> lvrp16: sure, it is about scaling - what good is a file system which is gone when a single disk dies
jstein has quit [Ping timeout: 240 seconds]
<longsleep> lvrp16: and zfs is very well tested for many years (on solaris)
<lvrp16> i thought thats what ceph, hdfs, etc were for
jernej has quit [Quit: Konversation terminated!]
<longsleep> lvrp16: they all have their problems and are not suitable for production use
<longsleep> lvrp16: ceph might be eventually as they now seem to have understood the latency issue
jernej has joined #linux-sunxi
ssvb_ has quit [Quit: Leaving]
ssvb has joined #linux-sunxi
<ssvb> jemk: regarding "a real memtest fails after some seconds (which is true for boot0 too...)", what kind of memtest is that?
<ssvb> jemk: also a80 still has the mixer processor (g2d), which has roughly the same effect on reproducing memory reliability problems as mali when g2d is doing 90 degrees rotation in the background
tkaiser has quit [Ping timeout: 244 seconds]
<ssvb> jemk: A31/A80 can use g2d for stressing DRAM, A13/A23/A33/H3/A64 can use mali, A10/A20 can use either of these options
<lvrp16> tkaiser: thanks for the link
<jemk> ssvb: i'm using the builtin self test of the dram phy for now, pretty fast at detecting problems, but since sits after the controller it doesn't detect problems there
<ssvb> jemk: have you tried just reducing the DRAM clock frequency a bit?
tkaiser has joined #linux-sunxi
<jemk> ssvb: 504mhz it passes, but above it fails
<jemk> i found quite a lot of potential problems in the dram setup (not only a80), but haven't had time to further investigate it
<jemk> h3 for example doesn't do regular zq short calibrations
<ssvb> jemk: a10/a13/a20 don't do zq short calibrations either, enabling short calibrations was making the reliability worse in my tests
<jemk> hm, ok
<ssvb> I could see the zq value changing at runtime, but the reliability test were failing at much lower clock frequencies
<jemk> i only noticed that my h3 works at 768mhz if it is warm at initial zq cal, if its cold there and gets warm later it only gets to 696
<ssvb> probably the accuracy of short calibrations was not good enough
<ssvb> but I suspect that even the long calibration at the dram init is probably doing more harm than good on a10/a13/a20
<ssvb> jemk: regarding the cold start differences - https://linux-sunxi.org/User:Ssvb/Cubietruck_DRAM_Calibration
<ssvb> so in the end, it's probably better to disable ZQ calibration and instead use some static ZDATA settings selected for each board
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
jstein_ has quit [Remote host closed the connection]
<jemk> ssvb: the first two pcduiono zdatas have minimal differences but still produce noticeable different results
<jemk> pull up and pull down output impedance is different by 1, rest is same
<ssvb> jemk: who knows, if it's a difference between /2 or /3 divisor, then even the off-by-one difference is pretty significant
Netlynx has quit [Quit: Leaving]
jstein has joined #linux-sunxi
<ssvb> jelle: but what we have in practice is that it's probably safer to use hardcoded settings than relying on the calibration result at boot time
<ssvb> ^ oops, I mean jemk
IgorPec has quit [Ping timeout: 252 seconds]
<ssvb> jemk: simply because the static hardcoded settings can be tested with more or less reproducible results, while the calibrated settings depend on the SoC temperature at boot time and are poorly predictable
<jemk> ssvb: true, thats why there is zq short cal ;)
<ssvb> jemk: right, if it works fine on h3
<jemk> ssvb: it doesn't work at all on h3
<ssvb> hmm
<ssvb> anyway, on a10/a13/a20 it's best to avoid any kind of automatic zq calibration altogether
<jemk> its turned off, and when turned on it only does it on ddr chip side, not on soc side
<ssvb> how do you know that it's really done on the ddr chip side?
<ssvb> did you get any measurable effect?
<jemk> measure the voltage at the zq resistor
<ssvb> ok
avph has quit [Ping timeout: 250 seconds]
cptG_ has joined #linux-sunxi
cptG has quit [Ping timeout: 250 seconds]
avph has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
mosterta has joined #linux-sunxi
<ssvb> jemk: moreover, here are test results from 4 pcduino boards (with nanya dram instead of hynix) - https://linux-sunxi.org/User:Ssvb/pcDuino2_with_NANYA_DDR3
<ssvb> jemk: they are pretty different from the same board, but with hynix dram - https://linux-sunxi.org/User:Ssvb/pcDuino2_with_HYNIX_DDR3_reliability_test
VargaD has quit [Ping timeout: 244 seconds]
<ssvb> jemk: OLIMEX also complained that they had dram reliability issues after changing the dram vendor for the later revisions of their boards
VargaD has joined #linux-sunxi
<ssvb> jemk: I suspect, that different dram chips may be just sampling data with different delays, something like having different tpr3 settings on the soc side
<ssvb> jemk: so while the dram traces routing and the impedance related setup is the same, the differences are still possible if you change the dram vendor
<ssvb> jemk: my four pcduino2 boards with nanya dram chips can work reliable at 480mhz dram clock speed (and using hardcoded zdata instead of calibration), but these settings are bad for the same pcduino2 board with the hynix dram
<ssvb> jemk: so in practice, the u-boot defconfig for pcduino is using 360mhz dram clock speed as a safe default :-)
<ssvb> jemk: we can't really trust the user here and assume that the user would pick the right defconfig if we were to provide separate configs
<jemk> ssvb: no, we can't, but if the controller isn't complete garbage it should be able to calibrate that
<jemk> ssvb: did you only hardcode the zdata, or something else to
<jemk> o
<ssvb> the hardcoded zdata is more predictable, so it's much easier to tune when adjusting settings on 4 boards simultaneously
<ssvb> and it looks like the differences between different units (the nanya boards) are smaller than the random differences introduced by the zq calibration
valkyr1e has quit [Quit: Bye.]
<jemk> ssvb: jfyi, the zdata values can be converted with the same mgray_to_bin tables as h3 to normal numbers, these numbers have a 1/x relation to the impedance
<ssvb> jemk: can you make some U-Boot branch with the hardcoded zdata values, which are good for 768mhz on your orange pi plus board?
<ssvb> jemk: it would be interesting to test it on my opipc board
zuikis has left #linux-sunxi [#linux-sunxi]
valkyr1e has joined #linux-sunxi
<jemk> ssvb: could be worth a try, but since pc uses 1.35V vs 1.5V on the plus it might fail horribly
<ssvb> jemk: hmm, aren't there exactly the same dram chips in pc and plus?
nove has quit [Quit: nove]
<ssvb> jemk: from what I read, the 1.35V ddr3 chips are just binned samples, but still can work with the 1.5V voltage perfectly fine
<jemk> ssvb: they are the same ddr3l chips on both, but plus uses them as normal ddr3
<jemk> i already thought about changing the resistor at the voltage regulator to try 1.35, but they are so small
pmattern has joined #linux-sunxi
<ssvb> as for the test, I just wonder if I can get higher dram clock speed passing the lima-memester check with the hardcoded zq calibration results, borrowed from your board
<ssvb> if yes, then the zq calibration accuracy is probably crap in h3
jernej has quit [Quit: Konversation terminated!]
pietrushnic`away is now known as pietrushnic
<jemk> ssvb: i have a lot of additional code from experimenting, but uncommented its pretty worthless
<jemk> ssvb: i really would like to improve the dram code, but i already invested too much time for this again today, I should do other things
hulu1522 has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 268 seconds]
iamfrankenstein1 is now known as iamfrankenstein
tsuggs has quit [Ping timeout: 276 seconds]
tsuggs has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
iamfrankenstein has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
mossroy has quit [Quit: Quitte]
hulu1522 has quit [Remote host closed the connection]
paulk-collins has quit [Quit: Leaving]
<ssvb> jemk: thanks, your patch looks quite promising, failed the 720MHz test on my Orange Pi PC, but still running at 696MHz
<ssvb> jemk: when doing real ZQ calibration, 696MHz was failing very fast, so it already looks like a progress
<ssvb> plaes: ^
* willmore find ZQ calibration issues fascinating
* willmore is a ham and likes transmission line theory, Z0, complex impedances, line termination, etc.
mozzwald has quit [Ping timeout: 244 seconds]
yann|work has quit [Remote host closed the connection]
mozzwald has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<ssvb> jemk: failed at 696MHz too, but still it took much longer
<ssvb> jemk: about the periodic short zq calibration - http://irclog.whitequark.org/linux-sunxi/2014-07-18#9648028;
<ssvb> jemk: sorry, I did not document the details in the wiki because it looked like a dead end
<ssvb> jemk: still, now I remember that one of the ideas was that probably burst refresh settings might affect the short ZQ calibration is some way
<ssvb> jemk: this did not help on A10/A20, but wonder what might be the reason why H3 did not want to do the re-calibration at the SoC side in your tests?
<ssvb> willmore: indeed, and in the case of the DRAM controller setup we get some interesting experimental data
ricardocrudo has quit [Ping timeout: 250 seconds]
pmattern has quit [Quit: Genug für heute.]
gzamboni has quit [Read error: Connection reset by peer]
bwarff__ has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 260 seconds]
tomboy64 has joined #linux-sunxi