vishnup has quit [Read error: Connection reset by peer]
tgaz has quit [Ping timeout: 240 seconds]
tgaz has joined #linux-sunxi
premoboss has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Net147 has quit [Ping timeout: 240 seconds]
Net147 has joined #linux-sunxi
afaerber has joined #linux-sunxi
VargaD has quit [Ping timeout: 260 seconds]
NiteHawk has joined #linux-sunxi
<tkaiser>
yann|work: Do you plan to maintain your H3 kernel 3.4 fork?
VargaD has joined #linux-sunxi
domidumont has joined #linux-sunxi
p1u3sch1_ has quit [Ping timeout: 256 seconds]
domidumont has quit [Read error: Connection reset by peer]
domidumont has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
viccuad has joined #linux-sunxi
vishnu_ has quit [Ping timeout: 272 seconds]
viccuad has quit [Ping timeout: 260 seconds]
viccuad has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
<antonva>
Hi guys, I've been building mainline u-boot for the lamobo-r1 (banana pi r1) but I'm hitting a wall. Flashing u-boot-sunxi-with-spl.bin works and I can interact with u-boot on the device. It however does not honor my uEnv.txt nor tries to boot uImage. Any ideas?
<tkaiser>
antonva: uEnv.txt? You'd better look into boot.scr/boot.cmd -- with 2016.01 it should simply work
<antonva>
tkaiser: Okay thanks. I might have been mixing up documentation.
<NiteHawk>
agreed. i don't think mainline u-boot supports uEnv.txt "out of the box" (at least not without customizing). you should take the boot.scr route instead
<plaes>
antonva: which howto or wiki page did you originally follow?
<antonva>
Was looking at the lemaker wiki originally, didn't realize that they had nothing to do with the SoC I have in my hands.
<plaes>
yeah.. there are some vendors who have just copied content from our wiki
<plaes>
but never bothered to keep it up-to-date
<antonva>
Yeah, it was all sorts of wrong.
<plaes>
..or even check whether those instructions work :)
<antonva>
They don't.
<antonva>
Deprecated sfdisk flags etc.
<antonva>
Oh, that's actually out of date in sunxi wiki as well.
<plaes>
just let us know or fix yourself.. ;)
<tkaiser>
antonva: With which kernel do you want to proceed then?
<antonva>
I want to experiment with OpenBSD on it.
<antonva>
Fully aware that it will be a headache.
JohnDoe1 has joined #linux-sunxi
<tkaiser>
In case you want to use this device as a 'router' be prepared that you'll need the b53 driver (OpenWRT) and that the 'worst case scenary' (acting like a bridge between WAN/LAN and not a router) is default behaviour
JohnDoe_71Rus has quit [Ping timeout: 276 seconds]
<antonva>
tkaiser: Thanks, I had intended to use it as a router but reading up on the issues it has I'm not so sure anymore. I still want to get it up and running and find some use for it around the house.
mzki has quit [Quit: leaving]
<tkaiser>
antonva: Unfortunately it's just a dumb layer 2 switch when it's booting (or bricked). The switch IC used has 2 RGMII interfaces that could be used to separate traffic. But since the A20 features only one all you can do is to rely on VLANs and the work only after the device loaded the kernel and configured the switch. Until this point your network is open.
<antonva>
Yeah, that's pretty bad.
<tkaiser>
I bought one of this devices just to realise that it has a few flaws. It's now only a dumb switch connected to a PoE injector. And I would never buy this board again since in theory it's great but in reality it totally sucks :)
<antonva>
I'm realising that more and more
<tkaiser>
Anyway: If you use an USB-to-Ethernet adapter for WAN you're fine
<antonva>
Mmmhm. What about the poor network performance?
<antonva>
Saw something about that on the wiki as well.
<tkaiser>
I never exceeded 370 Mbits/sec for yet unknown reasons.
<tkaiser>
Maybe related to the b53 driver -- don't know
<longsleep>
Can anyone enlighten me about IPI in smp.c. NR_IPI is 4 for arm64, but Allwinner tree passes 5 (for A64 BSP). Passing only 4 compiles and boots fine but i have no idea about possible consequences.
<yann|work>
tkaiser: probably a little - although we probably won't use H3 at work at the end, I have ordered an OrangePiPC for a personal project. Can't make any promise, though, time is scarce :)
Nacho has quit [Ping timeout: 248 seconds]
Ntemis has joined #linux-sunxi
<Ntemis>
hi
<Ntemis>
need some help
<Ntemis>
anyone knows what is the ethernet driver for orange pi pc?
Nacho has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
<Ntemis>
nothing spells the network chip name in there
<buZz>
Configure this kernel using sun8i_h3_defconfig, the rest is explained in the kernel compilation guide.
<buZz>
that has the driver enabled
<Ntemis>
what i must enable (driver?)
<tkaiser>
yann|work: Good to know. Currently I take your fork as Armbian's base for Orange Pi One (and the other H3 models)
<tkaiser>
I had to revert the GMAC patches you applied for the Plus and now nearly everything works on the Orange Pi One
<tkaiser>
Except HDMI output.
<tkaiser>
Ntemis: There is no Ethernet support for the H3 in mainline kernel at the moment.
<tkaiser>
Still WiP
<Ntemis>
CONFIG_STMMAC_ETH=y ? tkaiser
<tkaiser>
It doesn't work, there is no code. It's new IP in H3/A83T/H64
<tkaiser>
We have no driver in mainline
<Ntemis>
shit
<Ntemis>
you saved me a lot of recompiling though
<tkaiser>
Or USB-to-Ethernet adapter. This way an Orange Pi PC is serving music with 4.4.0-rc5 since weeks
<Ntemis>
nah
<Ntemis>
i have openwrt trunk ready
<Ntemis>
but with no ethernet working is just a pile of a bootable distro
<tkaiser>
yann|work: Do you have HDMI output?
<Ntemis>
tkaiser: will we get any gpu hw decoding in mainline too?
<yann|work>
tkaiser: yes, HDMI output works fine, HDMI-to-DVI adapter needs the relevant line in .fex (available as comment in my sunxi-boards-fex fork)
p1u3sch1 has quit [Ping timeout: 248 seconds]
<Ntemis>
its
<Ntemis>
hdmi_cts_compatibility = 1
<yann|work>
tkaiser: so we have to find a way to make both platforms work. Will be able to test both as soon as I recieve my piPC
<Ntemis>
hdcp_enable = 0
<yann|work>
did not check if hdcp_enable was necessary to change
<Ntemis>
yeap
p1u3sch1 has joined #linux-sunxi
<yann|work>
at least it works when setting both :)
<Ntemis>
it works
<tkaiser>
Ok, will try that next. Regarding HW acceleration and mainline... who knows... That's one of the reasons we spend now some time to get Armbian up and running with kernel 3.4 for H3
<tkaiser>
Interesting: With broken Ethernet SoC temperature is reported a few degrees lower and also consumption is 0.2W less :)
<KotCzarny>
device drivers without power management, fun, isnt it?
Nacho has quit [Ping timeout: 240 seconds]
<KotCzarny>
try connecting ethernet cable
<tkaiser>
yann|work: Nope, hdcp_enable = 0 and hdmi_cts_compatibility = 1 didn't do the trick.
<tkaiser>
Maybe the HDMI port is broken... I will build Armbian for the OPi PC and try there...
hipboi has joined #linux-sunxi
<tkaiser>
yann|work: My average load is 2.0 or above. 2 vsync processes in state D. i thought you resolved that already?
Nacho has joined #linux-sunxi
<yann|work>
tkaiser: it is in branch h3-wip, since I'm not sure if that is the correct solution
Ntemis has quit [Remote host closed the connection]
<yann|work>
would have to check what those vsync are trying to do, and why they have this behaviour
<tkaiser>
Ok, I try h3-wip out then.
Nacho has quit [Ping timeout: 240 seconds]
Nacho____ has joined #linux-sunxi
yann|work has quit [Ping timeout: 240 seconds]
<tkaiser>
yann|work: The 'usb-hardware-scan' issue can be resolved/workarounded by defining 'usb_detect_type = 0' for usbc0 in the fex file
hipboi has quit [Quit: This computer has gone to sleep]
<wens>
h3 / a83t / pine64 ethernet is a new, unsupported IP block
hipboi has joined #linux-sunxi
jstein has joined #linux-sunxi
FDCX has quit [Remote host closed the connection]
IgorPec has joined #linux-sunxi
JohnDoe1 has quit [Ping timeout: 240 seconds]
hipboi has quit [Quit: This computer has gone to sleep]
hipboi has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-sunxi
leio_ has quit [Read error: Connection reset by peer]
leio has joined #linux-sunxi
yann|work has joined #linux-sunxi
IgorPec has quit [Ping timeout: 272 seconds]
raknaz has joined #linux-sunxi
leio_ has joined #linux-sunxi
leio has quit [Ping timeout: 264 seconds]
raknaz has quit [Quit: raknaz]
paulk-collins has quit [Ping timeout: 240 seconds]
premoboss has quit [Remote host closed the connection]
<zoobab_>
@tkaiser which GIT repo do you use for h3-wip?
hypophthalmus has joined #linux-sunxi
<zoobab_>
any idea if the current uboot for H3 supports tftp?
<zoobab_>
I am sending an orangepi board to Kernelci.org, but they require TFTP booting in uboot, so in case it is not supported, I will try to make kexec kernel with TFTP support
<hypophthalmus>
Is anybody familiar with there being an ethernet problem on the a10 and the debian kernel?
leio_ has quit [Read error: Connection reset by peer]
leio has joined #linux-sunxi
Andy-D_ has joined #linux-sunxi
Andy-D has quit [Ping timeout: 272 seconds]
<mossroy>
Did anybody succeed to have hardware AES encryption with dm-crypt (on mainline linux)?
<mossroy>
plaes : regarding performance, the benchmark at the end of http://sunxi.montjoie.ovh/ seems to give better results? (But I don't know on which CPU it has been done)
<plaes>
probably A20
<mossroy>
Based in this benchmarks, it seems slower with 128-bit key, but faster with 256-bit, right?
<plaes>
which algo? :P
hypophthalmus1 has joined #linux-sunxi
hypophthalmus has quit [Quit: Leaving.]
<plaes>
ah.. it was DMA that sucked
<mossroy>
plaes : sorry. AES-CBC
<hypophthalmus1>
So I compiled a kernel for my Mele A1000 and booted it. After the starting kernel message, it clears the screen and displays the penguin in the corner... but then, nothing.
<plaes>
what's you kernel command line?
<plaes>
(aka u-boot commands used to load the kernel?)
<mossroy>
plaes : with the patch applied, dmesg gives :
<mossroy>
[ 1.148694] sun4i-ss 1c15000.crypto-engine: no reset control found
<mossroy>
[ 1.156470] sun4i-ss 1c15000.crypto-engine: Die ID 0
<mossroy>
cat /proc/crypto | grep sunxi gives nothing, even after a modprobe sun4i-ss
<plaes>
can you paste whole proc crypto output?
<plaes>
also, grep sun4 ;)
<plaes>
because algorithms are *-sun4i-ss
<mossroy>
plaes : yes, grep sun gives several -sun4i-ss drivers :-)
<mossroy>
cool
<plaes>
haha..
<mossroy>
Thanks plaes
<plaes>
hypophthalmus1: no idea, sorry
<mossroy>
cryptsetup benchmark still does not gives me an error, but I suppose it's a missing kernel option :
<mossroy>
Required kernel crypto interface not available.
<mossroy>
Ensure you have algif_skcipher kernel module loaded.
atsampson has quit [Ping timeout: 252 seconds]
<mossroy>
plaes : ok after adding the kernel option, I have 26.2MB/s on aes-cbc (128 or 256 bit), instead of 14.9 (128-bit) and 12.3 (256-bit) on kernel 3.4 without hardware acceleration
<mossroy>
Based on cryptsetup benchmarl
<mossroy>
Not so bad!
<mossroy>
Thanks again plaes and apritzel
<KotCzarny>
mossroy: what is the cpu usage at the time?
<mossroy>
KotCzarny : I'll test that after lunch
interrobangd has joined #linux-sunxi
<plaes>
dude.. it's already evening here ;)
<KotCzarny>
ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html
<plaes>
:)
<plaes>
so bascially one cannot leave for lunch :P
<jelle>
why would you ever leave
<KotCzarny>
~hotel california tune tunes in~
orly_owl has quit [Quit: leaving]
apritzel has joined #linux-sunxi
<montjoie>
happy to see sun4i-ss happy user
<montjoie>
mossroy: the benchmark was done on A20
<plaes>
montjoie: any idea whether that patch has made mainline?
<apritzel>
hypophthalmus1: so to get this right: do you see messages on the serial console?
<apritzel>
hypophthalmus1: you don't have any "console=tty0" on your command line, so the kernel does not output anything there?
<hypophthalmus1>
I only have it hooked up to a monitor at the moment... so I guess that explains it?
<apritzel>
ah, so you enter the u-boot commands on a keyboard and monitor console?
<apritzel>
how modern ;-)
<apritzel>
hypophthalmus1: so does adding console=tty0 help?
<hypophthalmus1>
Yes, now I can see the kernel panic error.
<apritzel>
;-)
interrobangd has quit [Quit: Leaving]
<longsleep>
apritzel: Hey, i have the Pine64 running fine with Linux 3.10 from the BSP now - only thing missing to be somewhat usable is networking. Do you have any clue what driver i need? I was thinking the BSP Kernel would have it ..
<apritzel>
sorry: BSP 3.10: wrong number
<apritzel>
seriously, don't waste your time with that
<longsleep>
:) well i can boot Arch Linux with it
<apritzel>
AFAIK the Android image also has issues with (Gigabit) Ethernet
<apritzel>
longsleep: sure, why should userland be an issue?
zoobab_ has quit [Ping timeout: 250 seconds]
<longsleep>
yeah i read about that - but what i do not get what Kernel driver it is using
<longsleep>
apritzel: Because of the mmc problem. Or have you been able to figure out the problem?
<apritzel>
I started ported this driver to upstream - and found some issues in there
<apritzel>
(the Ethernet driver)
<longsleep>
apritzel: anyhow my build environment now boots your Kernel and the 3.10 BSP Kernel with the same U-Boot
<apritzel>
longsleep: can you try to debug this mmc issue with the upstream kernel?
<apritzel>
it works with my first hacked 4.4-based kernel
<longsleep>
apritzel: sure, which tree should i use?
<apritzel>
a64-v1
<apritzel>
so far
<apritzel>
I traced it down to an regulator issue
<apritzel>
which is a bit weird, since a fixed-regulator should be no problem
<longsleep>
right, thats the one which does not find the mmc device. If you would tell me what i should try then i can surely do it. Unfortunately i have not much knowledge about regulators or the dt in general
<apritzel>
the last thing I saw is the regulator does not seem to be detected
zoobab has joined #linux-sunxi
<apritzel>
so can you add pr_info's into the code which probes the fixed-regulator?
<apritzel>
apparently it is not even registered
<longsleep>
sure let me try to find that code
<apritzel>
in debugfs there should be something which lists you the regulators
<mossroy>
plaes : sorry, I meant dinner, not lunch. I'm in France
<montjoie>
plaes: which patch ? the patch for solving "failed to register md5" ?
<longsleep>
apritzel: / # cat /sys/kernel/debug/regulator/regulator_summary regulator use open bypass voltage current min max
<montjoie>
mossroy: ok we speak about the same patch
hypophthalmus1 has quit [Read error: No route to host]
hypophthalmus has joined #linux-sunxi
atsampson has joined #linux-sunxi
<longsleep>
apritzel: ok i changed the dt and now have: / # cat /sys/kernel/debug/regulator/regulator_summary regulator use open bypass voltage current min max
<longsleep>
but also sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
<longsleep>
sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
<mossroy>
KotCzarny : during cryptsetup benchmark --cipher aes-cbc, the CPU is almost 100% on cryptsetup
<KotCzarny>
so cpu is still heavily used for it
<mossroy>
Yes, that's strange
reinforce has quit [Quit: Leaving.]
<mossroy>
montjoie, is there a way to check that hardware encryption is really used? (with cryptsetup benchmark)
<apritzel>
longsleep: vqmmc is optional
<apritzel>
(for highspeed transfers)
<apritzel>
not supported by SD cards AFAIK
<longsleep>
apritzel: yeah i figured that in the meantime - stil now i see the regulator but no mmc still
<longsleep>
apritzel: digging deeper
<apritzel>
thanks, very helpful ...
<apritzel>
I am kneedeep in preparing v2 (addressing all those comments I got)
<longsleep>
apritzel: yeah mainlining is like that - your work is greatly appreciated
<hypophthalmus>
Hooray! I compiled lots of things as modules, but not the ethernet driver, and it works. For reasons that will remain mysterious to me.
<hypophthalmus>
Thanks for your help, apritzel.
avph has quit [Ping timeout: 240 seconds]
hypophthalmus has quit [Quit: Leaving.]
<apritzel>
longsleep: what did you actually change in the DT to make the fixed regulator appear?
<longsleep>
mhm without the reset it seems to crash more than not
<apritzel>
well, removing the reset lines would be a kludge anyway ...
<apritzel>
longsleep: if you still have time and feel like it, you could add some debug output to the sun6i-a31-ahb1-reset driver
<apritzel>
to see what's going on there
<longsleep>
apritzel: yes, i can do that
<longsleep>
apritzel: btw, for some reason two getties are started with your kernel. Any idea why?
<apritzel>
gettys are launched from userland
<apritzel>
is its because of the four serial lines in the DT?
<longsleep>
yeah i have added a getty in userland systemd manually, maybe systemd checks the DT and starts one on itself as well
bonbons has quit [Quit: Leaving]
<longsleep>
apritzel: so the problem seems to be that sunxi_reset_init of reset-sunxi.c is never called
mossroy has quit [Quit: Quitte]
<apritzel>
do you see it getting compiled? (reset-sunxi.o in your build tree)
<longsleep>
yes
<apritzel>
aha!
<apritzel>
this ahb reset is a different beast
<longsleep>
oh?
<apritzel>
it only gets initialized by call from arch/arm/mach-sunxi/sunxi.c
<longsleep>
oh
<longsleep>
32bit only
<apritzel>
indeed
<apritzel>
and there is no equivalent in arm64
<apritzel>
need to find a solution which doesn't upset all maintainers again ;-)
<longsleep>
fun
<apritzel>
thanks a ton anyway for finding this!
<longsleep>
apritzel: sure no problem - you are doing the difficult work :)
paulk-collins has quit [Ping timeout: 256 seconds]
* apritzel
is tempted to procrastinate into testing I2C first ...
<longsleep>
hehe do what you wish to do - its not that someone pays you for this isnt it? ;-)
<apritzel>
not really, but the door for 4.6 is closing next week
<apritzel>
also all those backers start getting their boards next week, I guess
<longsleep>
well - they are in for some disapointment i guess
<longsleep>
thats why i looked at the BSP kernel as well - if ethernet would work there it would be at least something - i could release an arch image with the reset code commented out as well :D
<apritzel>
I'd rather avoid releasing something with a DT that is known to change or will not work with future kernels ...
<apritzel>
(again, that is ;-)
<longsleep>
apritzel: not the change in the DT as this leads to crashes - rather the hack which does not defer if reset says to defer
<longsleep>
but in any case, neither your kernel nor the BSP kernel has given me ethernet yet - so that is my priority in prototyping now
<apritzel>
the Ethernet MAC in the A64 (and in the H3) are a new IP block
<apritzel>
so there is no driver yet, but it's being worked on (for the H3)
<longsleep>
yes - but there should be a driver in the BSP, shouldnt it?
<apritzel>
yes
<apritzel>
and I started to port this over to mainline
<apritzel>
it compiles, but there are general problems
<apritzel>
like the regulators
<apritzel>
by default the PHY does not seem to get powered
<apritzel>
so we have to do this from the driver
<apritzel>
which is pretty standard, but ...
<apritzel>
we don't have a regulator driver yet :-(
<longsleep>
yes - there is only so many things one can do in limited time
<apritzel>
so far all the other peripherals are powered on on but
<apritzel>
*boot
<apritzel>
frankly serial, MMC and Ethernet are the only peripherals I need ;-)
<longsleep>
yes me to :)
<apritzel>
if you are still not sleepy ....
<apritzel>
USB could be a low hanging fruit
<apritzel>
it could just work, haven't tried
<longsleep>
i have cuba libre, not getting sleepy but drunk :-P
<apritzel>
brings you into the mood for the BSP kernel, I guess ...
<longsleep>
hehe
<longsleep>
USB works with the BSP kernel :D
<apritzel>
seriously, it may just work by adding the proper nodes to the DT
<longsleep>
yeah i can try for sure - but did i mention that i do not know much about DT :)
<apritzel>
but as the H3 is different in regards to USB, I didn't try this
<longsleep>
thats why i usually get somewhere - but it feels awkward
<apritzel>
can you find some Allwinner SoC which has two USB ports, one of which is OTG?
<longsleep>
sure i can check the existing DTs for examples
<apritzel>
maybe the addresses can be a hint
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 256 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<apritzel>
longsleep: just as an incentive: USB would enable these Ethernet USB adaptors ;-)
<longsleep>
apritzel: true - i am just looking and USB seems to have a ton of DT entries
clonak has quit [Remote host closed the connection]
<apritzel>
yeah, guess why I didn't try it yet :-P
Nacho___ has joined #linux-sunxi
clonak has joined #linux-sunxi
Nacho____ has quit [Ping timeout: 240 seconds]
yann|work has joined #linux-sunxi
yann|work has joined #linux-sunxi
<longsleep>
apritzel: i think this is to much for tonight - tons of gates and pins missing to even compile the DT - i think i can trial and error that until next year and it will not work
<longsleep>
apritzel: btw, Kernel just crashed again
<longsleep>
apritzel: null-ptr-deref on address again - does not seem to be a solution to go without initializing the reset stuff
<apritzel>
longsleep: anyway, thanks a lot for the MMC debugging!
FDCX has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
<Deskwizard>
mripard: it wont be for a while but, re: A31s audio: can I use sun4i as base as you did for some other things, do you think that is the way to go?