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
mosterta has quit [Read error: No route to host]
mosterta has joined #linux-sunxi
Amit_T has quit [Ping timeout: 265 seconds]
TheSeven has quit [Ping timeout: 276 seconds]
TheSeven has joined #linux-sunxi
ssvb has quit [Quit: Leaving]
scream has quit [Remote host closed the connection]
<juri_> ok, it'- definately my patch.
stasiic has quit [Ping timeout: 244 seconds]
apritzel has quit [Ping timeout: 244 seconds]
<wens> juri_: isn't stmmac broken in 4.5?
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 276 seconds]
cnxsoft has joined #linux-sunxi
arossdotme-planb has quit [Quit: Ex-Chat]
mosterta has quit [Read error: Connection timed out]
mosterta has joined #linux-sunxi
steev has quit [Ping timeout: 250 seconds]
steev has joined #linux-sunxi
aep has quit [Remote host closed the connection]
Guest61622 has quit [Ping timeout: 250 seconds]
zumbi has joined #linux-sunxi
aep has joined #linux-sunxi
adj__ has joined #linux-sunxi
mosterta has quit [Read error: Connection timed out]
mosterta has joined #linux-sunxi
mozzwald has quit [Ping timeout: 244 seconds]
mozzwald has joined #linux-sunxi
mosterta|2 has joined #linux-sunxi
mosterta has quit [Ping timeout: 240 seconds]
Amit_T has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 276 seconds]
p1u3sch1_ has joined #linux-sunxi
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
<juri_> wens: there's a patch for it. i'm running said patch.
IgorPec has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
JohnDoe1 has joined #linux-sunxi
jernej has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 246 seconds]
jernej has quit [Ping timeout: 252 seconds]
adj__ has quit [Quit: Leaving]
staplr has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
JohnDoe1 has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
zuikis has joined #linux-sunxi
Netlynx has joined #linux-sunxi
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
paulk-aldrin has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
jernej has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
bonbons has joined #linux-sunxi
al1o has joined #linux-sunxi
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 260 seconds]
cnxsoft1 is now known as cnxsoft
apritzel has joined #linux-sunxi
staplr has quit [Ping timeout: 244 seconds]
staplr has joined #linux-sunxi
<wens> juri_: is it in stable?
apritzel has quit [Ping timeout: 244 seconds]
p1u3sch1_ has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
jernej has quit [Ping timeout: 260 seconds]
jstein has joined #linux-sunxi
avph has joined #linux-sunxi
jernej has joined #linux-sunxi
<montjoie> apritzel I am sure that on pine64 PHY need to be powered, each time EMAC timeout in reset, the root cause is PHY
apritzel has joined #linux-sunxi
staplr has quit [Ping timeout: 276 seconds]
apritzel has quit [Ping timeout: 244 seconds]
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
The_Loko has joined #linux-sunxi
arossdotme has quit [Ping timeout: 246 seconds]
jernej has quit [Ping timeout: 260 seconds]
arossdotme has joined #linux-sunxi
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
jernej has joined #linux-sunxi
The_Loko has quit [Ping timeout: 246 seconds]
The_Loko has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
stasiic has joined #linux-sunxi
IgorPec has joined #linux-sunxi
Graf_Ithaka has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 246 seconds]
<Graf_Ithaka> good afternoon. Starting off with my Pine64, using the arch-build. already updated kernel manually (using kernel.sh from build-pine64-image repository). Only have access via UART. Is kernel 3.10.101-0-pine64-longsleep already hdcp_enable=0 ? On some points in the forum people hint that this might resolve HDMI/DVI issues. Thanks in advance :)
p1u3sch1 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 276 seconds]
dlan has quit [Ping timeout: 250 seconds]
<longsleep> Graf_Ithaka: all my releases are with hdcp disabled
<Graf_Ithaka> longsleep: thanks for the confirmation, then I'll need another adapter I guess :)
<longsleep> Graf_Ithaka: default HDMI resolution is 1080p60 - does your screen support that?
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
<Graf_Ithaka> longsleep: not exactly, it supports 1920x1200 @ 60Hz and many more modes below that
<longsleep> Graf_Ithaka: well then you have the answer, check the Pine64 forum on how to switch to lower resolution (eg 720p)
<longsleep> Graf_Ithaka: some people have confirmed that it works for them now with the releases from yesterday
<Graf_Ithaka> longsleep: tried doing so with your sunxi-disp-tool already but to no avail.
<longsleep> Graf_Ithaka: well - it should work just fine, try the Xenial image if unsure
<Graf_Ithaka> longsleep: okay will try that one :) thanks for your help :)
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 240 seconds]
iamfrankenstein1 is now known as iamfrankenstein
p1u3sch1 has quit [Ping timeout: 244 seconds]
p1u3sch1 has joined #linux-sunxi
arossdotme has quit [Ping timeout: 276 seconds]
The_Loko has quit [Quit: Leaving]
kruxXx has joined #linux-sunxi
Nacho has quit [Ping timeout: 246 seconds]
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> montjoie: PHY powered> yeah, would make sense, only the schematics is not really helpful here
<apritzel> montjoie: there is some extra power signal referenced in the PHY section, but it's not clear where it is connected
<apritzel> and on the PMIC section I don't see a rail that would be reserved for the PHY
<apritzel> NiteHawk: btw: your Pine64 is on the way, 1GB plus Wifi
<apritzel> probably the best packaged Pine64 so far ;-)
cnxsoft has quit [Quit: cnxsoft]
IgorPec has joined #linux-sunxi
<wens> maybe the bundled dt has some clues?
<NiteHawk> apritzel: great. thanks a lot!
<NiteHawk> apritzel: if you find some time, i'd like you to take a closer look at https://github.com/n1tehawk/pine64/tree/for-sunxi-tools - i've added a first implementation of the "extract" feature
<apritzel> wens: yeah, I am afraid I have to go down into the BSP dungeon for this ;-)
<apritzel> NiteHawk: ah, nice, looks mostly good
<apritzel> only that I am not a fan of mapping file formats to C structs
<apritzel> as this relies on the compiler and ABI to match the file format
<NiteHawk> ah, i see. to me, the uboot_header_t didn't "feel worse" than shuffling around with the word offsets
<Graf_Ithaka> longsleep: I tried the Xenial image. I can get a pink-ish image for a short time during boot if I flash the uboot with hdmi_cts_compatibility=1 as mentioned somewhere in the Xenial thread. Then image disappears again. Also I might have messed up something with this flash since my wifi is now not working anymore.
<apritzel> I see this "mapping something to C structs" a lot in sunxi code (in U-Boot, for instance)
<NiteHawk> apritzel: as i'm not making too much use of those header fields in extract_image(), i could discard/revert that again easily
<apritzel> this is frowned upon in the kernel - I guess for x86(-64), arm and arm64 the assumptions hold for the time being, that's why it works
<NiteHawk> well, as long as you can make sure that your structs match the actual (file or memory) layout, it's a somewhat 'natural' way to access the member fields
<apritzel> yeah, I see that, the point is that "make sure" is not really possible, as the C standard says that the compiler is free to align members in structs
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
<apritzel> now there is an ABI demanding certain rules to make object files compatible
<apritzel> so far the rules for arm and x86 match up here, at least for things like uint32_t, uint64_t and char[], which is whats mostly used in these fields
<apritzel> so I decided deliberately to give this array approach a go here
<apritzel> and it didn't look too bad
<NiteHawk> well it's really up to your preferences - i can live with those header_offsets enum just as well
<apritzel> I see some code in U-boot which matches register offsets to structs, with having the register offsets (as described in the manual) as comments in the declaration
kaspter has joined #linux-sunxi
<apritzel> which is a bit weird, as the register offset is the reference and it should be reflected in the code, not in the comments
<NiteHawk> yeah, quite a few places in uboot rely on structs / packing i think. at least from what i've seen when tinkering with the spl header
arossdotme has joined #linux-sunxi
mosterta|2 has quit [Read error: No route to host]
mosterta|2 has joined #linux-sunxi
jernej has joined #linux-sunxi
<KotCzarny> lvrp16: where is opi+2e ?
<lvrp16> KotCzarny: Coming out this week
<KotCzarny> lvrp16: woo, hoo
staplr has joined #linux-sunxi
<longsleep> apritzel: Pine64 nic driver is horrible - beware :)
<longsleep> Graf_Ithaka: and you added the kernel parameter so that it changes to 720p on boot?
<longsleep> Graf_Ithaka: but anyhow, you can ssh in and just try out various resolutions from commandline
<wens> longsleep: already looked at it :|
<Graf_Ithaka> longsleep: I added disp.screen0_output_mode=EDID:1280x720p60 as fallback. at a certain point I get [HDMI WRN] file:drivers/video/sunxi/disp2/hdmi/drv_hdmi.c,line:331: unsupported video mode 65535 when set display mode
<Graf_Ithaka> longsleep: I am connected via UART and tried playing with the resolutions. No reaction at all, screen stays blank
<longsleep> Graf_Ithaka: yeah, ignore that line message - its something else sending wrong parameters
<longsleep> Graf_Ithaka: well, then i guess you need another converter. I think there are some references to working ones in the Pine64 forum
<wens> seems there's a) void * base + OFFSET_MACRO, and b) &((struct foo *)base->bar)
<wens> kernel uses (a) more, while u-boot uses a lot of (b)
ricardocrudo has joined #linux-sunxi
<Graf_Ithaka> longsleep: already guessed so. Well, weekend is over anyway :) Thanks for your help and have a nice evening! :)
<longsleep> Anyone has measured performance of the various sunxi-ss crypto and hash implementations? I am wondering if i should bother with them ...
<longsleep> In any case, they now at least register - if someone is interested https://github.com/longsleep/linux-pine64/commit/e0d92c27bcfcbdcec6bae81dae4fb1729bab4d96
jernej has quit [Ping timeout: 252 seconds]
<wens> montjoie: ^
<longsleep> See http://paste.ubuntu.com/16302792/ for cat /proc/crypto for the results running with this patch on 3.10.101
<longsleep> but the user space examples and tests from libkcapi do not work as it seems there are some use space crypto patches not mainlined :/
<lennyraposo> haven;t tried yet longsleep
<NiteHawk> apritzel: dropped the struct and modified extract_image() accordingly - https://github.com/n1tehawk/pine64/commit/98c3e30
jernej has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 260 seconds]
mosterta|2 has quit [Read error: Connection timed out]
mosterta|2 has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 240 seconds]
hrw has quit [Read error: Connection reset by peer]
Nyuutwo has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
fredy has quit [Excess Flood]
hrw has joined #linux-sunxi
fredy has joined #linux-sunxi
jernej has quit [Ping timeout: 244 seconds]
mosterta|2 has quit [Read error: Connection timed out]
<montjoie> longsleep: I have benchmarked them
<montjoie> since I made them:)
<montjoie> longsleep: old data on sunxi.montjoie.ovh
Graf_Ithaka has quit [Ping timeout: 260 seconds]
<montjoie> oups it seems you speak BSP crypto driver and not mainline
Graf_Ithaka has joined #linux-sunxi
jernej has joined #linux-sunxi
<longsleep> montjoie: yeah i was looling into the ones which are in the BSP 3.10 driver for A64
dev1990 has joined #linux-sunxi
<longsleep> montjoie: ah but i can try if i get some numbers with https://github.com/montjoie/cryptotest - thanks for the link!
<apritzel> montjoie, wens: does sunxi-ss does something that the ARMv8 crypto extensions don't
<apritzel> wens: longsleep: back in December I took the BSP NIC driver and ported it to upstream
<apritzel> but then montjoie was getting promising results and so I dropped this
<apritzel> also there were some open questions around the regulators anyway
<apritzel> and I tried two weeks ago to compare the initialisation sequence of the BSP driver with montjoie's
<apritzel> just found one confusing bit to be different, but that didn't make a difference when I tried it
<apritzel> (that was that the BSP driver set bit 13 (enable bit?) in the clock register to 0, where the manual hints it to be set to 1)
<longsleep> montjoie: sunxi-ss md5 and sha1 is slower than the kernel ones according to your cryptotest af_alg - that is expected?
<longsleep> apritzel: i was under the impression that sunxi-ss does use something in the hardware? no?
<KotCzarny> but they free cpu still ?
<apritzel> longsleep: well, it is Allwinner hardware
<apritzel> but ARMv8 has crypto instructions in the core
<apritzel> which the kernel uses
<apritzel> potentially much faster
<KotCzarny> if cpu is free then its still a win even if slower than kernel implementation
<longsleep> yes, but only for crc32
<longsleep> (i think)
<apritzel> and sha1
<longsleep> KotCzarny: good point, let me check that
<apritzel> and AES
<longsleep> oh really - i backported only crc32
<KotCzarny> but why anyone should use md5 and sha1 nowadays?
<longsleep> right, sha256 would be nice
<longsleep> and aes-gcm
<longsleep> but in general any cipher which is used internall by whatever driver for hashing would be nice
<longsleep> thats why crc32 is important
<apritzel> yeah, that's the general problem with crypto instructions: when they reach the hardware, they might be already outdated
<KotCzarny> and good prng
<KotCzarny> good prng is never outdated
<longsleep> well no closed prng should be trusted
<longsleep> at least as sole source
<apritzel> oh, and ARMv8 crypto has both SHA1 and SHA256
<longsleep> and the sunxi-ss from 3.10 has one whatever it does
<longsleep> does openssl use those nowadays by default?
<apritzel> SHA1 is important for the most useful userland application these days ....
<apritzel> yeah, there is no architectural RNG in ARMv8
<KotCzarny> looking at benches of ciphers on montjoie's site..
<longsleep> really? what most useful userland app uses sha1?
<apritzel> longsleep: git ;-)
<longsleep> well ..
<longsleep> one where hash performance is critical
<KotCzarny> aes cbc 256 is 50-85% faster
<longsleep> yes, but cbc is useless
<KotCzarny> how so?
<longsleep> because insecure
<KotCzarny> hum
<wens> cbc insecure? O.o
<KotCzarny> issnt it what openvpn recommends?
<longsleep> i certainly hope not - aes-gcm is what you want
<wens> it is not insecure if you use it correctly
<longsleep> well they still recommend TLS 1.0
<longsleep> then you are stuck with cbc
<longsleep> TLS 1.0 == insecure
<longsleep> must have and restrict to 1.2
<KotCzarny> nope, they mention old openvpn versions
<KotCzarny> and recommend 1.2 if server/client supports it
<longsleep> sure, if you have TLS 1.2 disable cbc cipher
<longsleep> if you can limit to TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 only
<wens> longsleep: again, cbc is not insecure
<wens> it is the tls 1.0 implementation of cbc that is insecure
lynxis has quit [Remote host closed the connection]
lynxis has joined #linux-sunxi
<longsleep> wens: well - tls is the only crypto i am really concerned with where performance matter
<wens> then it's only useless for you :)
<longsleep> wens: sure, but still usless in web server and realtime encryption limits aes-cbc quite a lot
paulk-aldrin has quit [Remote host closed the connection]
<longsleep> also for completeness sake: lucky thirteen aes-cbc mitm attack paper at http://www.isg.rhul.ac.uk/tls/TLStiming.pdf
<wens> on a reasonably fast x86 machine with aes instructions, SSL AES accounts for a really small amount of cpu usage
<wens> for arm clients maybe it's a bigger difference
<longsleep> wens: assuming you trust intel aes, which i would not advise
<wens> longsleep: and you would trust arm or allwinner for that matter?
<KotCzarny> not to mention ss implementation in socs is buggy probably
<longsleep> wens: no of course not - but i am looking if that module does make any sense performance wise
<longsleep> i would recommend to not use AES (any variant at all), instead use the chacha20-poly1305 ciphers
<longsleep> the NSA will not like you then though
<longsleep> and yes - it is a lot slower if you have intel aes-ni
<lennyraposo> very true longsleep
<KotCzarny> as long the other party supports it
<lennyraposo> anyoen here play with letsencrypt ?
<longsleep> <<
<longsleep> lennyraposo: https://github.com/fancycode/debian-letsencrypt.sh - thats what you need
<montjoie> longsleep: af_alg is slow so bad perf is "expected", cryptodev is better but not in mainline
<longsleep> montjoie: can openssl use cryptodev?
<montjoie> and my bench are for the first SS (A20/A10/etc)
<montjoie> longsleep: yes and no, since cryptodev use ioctl you cannot use it with secomp
<montjoie> see the bug report on my site
<longsleep> KotCzarny: i see no difference in CPU usage for AES with or without ss module (and both yield similar r/s for aes test)
<KotCzarny> maybe you are not using it?
<montjoie> longsleep: KotCzarny SS do not use DMA for the moment so always CPU...
<longsleep> KotCzarny: well the performance is different (slower) for md5 and sha1
<wens> longsleep: chacha20-poly1305 support isn't that great :(
<KotCzarny> montjoie: those tests with dma mention its much slower
<wens> worse if you're dealing with mobile clients
<montjoie> KotCzarny: yes but less cpu
<KotCzarny> ahm. good. would be nice to include cpu column?
<montjoie> but I fear that DMA will never be usable, I need to confirm it, but the data coruption bug made DMA impossible
<KotCzarny> s/cpu/cpu usage/
<wens> longsleep: btw, cbc seems to be fixed in tls 1.1+
<KotCzarny> still, for cbc aes 256 its a nice gain
<lennyraposo> longsleep I know
<lennyraposo> I already use it
<lennyraposo> just wondering what people think ;)
<lennyraposo> been using it since december ;)
<longsleep> pff one of my wifi routers just started smoking and my connection stalled :-/
<KotCzarny> o.O
<KotCzarny> nsa attacks?
<longsleep> its getting summer
<longsleep> i guess the psu fried it
apritzel has quit [Ping timeout: 244 seconds]
kaspter has quit [Ping timeout: 252 seconds]
Graf_Ithaka has quit [Ping timeout: 276 seconds]
Graf_Ithaka has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
zuikis has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
<lennyraposo> pfsense ;)
adj__ has joined #linux-sunxi
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
IgorPec has quit [Ping timeout: 260 seconds]
pmattern has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
Gerwin_J has quit [Quit: Gerwin_J]
jernej has quit [Ping timeout: 244 seconds]
avph has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
jernej has joined #linux-sunxi
apritzel has joined #linux-sunxi
mosterta|2 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
pmattern has quit [Quit: Genug für heute.]
jstein has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 244 seconds]
jernej has quit [Ping timeout: 276 seconds]
IgorPec has quit [Ping timeout: 276 seconds]
jernej has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
wigyori has joined #linux-sunxi
apritzel has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
bonbons has quit [Quit: Leaving]
hrw has quit [Remote host closed the connection]
dev1990 has quit [Quit: Konversation terminated!]
jernej has quit [Quit: Konversation terminated!]
staplr has quit [Remote host closed the connection]
Graf_Ithaka has quit [Ping timeout: 240 seconds]
<apritzel> mripard: sorry for that trouble with that sunxi irq controller patch, who do I have to contact for getting that original ARCH_SUNXI for arm64 patch reverted?
paulk-collins has quit [Quit: Leaving]
jstein has joined #linux-sunxi
hrw has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
<dave0x6d> So for the Orange Pi (One) that has a H3, any suggestions on what kernel to use?
ssvb has joined #linux-sunxi
tomboy65 has quit [Quit: Uhh ... gotta go.]
tomboy64 has joined #linux-sunxi
jstein has quit [Remote host closed the connection]