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
Net147 has quit [Ping timeout: 256 seconds]
Net147 has joined #linux-sunxi
atenart has quit [Ping timeout: 272 seconds]
atenart has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
Wizzup has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
apritzel has quit [Ping timeout: 248 seconds]
khuey is now known as khuey|away
orly_owl_ has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
sprado has quit [Ping timeout: 272 seconds]
<wens> i must have tunnel vision of something
<wens> vishnu: thanks
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
hipboi has joined #linux-sunxi
arokux_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 250 seconds]
ninolein has joined #linux-sunxi
arokux has quit [Ping timeout: 276 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vagrantc has quit [Changing host]
vagrantc has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 272 seconds]
p1u3sch1_ has joined #linux-sunxi
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
huawei is now known as Shirasaka-Hazumi
IgorPec has joined #linux-sunxi
NiteHawk has quit [Remote host closed the connection]
FDCX has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
hipboi has quit [Quit: This computer has gone to sleep]
iamfrankenstein has joined #linux-sunxi
clonak has quit [Remote host closed the connection]
clonak has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
reinforce has joined #linux-sunxi
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
tkaiser has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
vishnup has joined #linux-sunxi
avph has quit [Ping timeout: 240 seconds]
reinforce has quit [Ping timeout: 240 seconds]
atenart has quit [Ping timeout: 240 seconds]
avph has joined #linux-sunxi
pekka30 has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
pekka30 has joined #linux-sunxi
premoboss has joined #linux-sunxi
atenart has joined #linux-sunxi
arokux_ has quit [Ping timeout: 264 seconds]
premoboss has quit [Ping timeout: 252 seconds]
yann|work has joined #linux-sunxi
vishnu_ has joined #linux-sunxi
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
<tkaiser> mkimage is your friend ;)
<NiteHawk> see http://linux-sunxi.org/Mainline_U-Boot#Boot for instructions
<antonva> Thanks.
<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
<tkaiser> In this horrible forum http://bananapi.com/index.php/forum/general user db260179 claims he was able to resolve that partially with his OpenWRT image.
<antonva> ick
<antonva> plaes: Updated the wiki
sprado has joined #linux-sunxi
domidumont has quit [Quit: Leaving.]
ricardocrudo has joined #linux-sunxi
sprado has quit [Quit: Saindo]
leio has quit [Ping timeout: 248 seconds]
leio has joined #linux-sunxi
<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.
dev1990 has joined #linux-sunxi
premoboss has quit [Ping timeout: 272 seconds]
premoboss has joined #linux-sunxi
premoboss has quit [Ping timeout: 240 seconds]
premoboss has joined #linux-sunxi
leio_ has joined #linux-sunxi
leio has quit [Ping timeout: 276 seconds]
avph has quit [Ping timeout: 240 seconds]
avph has joined #linux-sunxi
<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]
<buZz> Ntemis: why not ask the vendor?
<buZz> or just enable both of them
<Ntemis> because vendor is shit
<Ntemis> am looking for mainline kernel support
vbmithr has joined #linux-sunxi
<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]
apritzel has joined #linux-sunxi
IgorPec has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 264 seconds]
p1u3sch1 has joined #linux-sunxi
mossroy has joined #linux-sunxi
FDCX has joined #linux-sunxi
yann|work has quit [Ping timeout: 240 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
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> Based on http://sunxi.montjoie.ovh/ , it is supported since kernel 4.3
<mossroy> I compiled 4.4.1 and 4.3.5 but did not manage to have anything in cat /proc/crypto | grep sunxi
<mossroy> I used the sunxi_defconfig, following http://linux-sunxi.org/Mainline_Kernel_Howto
Andy-D__ has joined #linux-sunxi
<mossroy> montjoie : if you're around, you might have an idea?
<mossroy> (I'm using an Olinuxino A20 Micro)
Andy-D_ has quit [Ping timeout: 264 seconds]
<KotCzarny> modprobe ss ?
paulk-collins has joined #linux-sunxi
Andy-D__ has quit [Ping timeout: 240 seconds]
paulk-collins has quit [Client Quit]
<mossroy> modprobe: FATAL: Module ss not found
<KotCzarny> i think its sun4i-ss
<mossroy> Is it simply because I did not compile and transfer the modules?
<mossroy> modprobe sun4i-ss does not give any error
<mossroy> But still no sunxi in /proc/crypto
yann|work has joined #linux-sunxi
<apritzel> mossroy: anything in dmesg regarding this module?
<apritzel> does lsmod list it?
paulk-collins has joined #linux-sunxi
<mossroy> [ 1.154022] sun4i-ss 1c15000.crypto-engine: no reset control found
<mossroy> [ 1.161725] sun4i-ss 1c15000.crypto-engine: Die ID 0
<mossroy> [ 1.166754] sun4i-ss 1c15000.crypto-engine: Fail to register md5
<mossroy> [ 1.172806] sun4i-ss: probe of 1c15000.crypto-engine failed with error -22
<mossroy> lsmod does not list anything
<apritzel> mossroy: do you have an up-to-date .dtb?
viccuad has quit [Quit: WeeChat 1.4]
<mossroy> I use the sun7i-a20-olinuxino-micro.dtb that was generated by my kernel 4.4.1 compilation
<mossroy> And my boot.cmd is as follows : fatload mmc 0 0x46000000 zImage
<mossroy> fatload mmc 0 0x49000000 sun7i-a20-olinuxino-micro.dtb
<mossroy> setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait paa
<mossroy> nic=10 ${extra}
<mossroy> bootz 0x46000000 - 0x49000000
<mossroy> mmmh, I see a typo in this boot.cmd : I check if it's the reason
<apritzel> mossroy: can you add: pr_info("sun4i-ss-core: "PTR_ERR(ss->reset));
<apritzel> gaa
yann|work has quit [Ping timeout: 264 seconds]
<apritzel> pr_info("sun4i-ss-core: devm_reset_control_get_optional returns %d\n", PTR_ERR(ss->reset));
Andy-D__ has joined #linux-sunxi
<apritzel> just before the error message in drivers/crypto/sunxi-ss/sun4i-ss-core.c?
<apritzel> reset control seems to be optional, but there is some other error here, which the error message does not tell
<apritzel> mossroy: typo? paanic? shouldn't matter
<mossroy> apritzel : Yes : I fixed the typo and it did not change anything
<apritzel> also if you get this far (shell), any issue is probably not loading/command line related anymore
<mossroy> apritzel : I can add the pr_info line, but I think it's more probably a mistake I did than a bug...
<mossroy> apritzel : should I insert it before the "no reset control found", or somewhere else?
<apritzel> yes, before
<mossroy> OK : it gives a compilation warning about int and long int, but compiles
yann|work has joined #linux-sunxi
<apritzel> yeah, sorry, %ld
<plaes> mossroy: you should add some extra patch
<apritzel> also two lines printing the content of err before the "Fail to register"
<mossroy> The pr_info prints "sun4i-ss-core: devm_reset_control_get_optional returns -22" in dmesg
<mossroy> plaes : which patch are you mentioning?
<plaes> looking for it...
<plaes> but sunxi-ss is really slow
<plaes> even slower than cpu :(
yann|work has quit [Ping timeout: 240 seconds]
apritzel has quit [Ping timeout: 248 seconds]
<mossroy> plaes : could it be https://lkml.org/lkml/2015/11/16/46 ?
<plaes> yeah ^^ :)
<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
<hypophthalmus1> The uboot commands looks like this: http://pastebin.com/0ySgXUtK
<mossroy> But still no sunxi in /proc/crypto
<plaes> mossroy: whaat.. ?
<plaes> weird
<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
<longsleep> ------------------------------------------------------------------------------- regulator-dummy 0 0 0 0mV 0mA 0mV 0mV
<longsleep> so that is the problem? I did not add pr_info's yet
<montjoie> if this one, it will be in 4.5, and for stable I do not know
<apritzel> longsleep: yeah, it should list something with reg_vcc3v3
<longsleep> ok let me add some debug - i can probably find the code myself, but if you have a hint i would be greatful :)
<mossroy> montjoie : I think he's talking about https://lkml.org/lkml/2015/11/16/46 , which I needed to apply to have sun4i-ss drivers in /proc/crypto
<apritzel> longsleep: git grep regulator-fixed drivers/regulator
<longsleep> apritzel: cool thanks
<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> ------------------------------------------------------------------------------- regulator-dummy 0 0 0 0mV 0mA 0mV 0mV vcc3v3 0 0 0 3300mV 0mA 3300mV 3300mV
<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?
avph has joined #linux-sunxi
<longsleep> apritzel: the problem is now that devm_reset_control_get_optional does never succeed
<longsleep> devm_reset_control_get_optional(&pdev->dev, "ahb")
<longsleep> trying to figure out what this actually does now
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
avph has quit [Ping timeout: 240 seconds]
IgorPec has quit [Ping timeout: 252 seconds]
avph has joined #linux-sunxi
interrobangd has joined #linux-sunxi
<apritzel> probably missing a reset pin
<apritzel> but as it says on the tin: optional
<apritzel> longsleep: DT> ah, right, that child node issue, I was already suspecting something like this
<longsleep> apritzel: so you have an idea how to fix this?
<longsleep> apritzel: just not doing the optional call gives a null-ptr-deref
bonbons has joined #linux-sunxi
<longsleep> apritzel: ah now it works, i commented only the call to reset but not the assignment - just booted fine into Arch
<longsleep> apritzel: lots of mmc debugging output now, getting /dev/kmsg buffer overruns
* longsleep is turning off mmc debug
<apritzel> yeah, mmc debugging can be annyoing if everything finally works ;-)
<longsleep> and now it crashed
<longsleep> [root@alarm ~]# Bad mode in Synchronous Abort handler detected, code 0x86000004 -- IABT (current EL)
<apritzel> that may be due to overheating?
<longsleep> uh
<longsleep> did not check
<longsleep> it worked fine for hours with the BSP kernel
<longsleep> but it did not do anything
<longsleep> and now it was logging like crazy
<apritzel> or it could be due to the MMC actually being driven wrong with my kernel ;-)
<apritzel> as the MMC clock part has changed a bit in the A64
<longsleep> i disabled mmc debugging - lets see
<apritzel> I hoped we would get away for the beginning with pretending we are compatible to the old MMC driver
<longsleep> it boots just fine from emmc, so i think it is unlikely that there is something wrong there
<longsleep> looks good to me now
<apritzel> so you commented the reset lines?
<longsleep> yes
<longsleep> /*if (PTR_ERR(host->reset) == -EPROBE_DEFER)
<longsleep> return PTR_ERR(host->reset);*/
<longsleep> just those two
<apritzel> can you pr_info PTR_ERR(host->reset)
<apritzel> to get the error number
<longsleep> sure, hold on - in the mean time http://paste.ubuntu.com/15046487/ full dmesg output
<longsleep> the xxx lines are in the sunxi_mmc_resource_request function, 3 beeing before the rest and 3.1 after
<longsleep> reset
mpmc has quit [Ping timeout: 240 seconds]
mpmc has joined #linux-sunxi
<longsleep> apritzel: xxx 3.0 host->reset gives: -517
<longsleep> apritzel: i added pr_info("xxx 3.0 host->reset gives: %ld\n", PTR_ERR(host->reset));
<apritzel> mmh, so that's EPROBE_DEFER
<longsleep> yeah, if reset returns that it aborts with that as result
<longsleep> apritzel: system works fine, did not crash again. So i assume it was heat related
Andy-D__ has quit [Ping timeout: 264 seconds]
<apritzel> but as it's called DEFER, it should come back later once that reset gets registered
<apritzel> which mean that nevers happens, so MMC is on the deferred list forever
<longsleep> apritzel: i think it comes back once, but deferrs again
<longsleep> apritzel: let me confirm that
<longsleep> apritzel: confirmed, it runs through that code twice, both times returning -517
<longsleep> so defer seems to work ,but second time it still wants to defer
<apritzel> everytime _any_ driver successfully registers, it probes all drivers on the deferred list again
<apritzel> even if this new driver is totally unrelated
<longsleep> well, if i remove the reset from the
<longsleep> forget it, now it crashed :)
<longsleep> i just removed the reset from the device tree
<longsleep> then it returns -2, and gos on but later crashes
<apritzel> do you have my very first DT?
<longsleep> uhm no i deleted it :/
<apritzel> there it somehow worked, I was wondering what I did there about the reset line ...
<longsleep> did you commit that to git? I can check there
<apritzel> I just looked, I guess not
<apritzel> as it was a big hack
<longsleep> mhm too bad :/
<apritzel> mmh, so in that one there is no reset line in the mmc node at all
<longsleep> i just tried that and it crashed while booting, let me boot again
<apritzel> have you removed both reset-names and resets?
<longsleep> yes
<longsleep> ok now it booted
<longsleep> probably heat again
<longsleep> apritzel: without both these lines, the reset value is -2 and it works just fine
<longsleep> well now it crashed again
<longsleep> wapper/2[0]: undefined instruction: pc=ffffffc00014f664
<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
<apritzel> well, it's the usual copy & paste job, isn't it?
<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
<longsleep> apritzel: full stack here: http://paste.ubuntu.com/15048609/
<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?
ricardocrudo has quit [Ping timeout: 240 seconds]
pmattern has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]