<buZz>
raspi found. saying they will probably never release aarm64 raspbian
<ssvb>
pi3 can use aarch64, but it's just highly experimental at the moment
<buZz>
yeah with no driver support
17WAAT1WJ has quit [Ping timeout: 246 seconds]
<ssvb>
pi3 has limited ram size/bandwidth, also the network connectivity and usb are very weak
<ssvb>
they are using an old SoC and just upgrading the CPU part
<ssvb>
it is very reasonable that they only officially support 32-bit software, because this is a safe choice and also reduces memory footprint as a bonus
<ssvb>
their only strong point is relatively problem free software, why would they try to destroy their advantage?
fdcx has joined #linux-sunxi
fdcx_ has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
fdcx has quit [Ping timeout: 246 seconds]
fdcx_ has quit [Ping timeout: 264 seconds]
<KotCzarny>
who needs 64bit anyway
Mr__Anderson has quit [Remote host closed the connection]
fdcx has joined #linux-sunxi
fdcx_ has joined #linux-sunxi
<ssvb>
KotCzarny: that's a good question
<ssvb>
most likely the ones who need to make use of tons of RAM, in the ballpark of 4GB or more
<KotCzarny>
or do some weird mmaping tricks
<ssvb>
also scientific calculations can benefit from the FP64 support added to the NEON unit
<KotCzarny>
anything else? like better technology, process, performance or bugfixes?
<ssvb>
better technology and process are completely orthogonal
<ssvb>
performance may be better or may be worse, depending on what exactly you are trying to do
<ssvb>
the quality of software is still much better in the 32-bit land, so if you worry about bugs, then it's best to stay away from AArch64
<ssvb>
AArch64 is providing a lot more entertainment for hackers though, they may enjoy hunting down all those pesky bugs :-)
<KotCzarny>
and its interesting for developers of course just for the sake of being new
aballier has joined #linux-sunxi
popolon has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<tuxillo>
moin
premoboss has joined #linux-sunxi
apritzel has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<MoeIcenowy>
ssvb: I think sunxi devices with mainline kernel have less issues than rpi...
<MoeIcenowy>
If all the necessary driver is ready
caog has joined #linux-sunxi
<apritzel>
ssvb: I seriously doubt that quality of software is much better for arm32
<apritzel>
yes, it has been around for much longer, but ARMv8 is a much more sane architecture
<ssvb>
apritzel: not all the 32-bit assembly optimizations have been ported yet, then we have various JIT engines and stuff like this
<apritzel>
also taken more seriously by software vendors (like distributions)
<ssvb>
not to mention poorly written software, which may make assumptions about the pointer size on arm
<apritzel>
we have slightly different viewpoints here, I guess
<apritzel>
I think more about server class applications
<ssvb>
yes, ARMv8 is going to be better in the long run
<ssvb>
but right now not everything is so simple, and just recompiling the software does not ensure that it will run perfectly fine
<ssvb>
btw, the fact that the worst Cortex-A53 errata only affect the 64-bit mode is also telling a lot
<apritzel>
ssvb: well, nobody cares about AArch32 on A53, really
<apritzel>
(at least not on Linux, Android may be different)
<ssvb>
"nobody" == "Raspberry Pi foundation"?
<apritzel>
Oh, yeah, those one ...
<apritzel>
let's put it that way: upstream Linux does not care
iamfrankenstein has quit [Ping timeout: 244 seconds]
<ssvb>
upstream Linux supports running 32-bit applications
<apritzel>
sure, I was more thinking about the kernel part
<apritzel>
probably tunnel vision ;-)
<ssvb>
and realistically, running a 32-bit userland would be probably the most reasonable choice for the 512MB variant of Pine64
<apritzel>
we had quite some issues with running 32-bit kernels on ARMv8 in practise, that's why I think nobody seriously tried that before
<apritzel>
ssvb: or this ILP32 thing - if that ever materialises ;-)
iamfrankenstein has joined #linux-sunxi
<apritzel>
and yeah, 32-bit luserland just works - booted one accidentally the other days and didn't even noticed for a while ;-)
<tuxillo>
how long until arm 32-bit dissapears in favour of 64-bit?
<tuxillo>
in my view it will be more than a decade
enrico__ has joined #linux-sunxi
<lvrp16>
woah ILP32
<lvrp16>
hope that doesn't go the way of x32
<apritzel>
sure it does
<apritzel>
shall it ever get merged, first ;-)
<apritzel>
interesting from a technical point of view, but a PITA to maintain
<lvrp16>
does any1 really use x32?
<apritzel>
not that I know of
<lvrp16>
beside extreme performance phobes
<apritzel>
except for this one benchmark, where it shines
<lvrp16>
i used it when doing high performance compute project in college but that was it..
<lvrp16>
but it does make sense on many levels
<KotCzarny>
just not in the desktop/sbc area?
<KotCzarny>
;)
<apritzel>
sort of, but it means to maintains a completely separate set of binaries and librariies
<apritzel>
which frankly nobody really likes
<tuxillo>
so no opinions? :D
<KotCzarny>
especially when mem bandwidth is so little
<ssvb>
lvrp16: not really, x32 is just a third incompatible ABI to maintain
<KotCzarny>
(and as i understand 64bit means 2x more bw usage?)
<maz>
lvrp16: so far, performance results tend to show that it doesn't show much improvement over the full AArch64 ABI.
<apritzel>
KotCzarny: you can't say that in general
<maz>
lvrp16: you get extra registers, but you also get extra overhead on any exception, syscall.
<maz>
lvrp16: this is basically a marketing attempt at saying "we can also do 32bit" when your CPU only has a 64bit instruction set.
<ssvb>
lvrp16: and suddenly you discover that some (small) fraction of applications does not work well for one reason or another, while the developers are definitely not eager to go extra mile supporting it
<apritzel>
ssvb: absolutely
<lvrp16>
maz: ssvb: that was my general experience.
<lvrp16>
it was some 30% faster in some of the problems I was working on
<maz>
lvrp16: my concern is that this thing will bitrot within a couple of years (lack of users), and will create a maintenance (and possibly security) burden for the rest of us.
matthias_bgg has joined #linux-sunxi
<lvrp16>
i can totally see that
<tuxillo>
when you refer to x32 you're referring to aarch32?
<ssvb>
tuxillo: yes, but there are some devices with limited RAM size, and having 64-bit pointers is seen by some people as a waste (they also need some storage space)
<tuxillo>
yeah, that's true
<tuxillo>
x32 or ILP32 sounds like a good approach, doesn't it?
<maz>
tuxillo: in theory only. in practice, this is yet another ABI that will not get used, driven by a compiler that lacks maturity.
<maz>
tuxillo: just look at who uses x32. almost nobody.
enrico__ has quit [Quit: Bye]
<tuxillo>
I see
<tuxillo>
but I was thinking in ARM devices with 1 or 2GB of memory
<maz>
tuxillo: most 64bit cores also support aarch32, so you're much better off running that.
<tuxillo>
sounds like the correct approach to use
<tuxillo>
yeah, true
<apritzel>
tuxillo: I'd rather fix that issue by adding more memory
<tuxillo>
your point is that the trade-off might not be worthy
<apritzel>
ILP32 shouldn't be an excuse for having only 1GB
<tuxillo>
how do you add more memory to a SoC?
<apritzel>
you solder bigger memory chips to the board?
<maz>
tuxillo: erm. you plug a DIMM in?
<merbanan>
ssvb: I have a MT board without sources for the memory controller, is there any open source implementation of schmoo training ?
<tuxillo>
well, I was talking about the average user :P
<maz>
tuxillo: you've voted with your money.
<tuxillo>
what?
<maz>
tuxillo: you've decided to buy a system with limited extension capabilities, and hardly any RAM on board.
<maz>
tuxillo: I'd happily pay twice as much for a board *without* any memory.
<tuxillo>
yes, that's correct. currently I own a rpi2, rpi3 and a pine64
<tuxillo>
well we have to adapt to what's provided
<tuxillo>
no?
<maz>
tuxillo: I tend to think the opposite, and strive for something better than the sh*t we're being fed... ;-)
<tuxillo>
how do you change the tide?
Amit_t_ has joined #linux-sunxi
<tuxillo>
convince a large number of developers to hold on and not buy what's provided?
<maz>
tuxillo: by *not* buying stuff that doesn't seem fit for purpose.
<tuxillo>
you blackmail the manufacturer? hehe I don't know
<tuxillo>
that sounds a lot like idealism :-)
<ssvb>
there is also the ASLR thing, which inherently needs large address space
<maz>
tuxillo: I have no problem with that, having been hacking on Linux for the past 24 years...
iamfrankenstein1 has joined #linux-sunxi
<tuxillo>
really?
<maz>
tuxillo: really what?
<tuxillo>
24 years working on the linux kernel
<tuxillo>
because that's basically almost from the beginning
<maz>
tuxillo: first patch in late 1992, so I'm probably lying. 23.7 years, or so.
<maz>
tuxillo: bear in mind that I'm probably 3 times your age... ;-)
<tuxillo>
got a webpage where I can stalk your work?
<tuxillo>
:P
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<maz>
tuxillo: I got a tree on kernel.org, and that's enough.
<tuxillo>
I doubt you're 105 years old :P
<maz>
tuxillo: I feel that old sometimes.
<KotCzarny>
hehhee
<tuxillo>
maz: you do that for a living, I guess
<maz>
tuxillo: indeed.
<tuxillo>
that must be cool
<maz>
tuxillo: just like apritzel
<tuxillo>
I work on something you've probably just heard
<apritzel>
though maz is much more successful in this ;-)
<tuxillo>
hehe
<tuxillo>
you guys know SAP?
matthias_bgg has quit [Ping timeout: 264 seconds]
<maz>
tuxillo: yeah, have to deal with the crap on a regular basis. never works. ;-)
<tuxillo>
haha
<tuxillo>
your company runs sap for HR or what? :P
<tuxillo>
I am what is known as a SAP administrator
<tuxillo>
and I like OS development, well in a very very amateur way
<tuxillo>
quite a difference in the job vs the hobby
<Amit_t_>
maz: 1992 ?, I was just couple year of old :)
caog has left #linux-sunxi ["Ex-Chat"]
<maz>
tuxillo: yeah, they use it for HR, payroll, holidays, and probably other things I don't want to know about.
mark__ has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
<tuxillo>
maz: I can see you work at ARM (or worked recently)
<MoeIcenowy>
23.7 years...
<MoeIcenowy>
I'm only 18 years old...
cnxsoft1 has joined #linux-sunxi
<tuxillo>
maz: there is a bsd developer that I know that works at ARM as well, but in cpu design afaik
Amit_t_ has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft1 is now known as cnxsoft
Amit_t_ has joined #linux-sunxi
bonbons has joined #linux-sunxi
<ssvb>
merbanan: what kind of MT board?
<ssvb>
merbanan: in fact, which SoC is used in it?
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
premoboss has quit [Remote host closed the connection]
IgorPec has quit [Ping timeout: 240 seconds]
fdcx_ has quit [Remote host closed the connection]
fdcx has quit [Remote host closed the connection]
Mr__Anderson has joined #linux-sunxi
IgorPec has joined #linux-sunxi
aballier has quit [Ping timeout: 260 seconds]
aballier has joined #linux-sunxi
bmeneg has quit [Remote host closed the connection]
<merbanan>
ssvb: MT7621
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
vagrantc has joined #linux-sunxi
vagrantc has quit [Client Quit]
matthias_bgg has joined #linux-sunxi
lennyraposo has quit [Ping timeout: 252 seconds]
IgorPec has quit [Ping timeout: 244 seconds]
lennyraposo has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
xinj has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 260 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
Amit_t_ has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
reinforce has joined #linux-sunxi
enrico_ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
fdcx has joined #linux-sunxi
IgorPec has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<ssvb>
merbanan: but MT7621 is not an Allwinner SoC, so its DRAM controller may be very much different
fdcx has quit [Ping timeout: 252 seconds]
Gerwin_J has joined #linux-sunxi
fdcx has joined #linux-sunxi
<ssvb>
jelle, mripard, lennyraposo: the 64-bit mali blob and also a new display driver variant with GPL license notices for HDMI code parts - http://wiki.pine64.org/index.php/Mali_Driver
<ssvb>
only 'drm_al.c' and the transform accelerator support code are 'all rights reserved'
<jelle>
ssvb: nice
<ssvb>
well, I guess this code can be used for implementing the video driver for U-Boot
<jelle>
64 bit mali blob is for the pine and is similiar to the H3?
<ssvb>
well, only pine64 can run 64-bit code
<jelle>
yup
<ssvb>
and traditionally, there is no EULA with the mali blob :-/
<ssvb>
ARM tends to have some funny clauses in the mali blob EULA nowadays, so it would be nice to clarify this
cnxsoft has quit [Quit: cnxsoft]
<lennyraposo>
ya downloading
fdcx has quit [Remote host closed the connection]
<lennyraposo>
reading
xinj has quit [Ping timeout: 260 seconds]
zuikis has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<lennyraposo>
some additions to longsleeps kernel work
<lennyraposo>
how is it looking to you ssvb?
nove has joined #linux-sunxi
<ssvb>
lennyraposo: I have only briefly looked at it
<ssvb>
I was obviously most interested in the GPL compatible code for HDMI support
<jelle>
I'm not sure if I want to invest my free time in the u-boot driver hmm
<ssvb>
jelle: ok
<ssvb>
are you working on something else at the moment?
<jelle>
ssvb: yes that too
<jelle>
ssvb: well I hack for fun ;-)
bonbons has quit [Ping timeout: 272 seconds]
matthias_bgg has quit [Ping timeout: 260 seconds]
<lennyraposo>
ssvb were you referring to video driver for mainline integration?
<ssvb>
lennyraposo: yes
<lennyraposo>
that's good news :D
iaglium has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
bonbons has joined #linux-sunxi
<jelle>
ssvb: although hmm this new code dump might give me some hope to pick it up again :-)
<ssvb>
jelle: make up your mind ;-)
<jelle>
haha indeed
matthias_bgg has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #linux-sunxi
<nove>
will the use of a tool such as fossology.org, be any good?
<mripard>
ssvb: awesome
<MoeIcenowy>
mripard: you merged some usb nodes in q8 dtsi?
<mripard>
yes
<mripard>
why?
<MoeIcenowy>
I think they should be enabled in per-device dts
PolarbearIbiza has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 260 seconds]
jernej has joined #linux-sunxi
cptG_ has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
cptG has quit [Ping timeout: 246 seconds]
BenG83 has joined #linux-sunxi
PolarbearIbiza has quit [Quit: Verlassend]
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
fire219 has joined #linux-sunxi
<fire219>
hi, recently i've been trying to build apritzel's a64-v5 branch of the linux kernel, but keep coming up across a few errors, but the one i'm most puzzled by is the acpi tbfind.o error here http://pastebin.com/BYCLHL2B
<fire219>
i've tried numerous toolchain versions (gcc-4.9 and 5.3), and even completely redownloading the source to rule out file corruption
<fire219>
does anyone have some insight as to why this may happen?
<apritzel>
this is probably due to being based on -rc1 in combination with a non-defconfig setup?
<apritzel>
have you tried defconfig?
<fire219>
i have been using the usual arm64 defconfig
popolon has quit [Quit: WeeChat 1.3]
zuikis has left #linux-sunxi [#linux-sunxi]
zuikis has joined #linux-sunxi
<apritzel>
fire219: weird ...
<apritzel>
I am on the run now, will look at it later
paulk-collins has quit [Quit: Leaving]
<fire219>
thanks. this has been driving me crazy for the last week or so
apritzel has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
vagrantc has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
jstein_ has joined #linux-sunxi
jstein is now known as Guest87075
jstein_ is now known as jstein
Guest87075 has quit [Ping timeout: 240 seconds]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<mripard>
MoeIcenowy: maybe, you have to be more specific
<apritzel>
remove that (it's pointless and dangerous anyway)
<apritzel>
some people (including me) _never_ compile anything as root
<apritzel>
you could also try to add ~/Pine64dev/aarch64-linux-gnu/bin to your PATH
creemj has quit [Ping timeout: 244 seconds]
<fire219>
apritzel: because it was bitching at me about file permissions and my subconscious response is to sudo it, for better or worse
popolon has joined #linux-sunxi
<apritzel>
IIRC sudo nukes any exports
<fire219>
kinda had a feeling it would, but had no way to prove that
<fire219>
anyway, doing it this way fixed the acpi error, but sound one is still there. i have fixed the sound one in the past though, so i can do it again :)
<fire219>
nevermind -- no it did not, i just missed it
<apritzel>
can you look what in the head of .config after defconfig?
<apritzel>
mainly to check that it's the right architecture
<fire219>
it's arm64
creemj has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
al1o has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ikmaak has quit [Ping timeout: 276 seconds]
naobsd has quit [Remote host closed the connection]