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
<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)
<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
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>
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
<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]