<slunatecq>
Hi - I have bananapi M1 archlinux installed. I just tryed to compile kernel by this guide http://forum.lemaker.org/forum.php?mod=viewthread&tid=22694&extra=page%3D1 when I did makepkg -o, it said==> ERROR: linux-armv7 is not available for the 'armv6h' architecture. lscpi gives me Architecture: armv7l. Why does makepkg thinks I have armv6h
<slunatecq>
architecture?
<KotCzarny>
disregard lameker forums, go armbian
<slunatecq>
Even though I have archlinux?
<tkaiser>
slunatecq: Why do you want to fiddle around with kernel 3.4 anyway?
<slunatecq>
tkaiser: I want newer kernel so I can run docker
<tkaiser>
Oops, ok, you're trying it with mainline already
apritzel has joined #linux-sunxi
<slunatecq>
tkaiser: That is a bad thing?
ninolein has joined #linux-sunxi
<KotCzarny>
slunatecq: you are better off grabbing armbian kernel and compiling it
<KotCzarny>
even if you want to stick with archlinux
<KotCzarny>
as for compiling itself, you can try compiling on device itself, but it could be long ~40-80minutes
<slunatecq>
armbian kernel says "Kernel 3.4.110 for Allwinner A20" that means I will get 3.4 kernel don't it?
<KotCzarny>
there is also mainline kernel for a20
<KotCzarny>
but vanilla compiles/works too
<tkaiser>
Currently Armbian is at 4.6.3 I believe. At least yesterday it was 4.6.3
<KotCzarny>
if you want .config for my bpi-m1 i can pastebin it
<KotCzarny>
tkaiser, are there any patches for mainline/a20 or just vanilla?
<tkaiser>
KotCzarny: I've lost track, at least with Banana Pro there were issues with SATA that require attention in both u-boot/kernel. No idea about M1. And hey, I use the build system since the knowledge is inside so I don't need to think too much
<slunatecq>
I am quite kernel-compile noob... Is there any step by step tutorial or something? I don't mind if compiling will take even few days...
<tkaiser>
slunatecq: Please try it here first: http://www.banana-pi.org/m1-download.html (these are the images that really do not work, those from LeMaker are just outdated)
<slunatecq>
I was there too, but theese are all 3.4 kernels too
<tkaiser>
I was kidding. All of the software there is crap anyway
aballier has quit [Read error: Connection reset by peer]
<Wizzup>
Has anyone used kexec on a10/a20?
<KotCzarny>
or jessie
<KotCzarny>
if you want plain debian
<KotCzarny>
but as i said, all you need is mainline uboot/kernel and just roll with any distro with armhf packages
<slunatecq>
And vanilla xenial has mainline uboot/kernel?
<slunatecq>
Oh - that is ubuntu - so jessie has mainline uboot/kernal?
<KotCzarny>
both
<KotCzarny>
and most likely legacy has mainline uboot/legacy kernel
<tkaiser>
slunatecq: All images use mainline u-boot, vanilla images use mainline kernel, the others not. You will save a lot of time by starting here: http://docs.armbian.com
<tkaiser>
BTW: Jessie armhf packages are compiled with more conservative settings compared to Xenial (due to their age) so you end up with an overall faster distro if you choose the newer one.
Putti has joined #linux-sunxi
<tkaiser>
If you care about stuff like that forget about Armbian and choose Gentoo instead :)
<slunatecq>
I was considering that, but I don't have the time to study all new system, nor to compile every single thing in it :-)
<slunatecq>
I liked arch, because I feel it like gentoo without compiling
<jonkerj>
I doubt if the ubuntu binaries will be notably faster
<jonkerj>
in theory they are, but in practice you won't notice the differences unless you are generating RSA keys all day
<Wizzup>
slunatecq: arch is very different from gentoo in many ways, it's not just 'compiling'
<slunatecq>
I know - but the idea of you have only what you want is similar
<tkaiser>
jonkerj: Or you calculate prime numbers. When you use sysbench on an armhf board with Xenial the board is 30 percent faster. And people around believe this without taking notice :)
<jonkerj>
yeah but those benches are extremities, day to day/real life is a total different matter
<jonkerj>
I'de choose based upon ease of use, unless I really really need that performance
<slunatecq>
anyway - thank you guys for your help - to be honest, I hope I will never see you, because I will have no further problems :)
<jonkerj>
good luck
<tkaiser>
jonkerj: On a RPi 2 or 3 switching from Raspbian to Ubuntu gives you 12.5%. Apart from that I agree, the differences in performance do not matter.
dearfibonacci has quit [Read error: Connection reset by peer]
<jonkerj>
does anyone know about a (off the shelve, preferably cheap ebay) CSI breakout board/cable?
<jonkerj>
the SPDIF-out (PA17) on H3 is hardwired to the CSI port on my orange pi's, and I'd like to work on sun4i-spdif to get it working on H3
<jonkerj>
mechanics/electronics are dead simple, but does not seem available yet
<jonkerj>
spoke too soon, there appear to be DSI breakouts, should be good enough
<tuxillo>
agraf: I wanted to follow up on yesterday's topic about built-in rpi3 pxe boot
<agraf>
tuxillo: yes? :)
<tuxillo>
agraf: you mentioned you can pxe boot to UEFI and then load a kernel from there
<tuxillo>
is there any documentation about it?
foxx_ has quit [Remote host closed the connection]
foxx_ has joined #linux-sunxi
Putti has quit [Ping timeout: 255 seconds]
<agraf>
tuxillo: not to uEFI, you can pxe boot to u-boot which implements uEFI interfaces
<agraf>
tuxillo: if you build a recent version of u-boot for the rpi3, it has support the uefi pxe boot
<agraf>
tuxillo: so you just run it and it will try to run the file you pass it as efi binary
<_mamalala>
jonkerj: it's the same 24 pin, 0.5mm pitch FPC connector, right?
<jonkerj>
should be
<_mamalala>
since i'm going to make some boards to test stuff in a few weeks, i might as well make a little adapter boards, with a 24 pin fpc connector routed to a regular 24 pin 0.1" header
<_mamalala>
making pcb's in china is dead cheap nowdays, thnaks to itead and seeed and such
<_mamalala>
might be useful for others as well, given that the pins on the cam connector can be used as gpio as well
<jonkerj>
indeed
tlwoerner has joined #linux-sunxi
<_mamalala>
the fpc connectors are cheap on aliexpress, 3,70 euros for 20 pcs.
<_mamalala>
short fpc cables are way more expensive, 6,87 for 10 pcs. 24 pin and 40mm length :P
<jonkerj>
I just buy now'd a board+cable from UK for ~ukp 7 shipped
<jonkerj>
bit expensive
<tuxillo>
agraf: okay, I will be trying to do that. the instructions for rpi3 are similar to the ones for rpi2? I need to start it in aarch64 mode
<agraf>
tuxillo: aarch64 mode only means you need to set arm_mode to 0x200 or so
<apritzel>
miasma: good point, I guess this should be relaxed a bit
<apritzel>
or be more fine grained, as in: boots with a UART, works headless, supports framebuffer, ....
<miasma>
there's already the other table with color codes, which is a bit more informative
<miasma>
but this lists the specs
<apritzel>
I guess by the high standard of linux-sunxi no board will ever have a "yes" in this table ;-)
<miasma>
my idea was, what if you had both tables, the SoC based color coded table, and this one on the same page
<miasma>
since the support thing is probably more tied to SoCs, not boards
<miasma>
that would make this column a bit obsolete
<apritzel>
well, some summary would be good, which could be "WIP", for instance, but being a link to the SoC support table having the details
<miasma>
I guess mediawiki doesn't support embedding pages in other pages?
<miasma>
like symbolic links, so that updates are propagated
<miasma>
maybe i'll ask a wikipedia employee :)
<apritzel>
what's wrong with an old fashioned HTTP link?
<apritzel>
or Intra-Wiki link, for that matter?
<miasma>
nothing
<apritzel>
could use an anchor to scroll to the right table
<apritzel>
and the back button does what it's supposed to do, then
<apritzel>
otherwise the "List of Allwinner boards table" would be quite big and also off-topic
tkaiser has joined #linux-sunxi
<tkaiser>
longsleep: In any of the conversations with those Pine64 GbE negotiation victims... had any of them had a look at flow control settings?
Wizzup has quit [Ping timeout: 252 seconds]
Wizzup has joined #linux-sunxi
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
IgorPec has quit [Ping timeout: 260 seconds]
jstein has quit [Read error: Connection reset by peer]
cptG_ has joined #linux-sunxi
foxx_ has quit [Ping timeout: 240 seconds]
cptG has quit [Ping timeout: 265 seconds]
<mpmc>
Anyone here heard of a "QL300-EVB Qpixel Artesa Evaluation Board"? :p
<plaes>
nope
<plaes>
if it's not in wiki, it doesn't exist :)
Putti has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<KotCzarny>
miasma: those seagate smr drives are SLOW on writes
<KotCzarny>
very slow
foxx_ has joined #linux-sunxi
<KotCzarny>
which is good when you are building someserver/archive, but bad on frequent writes (even for backup purposes)
<miasma>
KotCzarny: yes true. i use one in a jukebox
vagrantc has joined #linux-sunxi
<KotCzarny>
as for mainlining support, it might be good idea to add single/double letter codes of what is supported, ie. B(oots)S(table)T(hermal)C(pufreq)A(udio)N(and)I(2c) etc
<KotCzarny>
or maybe add paragraphs on device pages and put a links to it
<KotCzarny>
andmaybe color code it gray(untested) black(doesnt work) red(some things work) yellow(most things work, but some essentialthings dont) green(almost everything works, some minor/niche things missing)
<KotCzarny>
and i agree, its more about soc, than boards themselves, unless anyone have an example where soc is supported but something important on board is not
<zoobab_>
@_mamalala I bought some fpc connector to expose it in 2.54 header
<_mamalala>
if one needs to put an adapter inbetween, to re-order the pins/signals, it can quickly become too long
<_mamalala>
plus, depending on how the lcd is driven, having too long cables can ruin the signal integrity
<_mamalala>
it's best to keep such things as short as possible
apritzel has joined #linux-sunxi
afaerber has joined #linux-sunxi
reinforce has joined #linux-sunxi
<zoobab_>
yeah, like jtag cables :-)
NiteHawk has quit [Remote host closed the connection]
NiteHawk has joined #linux-sunxi
NiteHawk has quit [Changing host]
NiteHawk has joined #linux-sunxi
afaerber has quit [Ping timeout: 250 seconds]
afaerber has joined #linux-sunxi
jernej has joined #linux-sunxi
Putti has quit [Ping timeout: 240 seconds]
<longsleep>
tkaiser: not that i am aware of
<tkaiser>
longsleep: Maybe that might be the culprit. One user in their forum (the only one so far) used a router with Linux based firmware and posted settings from both ends
<tkaiser>
longsleep: In case you want to further investigate or tell users what to do or where to look. I'm out of the game already since this MarkHaysHarris777 guy constantly deletes or edits my posts.
<longsleep>
tkaiser: oh really lol
<tkaiser>
longsleep: Yeah, i already got a few warnings that I shouldn't disturb their community via PM :)
<KotCzarny>
tkaiser, you are at fault too, because your writing style is aggressive ;)
<_mamalala>
i don't see anything aggressive about tkaiser's writing style .... annoyed, yes ...
<KotCzarny>
you didnt saw him in action yet ;)
<longsleep>
well i got blamed to be grumpy yesterday too :P
<KotCzarny>
but i agree that annoyed is still better than plain stupid and touchy
<KotCzarny>
which seems to be common on those pine64 forums
<_mamalala>
well, search a random forum(reddit thread with systemd as topic, and you can see what an aggressive posting style looks like :P
<KotCzarny>
systemd is evil and should die in a fire :P
<longsleep>
tkaiser: yeah i looked into that already but did not want to spend the time to port that over to the kernel driver ..
<_mamalala>
a big problem on many forums is that a lot of users are either unwilling or unable to grasp simple facts, even after it has been explained to them repeatedly
<tkaiser>
longsleep: But a few users that are not that clueless and are able to check both ends of the connection would be needed, especially some that not rely on voodoo
<_mamalala>
and so, at some point the beeing-all-nice-and-fluffy talk has to end and a more clear wording used to get it into their thick skulls, i think
<tkaiser>
longsleep: ok, then problems remain. And moderators can do their job preventing any progress again (like they did even months ago with all Ethernet problems)
<KotCzarny>
or just leave that ecosystem and go back to linux-sunxi which is more about real thing than fluffiness
<longsleep>
well i try to be nice without the fluffiness and to many extra words - its hard sometimes ..
<KotCzarny>
imo longsleep/tkaiser should pm pine64 creators directly with a list of what's wrong and do accordingly totheir reply. leave/stay
<tkaiser>
KotCzarny: Why again?
<longsleep>
well, no :)
<longsleep>
i stopped caring what they do a long time ago
<KotCzarny>
because why do you care about them in thefirst place?
<_mamalala>
thing is, if someone buys such sbc's, it is reasonable to expect from them to be able to understand technical issues up to a certain degree .... and if they can't do that, then they simply bought the wrong thing, imho
<longsleep>
well for me it was hoping to get useful feedback without having to find all the issues myself
<tkaiser>
KotCzarny: it's about the users. But since the pine64 folks also do not care about their users/customers it's useless anyway
<longsleep>
tkaiser: btw i am not convinced that mii-tool works correctly on Pine64
<_mamalala>
but then, the dunning-kruger effect is pretty strong on technology-leaning forums these days
<tkaiser>
_mamalala: Well, a few of the moderators of this specific forum are definitely members of team dunning-kruger. And unlike other SBC community pine64 recruited really clueless people with their marketing. So it
<tkaiser>
's not that easy there ;)
<_mamalala>
yea, i gathered that from skimming that forum
<KotCzarny>
why would non-technical people admin technical project? smells like manager material :>
<tkaiser>
longsleep: ok, then it gets really hard to find out what's going on without someone using a real sniffer in a location where the problem occurs
<_mamalala>
tkaiser: well, are you claiming that there exists people in marketing that actually have a clue? got any evidence for that? :P
<longsleep>
tkaiser: ethtool works fine though, but they still have not added flow control support to it have they?
<tkaiser>
_mamalala: I was referring to their kickstarter campaign. The supercomputer for $15 thing attracting all sorts of people that are not familiar with SBCs and Linux
<tkaiser>
longsleep: Nope
<_mamalala>
hehe, yes, i know ... sorry for making bad puns ;)
<_mamalala>
kickstarter and similar platforms are a cesspool of bollocks marketing blubber
<apritzel>
tkaiser: you mean to say that just being 64-bit does not qualify for a supercomputer?
<longsleep>
64-bit +2GB RAM!!!
<longsleep>
dont forget the RAM
<KotCzarny>
comparing to commodore 64, yes
<apritzel>
longsleep: right!
<_mamalala>
and mali!
<tkaiser>
apritzel: Running under full load at just 2.5W and does not exceed 32¡C!
<apritzel>
I admit, "supercomputer" is justified then ;-)
<KotCzarny>
also, remember it runs android, linux and air
<apritzel>
or maybe they forgot to mention that supercomputer referred to 1979 standards
<longsleep>
but - i think the Pine64 is really great, i replaced all my various Raspberry PIs with it, now running 3 Pines with LXD on Ubuntu 16.04 with LXD using ZFS with Gigabit Link. Thats so nice and almost qualifies as supercomputer if you comare it with ra RPi3 :)
<_mamalala>
i think that's a pretty general problem with these soc-based sbc's anyways ... there really isn't much to differentiate them, when it comes to specs, so the marketing clings to even the smallest, neglible advantage and blows it out of proportion
MiLeon has joined #linux-sunxi
<tkaiser>
longsleep: Let's see how situation with H5 looks like. I still hope that it's just a mixture of H3 and A64 so headless usage would benefit from the 3 real USB host ports. Mali450 my ass...
<KotCzarny>
right. decacore ftw!
<longsleep>
if i could boot from ZFS i would not even need any storage :)
<tkaiser>
longsleep: I sent my remaining Pine64 to forum user androsch. If my 940 Mbits/sec translate to 10 Mbits/sec there then it's just another confirmation...
<mripard>
wens: I don't think I did
<willmore>
I have a Pine64. Does someone need some testing done?
<tkaiser>
willmore: Yeah, does the Mali work?
<willmore>
tkaiser, as well as I expect it to.
<willmore>
;)
<KotCzarny>
it would be dream if someone wrote hashing/encryption code working in opengl
<KotCzarny>
or if malidrivers gained some cuda-like interface
<tkaiser>
KotCzarny: Still in supercomputer mood? GPGPU processing on a 8 years old GPU? You work in marketing?
<_mamalala>
KotCzarny: why would you try to abuse the gles core for encryption stuff, when the soc's have a unit that is there for that exact purpose (sunxi-ss)
<KotCzarny>
mmm, did you see decacore in h5leaflet?
<KotCzarny>
maybe they have a surprise for us! *dremmy*
<KotCzarny>
*dreamy*
<_mamalala>
for example on the h3, check section 4.15. in the datasheet, crypto engine
<tkaiser>
KotCzarny: maximum clock of all GPU cores 100 MHz to meet budget cooling requirements?
<KotCzarny>
_mamalala: because its slow (slower than cpu at least)
<_mamalala>
are you sure about that? i mean, i find it hard to believe that they spend die space to plop in a crypto engine, when they could do the same much faster on the existing core(s)
<_mamalala>
sure, for some special applications it may be faster to use the cores, due to parallelsim and stuff ... but in general?
<KotCzarny>
and of course new battery, but that's obvious for almost any device, even 'brand new unopened'montjoie's page yet
<willmore>
I was wondering why you describing montjoie as 'brand new unopened'.
<_mamalala>
KotCzarny: according to the tables there, in most cases it is faster to varying degrees ... however, i'm rather baffled that it becomes so incredibly slow as soon as dma is used ....
buZz has quit [Quit: ok maybe irssi restart then ;)]
buZz has joined #linux-sunxi
buZz is now known as Guest90783
utente_ has joined #linux-sunxi
IgorPec has joined #linux-sunxi
utente__ has quit [Ping timeout: 264 seconds]
ricardocrudo has quit [Remote host closed the connection]
netlynx has joined #linux-sunxi
<montjoie>
_mamalala: the crypto engine in A64/H3/A83t is slow for the moment (according to my latest test)
<montjoie>
the table are for sun4i-ss (A20 and co)
<_mamalala>
montjoie: ah, ok
sarietta has joined #linux-sunxi
BenG83 has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
book` has quit [Quit: Leaving]
apritzel has quit [Ping timeout: 244 seconds]
Mr__Anderson has quit [Remote host closed the connection]
<TheLinuxBug>
in the case where your board needs more you need to power by DC or GPIO
<TheLinuxBug>
to get full 2.xA
<TheLinuxBug>
thats why the Orang Pi boards for example all come with a DC jack also
<TheLinuxBug>
and same with Cubieboard products I do believe
<TheLinuxBug>
etc
<zoobab_>
well if you power via microUSB with a 2A charger, I think it will work out
<TheLinuxBug>
your not reading what I say
<TheLinuxBug>
USB spec only provide 1.8A on USB cord
<TheLinuxBug>
thats the spec
<zoobab_>
ah
<zoobab_>
1.8A
<TheLinuxBug>
therefore if your power requirements are past that, in most cases you will need DC/GPIO
<zoobab_>
and you might need 2A
<TheLinuxBug>
ya
<TheLinuxBug>
:)
<TheLinuxBug>
sorry not try to be mean, just make sure you understand :)
<zoobab_>
got it
<TheLinuxBug>
so in case of Pin64 to get full CPU etc you probably need full power through DC/GPIO otherwise it likely throttles cpu
<TheLinuxBug>
Pine64*
<zoobab_>
is it possible to disable this cpufreq?
<_mamalala>
otoh, hopefully they use more than one pin for the supply on the gpio header then, because almost all simple pinheaders are spec'd for 1A per pin ;)
<tkaiser>
zoobab_: Undervoltage is the real problem. 1.8A max just adds to it
<TheLinuxBug>
tkaiser: thanks for clarify :D
<tkaiser>
TheLinuxBug: It's not about throttling (related to temperature), it's about powering the board off immediately.
<TheLinuxBug>
!! ahh ok
<tkaiser>
You can use cpuburn-a53 to switch off any Pine64 when powered through Micro USB
<_mamalala>
(well, actually many _pin_ headers are rated for more than that, but the female headers to plug onto them are usually 1A)
<zoobab_>
@tkaiser maybe you could add a quick explanation about the 1.8A USB limit on the armbian/pine64 page
<tkaiser>
_mamalala: But there it works. The problem for the average user is also not the connector but that he uses crappy (read as: nearly all) USB cables
<zoobab_>
I discovered it now :-)
<_mamalala>
tkaiser: indeed ... not to mention the cheap power supplies
<zoobab_>
yeah I had problems with some cheap chinese usb cables
<zoobab_>
and I trust now Olimex which only ships with barrel connectors
<_mamalala>
fun test: hold a strong magnet to the cable itself ... nowdays, many cheap usb cables use copper clad steel instead of copper ... at least i have the "luck" of getting a lot of those crap things
<_mamalala>
that's what you will often find find in a cheap power cord ... the yellow/green piece in the picture is what a 1.5sqmm wire really looks like, rated for 16 amps
<_mamalala>
_many_ power cords that come with cheap pc supplies and stuff are like that, unfortunately
<tkaiser>
plaes: Sweet!! Those tiny wires!
<plaes>
and those colors :D
<zoobab_>
sometimes they don't even wire the ground :-)
<_mamalala>
they happily print/emboss all the required logos and stuff on there, plus a 16A rating ... but you better not try to actually use it for that :P
<_mamalala>
plaes: well, i don't mind the colours ... mains wiring color codes are different from country to country, and in ready-made cables it's not important anyways ... however, the severe lack of conductor cross section is really bad
<plaes>
this and colors :D
<_mamalala>
ah, you mean the conductor, not the insulation colour?
mosterta has quit [Ping timeout: 265 seconds]
<KotCzarny>
_mamalala:lol @ netzkabel1
<_mamalala>
KotCzarny: sadly, it's not really something to laugh about ... if someone were to use that cable with only a medium load, it would very likely start a fire
<KotCzarny>
true.
<_mamalala>
and the average user/customer has no way to check that the cross section is sufficient ....
<KotCzarny>
but seriously, i dont know if its safe for microusb :>
<_mamalala>
yea
<_mamalala>
you'll find a similar insulation-to-conductor ration in many cheap usb cables as well ... having only a few thin strands of something conductive in them
<_mamalala>
quite often steel or aluminium
<KotCzarny>
yah,i saw one usb cable with 4-5 tiny strands
<KotCzarny>
but it was for a mouse, so it was safe
tkaiser has joined #linux-sunxi
petr has quit [Remote host closed the connection]
petr has joined #linux-sunxi
sarietta has quit [Remote host closed the connection]
<_mamalala>
yea ... for a real thrill, just search for "usb power supply teardown" on youtube ... and see how the cheap firestarters look from the inside
<_mamalala>
the only somewhat safe use for most of them is as a doorstop
<KotCzarny>
my bpi-m1 runs on alcatel charger ;)
<KotCzarny>
but bpi-r1 and orange pis run on meanwell psu
<_mamalala>
good choice
<KotCzarny>
one of them is dual voltage (12V for hdd/monitor)
<_mamalala>
i wish a friend of mine would still work at the dsl provider he used to work at ....
<_mamalala>
tons of really god equipment for free, straight out of their electronics garbage pile
<KotCzarny>
:>
<KotCzarny>
oldie but goldie
<_mamalala>
funkwerk routers, etc ... and those beefy 48 volt supplies from old dslam's ... 2kW per pop
<_mamalala>
it's really a shame that the market is so flooded with crappy and hazardous power supplies these days
<_mamalala>
but then, people demand stuf to be as cheap as possible, so it's not really a big surprise, i guess
<KotCzarny>
i would bemore wondering why there are no fires running around
<_mamalala>
yea, that too ... i guess many fires don't get reported, and are catched by the residents early enough .... meaning they plug in that crap mostly when they are sitting next to it
<_mamalala>
plus, in all fairness, most of the time those cheap supplies just pop a capacitor and cease to function
<_mamalala>
whats way more worrying is the lack of proper isolation between primary and secondary side ... which can easily result having mains potential on the output plug
sarietta_ has joined #linux-sunxi
fdcx has quit [Ping timeout: 252 seconds]
mosterta has joined #linux-sunxi
MiLeon has quit [Quit: Leaving]
<zoobab_>
I bought some USB 220v psu for 1EUR on the flea market
Nacho has quit [Ping timeout: 240 seconds]
Nacho has joined #linux-sunxi
Guest90783 is now known as buZz
mosterta has quit [Ping timeout: 250 seconds]
netlynx has quit [Quit: Ex-Chat]
fdcx has joined #linux-sunxi
jmcneill has joined #linux-sunxi
<jmcneill>
Hi folks. Has anybody looked at A64 cpufreq? I wrote code to support it on FreeBSD but for some reason it takes nearly 4 seconds to switch to a higher clock rate.
<jmcneill>
It boots at 408, 408 -> 648 is fast. 648 -> 816 is slow and the pattern continues up to 1200.
<jmcneill>
Decreasing is fast too.
<_mamalala>
maybe some issues with pll settings, so it becomes unstable for a while ... or register settings applied in the wrong order? but then, i never looked much into that cpufreq stuff, and not at all for a64
<jmcneill>
I'm updating PLL_CPUX_CTRL_REG after increasing voltage. Maybe naive but the user manual doesn't really say that I need to do anything else, just that PLL_CPUX can be dynamically adjusted for DVFS.
<_mamalala>
at least on the h3 there are several registers to control the pll for the cores, a pll control register, a config register, a bias register and a pattern control register
<jmcneill>
I also tried switching CPUX to OSC24M before adjusting PLL_CPUX (and back to PLL_CPUX after the change) but it didn't seem to help.
<_mamalala>
yea, but iirc you need different bias settings as well ... at least that is what i gather from that stuff on the h3
<jmcneill>
oh interesting
Mr__Anderson has joined #linux-sunxi
<_mamalala>
you could check the pll lock status bit to see if it locks quickly or if it takes a lot of time ...
<jmcneill>
can you link me to the code for h3?
<_mamalala>
a quick hunch would be that the code doing the switchin may actually wait for that lock bit to come up before proceeding
<jmcneill>
I'm definitely not waiting for the lock bit.
<_mamalala>
if you look at the 3.4 sunxi kernel tree, the stuff is in drivers/cpufreq and drivers/clk/sunxi
<_mamalala>
and there was something about clocks/pll somewhere else, i think, trying to find that now
<_mamalala>
(in drivers/clk/sunxi the core specific stuff is in in the sun8iw7 files)
<jmcneill>
oh interesting it looks like it is updating the factors in multiple writes
<_mamalala>
the allwinner "datasheets" aren't that helpfull ... they merely list the registers, and with a lot of luck you may get some cryptic note about setting multiple bits for stuff like TMR ....
<jmcneill>
Painfully aware :/
<_mamalala>
so one has to always check the sources of whatever kernel code they provide to see how it may be done "right"
mosterta has joined #linux-sunxi
<_mamalala>
i'm pretty sure that there must be a more complete manual to their chips ... but probably in chinese .... but then, i wouldn't mind, because i'm sure that some folks would start to translate it piece by piece
sarietta_ has quit [Remote host closed the connection]
<jmcneill>
The incomplete manuals are a big help in understanding the bsp code.
<_mamalala>
true
<jmcneill>
I wish the new DE2.0 and HDMI transmitters were documented.
<jmcneill>
I did A20 and A31 drivers for those but they've dropped it all from the later user manuals.
IgorPec has quit [Ping timeout: 244 seconds]
<_mamalala>
well, for h3 there is at least some content in the datasheet for TCON, which does hdmi and lcd .... but the section for de2.0 is basically empty as well
<jmcneill>
there's still a separate hdmi transmitter isn't there?
<_mamalala>
otoh, chances are good that most stuff in the docs from other soc's will be the same ... they rarely completely change the ip blocks for such things between chips
<jmcneill>
that is fed fromt con
<_mamalala>
could be, dunno ... the block diagram just basically lists DE -> TCON -> HDMI/TV
foxx_ has quit [Ping timeout: 258 seconds]
<jmcneill>
that's how it works on a20/a31 at least
Andy-D has quit [Ping timeout: 276 seconds]
<plaes>
A33 display code was just submitted
<jmcneill>
and i didn't see any ddc interfaces on the new tcon
<_mamalala>
i simply fail to understand why they make such a big secreet out of that stuff, instead of just releasing a usable docu .... not just allwinner, but in general
<_mamalala>
no need to provide free tech-support ... but just release complete datasheets at least
|Jeroen| has quit [Ping timeout: 250 seconds]
<_mamalala>
oh, and having a way to set the gating frequency for gpio pins would be neat as well :P
<_mamalala>
some peripherials have such a config register, but gpio does not, unfortunately
<KotCzarny>
maybe they dont even have docs, just some scribbles passed from hw design person
<_mamalala>
the result is that if you do a sequence of gpio data register accesses, that whole sequence slows down to what the gpio is clocked at, which seems to be 1/10th of the ahb frequency, i.e. 30MHz maximum ...
<_mamalala>
KotCzarny: i somehow doubt that, given the fact they (and their larger customers) are able to implement that stuff, which requires some form of docu
<_mamalala>
but then, its possible, sure
<KotCzarny>
scribbles.
<_mamalala>
;)
Andy-D has joined #linux-sunxi
pg12 has quit [Ping timeout: 260 seconds]
pg12 has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
fire219 has joined #linux-sunxi
<jmcneill>
ok maybe it's the voltage switch that is taking time, not the cpu freq switch..
<_mamalala>
makes me wonder if they _legally_ integrated that stuff in their soc's
andor2007 has quit [Client Quit]
<ssvb>
_mamalala: considering that Synopsys DesignWare does not provide public documentation from their website (and one has to read TI, Rockchip and Freescale manuals), there might be some complicated confidentiality agreements between companies
<_mamalala>
ssvb: true, but then, given that "the cat is out of the bag" already, because there seems to be an open-source driver for the general thing, obfuscating register address bits seems really strange
<jmcneill>
ok i fixed the timing thing
<jmcneill>
(stupid me)
<jmcneill>
cpufreq changes are fast now
<_mamalala>
jmcneill: yay!
<jmcneill>
it was dumb
<ssvb>
_mamalala: well, it's none of my business, and I would prefer to just assume that AW is innocent until proven guilty rather than speculating about the worst :)
<_mamalala>
ssvb: fair enough
<jmcneill>
the freebsd regulator "set voltage" method has an 'int *udelay' param
<jmcneill>
uninitialized, and the regulator fwk was sleeping for whatever the value was after setting voltage
<_mamalala>
:P
<jmcneill>
this code would probably work for our other sunxi ports too
<jmcneill>
thanks for your help!
<_mamalala>
well, wasn't much of a help, just wild guessing
<jmcneill>
at least now I know who to bug when it's time to do h3 cpufreq :)
<_mamalala>
lol
<_mamalala>
just because i read the datasheet, and took some time to browse through the sunxi related kernel sources, doesn't mean i have a clue :P
sarietta has joined #linux-sunxi
<_mamalala>
and i did that mainly to see what i can do to get my own stuff working as i want it to work ... it just so happens that my main hobby and job is electronics, a lot of that with microcontrollers, and thus i read and peeked a bit further than really needed ;)
tsuggs has joined #linux-sunxi
<miasma>
anyone had issues with the build quality of orange pis?
<miasma>
my sd connector got loose when i pushed the card in. it was like after 2 weeks of use. i tried to solder it back but it won't work properly :F uboot might boot but then it can't find mmc
<_mamalala>
miasma: do you have a proper soldering station, and extra flux? that leadfree solder isn't that easy to touch up compared to leaded solder
<miasma>
apparently all the contact need to be soldered, even the ones on the sides that hold the connector. otherwise it won't boot
<miasma>
_mamalala: not a high quality station, but i'm worked with electronics as a hobby for years
<miasma>
*i've even
<miasma>
although i'm not that familiar soldering smd components
<_mamalala>
as far as such production issues go: that can always happen ...
<miasma>
yep
<miasma>
i decided to order few more
<_mamalala>
well, you need at least some flux ... otherwise you can forget any chance of decent rework
<miasma>
well basically the small pins didn't come loose
<miasma>
only the two on the sides
<miasma>
and they're quite large
<miasma>
but maybe there's a small fracture now. sometimes it boots to uboot, sometimes the whole kernel but hangs during init
<miasma>
I was thinking of moving the root to usb
sarietta has quit [Remote host closed the connection]
<_mamalala>
hmm, if you mean the lugs that are only holding the whole slot onto the pcb, that shouldn't have any effect, usually
<miasma>
also another issues with my banana pi m1+ a20 board, it randomly crashes with some memory fault error. I guess it's also dead
<_mamalala>
do you have a photo of the thing/area in question?
<miasma>
_mamalala: i can take. they actually have. the system doesn't detect the sd if they're loose
<_mamalala>
well ... could also be a faulty sd card by itself, or simply wrong settings for cpu and ram speed
<miasma>
i doubt that since it varies. if it reset it like 20 times in a row, it might or might not show uboot. i'm using the default settings
<_mamalala>
ok, if that is the case, that sounds more like the pins for the sd-detect switch in the socket ... but iirc they are usually quite small as well
apritzel has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
<_mamalala>
yea, well ... i don't have orangepi's, but nanopi's ... and if i set the cpu creq to 1200MHz in u-boot, i also get sporadic boot failures ... however, booting at 1008MHz and then setting 1200MHz in linux is rock stable
<miasma>
where do I set that? in the uboot's menuconfig?
<miasma>
ok i'll try that. gotta study more
<_mamalala>
yes
<_mamalala>
also, make sure you have a really good power supply and cable
<tkaiser>
_mamalala: As expected. Booting with 1200 Mhz @ 1.1V is asking for trouble ;)
<miasma>
_mamalala: i tested with a lab supply
<_mamalala>
tkaiser: :P
<_mamalala>
tkaiser: but mali should help with that, right? :P
<_mamalala>
i mean, we just need to integrate mali into u-boot, and all should be fine!
<_mamalala>
miasma: ah, ok
<miasma>
the other problem is the A20 board. it can work for like say 7 hours, then the kernel hangs. and it's not even under load. totally idle. it can even crash if the initramfs goes into rescue mode so before the init even starts. i'll need to check what the problem was but it seems to display some random memory access and then reboots the kernel
<tkaiser>
_mamalala: A Mali a day keeps the doctor away
<_mamalala>
tkaiser: and the sanity is kept away as well, i gather
<tkaiser>
miasma: _Which_ A20 board?
<miasma>
tkaiser: sinovoip banana pi m1+
<miasma>
the banana pro rip-off
<miasma>
it used to work for a week, now it shows those memory errors
<tkaiser>
miasma: Custom u-boot? Own DRAM clockspeed or using conservative settings? 384 MHz?
<miasma>
tkaiser: i compiled the stock u-boot, i think 2016.5 or so
<miasma>
default settings. but i could downclock it
<miasma>
it works for hours, but less than a day :)
<miasma>
and I used kernel 4.6.x, 4.7.x and 4.8-rc3
<tkaiser>
miasma: I misuse a Banana Pro since weeks. Runs constantly and feeds other SBCs through its USB ports. Just works (surprisingly good and with at up to over 1A current delivered)
<miasma>
yes, I know that the boards should work :) I have rpi bs and odroids and they work just fine :) well.. rpis have some nice issues like rebooting when you plug usb devices, but it's by design
<_mamalala>
clock speeds are really important on these cheap chinese boards ... thermal management is usually bad, routing isn't perfect ... it's rather easy to use a clock speed that can, over time, damage stuff, unfortunately
<miasma>
that could be the case
<tkaiser>
miasma: BPi M1+ shares the design flaw unless you power through SATA power connector ;)
<miasma>
could be. i never tested
<miasma>
fun things these micro-usb connectors
<_mamalala>
tkaiser: that reminds me ... did the small heatsinks arrive yet, and if so, had a chance to check one out? at least for me they provide enough cooling to have the chip run at 1.2G all the time (albeit with not so much system load, i admit)
<tkaiser>
miasma: crap things these crap connectors.
<tkaiser>
_mamalala: Yeah, just tried it before and did it obviously wrong (mot enough thermal glue I would suppose). I glued one on NanoPi M1, idle temp remained the same and when running cpuburn-a7 it gets up to 816 MHz instead of 720 MHz
<tkaiser>
_mamalala: So obviously I managed to provide enough insulation between heatsink and SoC ;)
<_mamalala>
;)
<tkaiser>
Will give it a try with the other NanoPi M1 tomorrow. And if this works correctly then I start with the NEO
<_mamalala>
it shouldn't have too much effect on idle temp anyways ... the temp sensor is on the die, while there is quite some thermal resistance to even get to the contact surface to the heatsink ...
<_mamalala>
it is, after all, only passive cooling
<_mamalala>
haven't tried cpuburn yet, but at least running stress for longer times barely brings it over 65 degrees or so, with sysload shown at 9 or 10
<miasma>
tkaiser: I suppose if you had two wire usb cables and a 'smart' connector in the one end, you could make a stronger charger cable for phones and stuff, but for some reason most of the cables are for both data and charging
afaerber has quit [Quit: Ex-Chat]
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
<tkaiser>
miasma: No idea, electrics NOOB. I bought a couple of 20AWG rated USB cables and use most of the times an ultra short one for such stuff. With NanoPi M3 (octa-core Samsung SoC) I can power the device off with cpuburn-a7 when connected through USB but not via pin header. So I would assume contact resistance is also an issue? It almost hurts looking at these tiny contacts in a Micro USB jack.
Putti has joined #linux-sunxi
sarietta_ has joined #linux-sunxi
<_mamalala>
tkaiser: ok, just compiled cpuburn-a7 ... it manages to throttle down the chip to 1008MHz at around 70 degrees
<_mamalala>
well, to get the chip throttled down, i mean
<_mamalala>
just removed budget cooling from the kernel to see how high it will climb when fixed at 1.2GHz
Mr__Anderson has quit [Remote host closed the connection]