<ssvb>
lots of "witch hunt style" news badmouthing Allwinner mean that the closed source proponents inside of Allwinner will likely gain even more power
<ssvb>
this might throw a really big wrench into the efforts of the Pine64 folks, who are trying to convince Allwinner that open sourcing libdram and other code for A64 would be a good thing for everyone
dave0x6d has quit [Ping timeout: 250 seconds]
<ssvb>
couldn't these f*ckers at least write something positive about having the kernel sources and being able to audit them?
<NiteHawk>
hmm... kernel 4.6-rc7 sunxi_defconfig is missing "CONFIG_SYSVIPC=y", while multi_v5_defconfig and multi_v7_defconfig have it
<apritzel>
NiteHawk: isn't there some config overlay feature in the kernel?
luoyi has joined #linux-sunxi
<luoyi>
sun4i-codec driver is working correctly in 4.5.3 ?
<oliv3r>
mripard: where is the arm git tree that i can use to extract the hash for the proper commit reference?
<luoyi>
I enabled the codec and aplay a wav file give me : aplay: pcm_write:2004: write error: Input/output error
<NiteHawk>
apritzel: i'm building my own config based on that using scripts/kconfig/merge_config.sh - not a problem. but i just ran into a quirk using a gentoo-flavored kernel that 'silently' introduced a dependency on SYSVIPC, and ended up with a linking failure (undefined references) for vmlinux :P
<NiteHawk>
so i just wondered if it should be set by default across all three *_defconfigs provided
<apritzel>
yeah, I was wondering whether we should base sunxi_defconfig on top of multi_v7_defconfig to avoid those issues
<apritzel>
arnd was asking for something like this for kvm_defconfig for ARMv7
<apritzel>
NiteHawk: and to answer your question: yes, it should be set
<NiteHawk>
apritzel: guess that means i'm supposed to submit a patch... :D
<apritzel>
NiteHawk: well, I think so, but the question is whether it's worth to keep sending patches to keep the sunxi_defconfig up-to-date (for instance if multi_v7_defconfig gains something)
<mripard>
oliv3r: it depends on where the commit has been applied
<apritzel>
or whether we should make sunxi_defconfig some kind of diff against multi_v7_defconfig
<oliv3r>
mripard: well you asked me to fix my commit reference, and I didn't know which commit reference i needed so only used the subject :( sorry!
<mripard>
NiteHawk: if it's missing, please send a patch
<apritzel>
NiteHawk: so that sunxi_defconfig takes multi_v7_defconfig, adds features and possible removes others
<mripard>
apritzel: the point of sunxi_defconfig all along has been to not pull all the bloat multi_v7 brings
<mripard>
so it would kind of defeat the purpose
<wens>
oliv3r: the proper format is """commit <git hash> ("first line of commit message")"""
<wens>
oliv3r: and you'd use the hash from a tree that is destined for mainline, such as mripard's tree, or arm-soc
<apritzel>
mripard: I see that idea, I am just wondering if we miss something useful by doing so and whether it's really still useful (read: non-bloated compared to multi_v7) these days
<apritzel>
mripard: all sunxi SoCs are ARMv7, right?
<apritzel>
with the smallest one being based on a Cortex-A8?
<luoyi>
mripard: why can't we just set the sun4i-codec's dts status to okay by default. does the sun4i-codec driver or the dts file needed to be modified for every different boards ?
<oliv3r>
wens: yeah but i don't know the git hash, and using my local hash probably is wrong :)
<wens>
oliv3r: git.kernel.org has cgit, please look it up
<wens>
or fetch the related trees from git.kernel.org directly
<NiteHawk>
mripard, apritzel: to reflect that idea, the multi_v?_defconfig files should probably based on a 'minimalistic' sunxi_defconfig. unfortunately it looks like there's no simple way to "include" these configs into each other?
<wens>
luoyi: boards might not use it, instead opting for I2S for "better" sound
<NiteHawk>
..be based
Worf has quit [Quit: Konversation terminated!]
ricardocrudo has joined #linux-sunxi
<apritzel>
NiteHawk: this is the question, I dimly remember there was something
<wens>
luoyi: one good example would be the A20 based guitar effects pedal on kickstarter
<oliv3r>
wens: but it's not applied on kernel.org as far as I understood, but i'll double check
<wens>
oliv3r: i not talking about linus' tree
<luoyi>
wens: the i2s driver is still not in the mainline kernel tree now.
<wens>
oliv3r: git.kernel.org hosts a whole bunch of peoples repositories, including mripard's
<wens>
luoyi: that is another problem
<luoyi>
wens: and I'm using a bpi m1+, want to enable the integrated codec
<oliv3r>
wens: but i think mripard ment the upstream branch on which it was applied, my guess now is armsoc
<wens>
luoyi: then (send a patch to) enable it in the board dts?
<wens>
oliv3r: yes
<luoyi>
wens: I've add status='okay' in the m1+'s dts file
<wens>
everything is muted, nothing will play (ALSA will block)
<wens>
unmute Power Amplifier DAC and Power Amplifier Mute
<mripard>
luoyi: some boards might or might not use it, so, yeah, we have to enable it on all the boards that make use of it
<luoyi>
in the alsamixer , I can just tuning 'Power Amplifier', I can't tuning anything other
<wens>
luoyi: press 'm' to toggle mute
<mripard>
NiteHawk: I don't really know what that option is about to be honest, so I can't really say
<wens>
luoyi: you should check the manpage
<luoyi>
m just give me 00, and up / down doesn't work
<wens>
mripard: SYSV IPC is ancient version of shared memory , semaphores , (and one other thing i forgot)
<wens>
luoyi: OO is unmuted, MM is muted
<mripard>
oh, so it is what it obviously is
<mripard>
then yeah, we should add it
<wens>
luoyi: as i said, read the manpage for alsamixer
<luoyi>
wens: okay. I understand. I should unmute 'Power Amplifier Mixer' , and adjust the volume through 'Power Amplifier'
<wens>
it helps if you could look at the audio codec diagram in the A10 or A20 user manual to understand what the controls are
<wens>
you need an unmuted path from the DAC to the output
<luoyi>
OK. it sounds good now. thank you for your explaination.
<wens>
:)
<luoyi>
and I just find the integrated codec sounds really bad ......
<luoyi>
hope we can have a mainline i2s driver quickly
<wens>
i'm using an earphone, seems ok
<luoyi>
I've used a rpi2+es9023 dac board as my music playbox for some time now, and want try to make use of the allwinner board replace it
<luoyi>
I can hear some noise while playing music
<luoyi>
I'll try to change music file and give it retry
<wens>
montjoie: half way through my emac/ephy rework
<KotCzarny>
luoyi: noise is usb activity mostly
<KotCzarny>
bad separation
<luoyi>
KotCzarny: you mean usb power noise ?
<KotCzarny>
nope, usb activity noise
<luoyi>
usb port is empty now
<KotCzarny>
onboard wifi?
<luoyi>
yes
<luoyi>
I'm using onboard wifi
<KotCzarny>
onboard wifi is usb?
<luoyi>
i
<luoyi>
it's sdio
<KotCzarny>
Processing Time remaining: 10 days 23 hours 59 minutes
<KotCzarny>
11 days, hrm, it will arrive when im not available :/
<KotCzarny>
unless its only processing ie. making and packing
<wens>
sdio clock frequencies are still in the audible range though
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
<KotCzarny>
try observing if wifi activity correlates with the noise
Andy-D has quit [Read error: Connection reset by peer]
Andy-D has joined #linux-sunxi
TheSeven has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
<speakman>
Now running kernel 4.3 on A20. First wierd thing I encounter is the unability to change direction of an gpio pin.
<speakman>
I've exported gpio19 (echo 19 > export) but trying to change direction on it fail with "Unknown error 517"
<speakman>
Any idea what may cause that?
<speakman>
It even fail when trying to gpio_direction_input() in a kernel driver
<speakman>
(even though it seems to already be an input)
leio has quit [Ping timeout: 260 seconds]
<speakman>
Oh, pin enum has changed severely.
Worf has joined #linux-sunxi
fl_0 has quit [Quit: STRG + Q]
pmattern has joined #linux-sunxi
fl_0 has joined #linux-sunxi
fredc has quit [Ping timeout: 244 seconds]
IgorPec has quit [Ping timeout: 246 seconds]
<willmore>
speakman, I know very little about that subject, but one thing I did notice from others who have discussed something similar here in the past is that you need to make sure the pins you want to use aren't used by anthing else in the DT.
<willmore>
But that's about all I know.
engideavr has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
Worf has quit [Quit: Konversation terminated!]
IgorPec11111 has joined #linux-sunxi
adj__ has quit [Quit: Leaving]
adj__ has joined #linux-sunxi
IgorPec11112 has joined #linux-sunxi
IgorPec11111 has quit [Ping timeout: 252 seconds]
<MoeIcenowy>
speakman: I'm afraid there's no gpio 19
IgorPec11113 has joined #linux-sunxi
<MoeIcenowy>
(Bank No. - 1 ) * 32 + Pin No. seems to be a common calculation for all the mainline SoCs...
IgorPec11113 has quit [Read error: Connection reset by peer]
<MoeIcenowy>
for example, my tablet's gsl1680 touchscreen should be enabled at PH1
<NiteHawk>
btw: pine64 has arrived. a big thank you to apritzel! :)
<ssvb>
NiteHawk: congrats, this was really fast
<NiteHawk>
i'll test your fel support patch later and plan to merge it afterwards - do you consider it stable / 'final' enough for that?
<apritzel>
NiteHawk: enjoy, looking forward to your USB, Ethernet and HDMI support patches :-P
<NiteHawk>
X)
<montjoie>
crypto engine aes support complete, now working on hash
<montjoie>
will I resist to bench it...
<ganbold>
montjoie: which SoC?
<montjoie>
H3
<KotCzarny>
bench with cpuburn!
<ganbold>
nice
<montjoie>
but A83T is a bit similar
IgorPec11113 has quit [Ping timeout: 265 seconds]
<montjoie>
A64 is same as H3 (just +/- some algos)
<ganbold>
montjoie: updated benchmark page would be nice
<montjoie>
yes even for A20 I need it
<ssvb>
montjoie: Cortex-A53 in A64 has roughly twice faster NEON per MHz compared to Cortex-A7 in H3, so the software crypto should have a nice speed boost
<ganbold>
someone should make arm64 board with 2 ethernet that can be used in networking
<KotCzarny>
allwinner is bad for bandwidth related stuff
<apritzel>
ssvb: montjoie: also would be interesting to see how the crypto extensions perform on the A53
<montjoie>
ssvb: I dont think the crypto engine use neon
<KotCzarny>
tkaiser: there are more differences between opipc and opi+2e
zuikis has joined #linux-sunxi
yann has quit [Ping timeout: 246 seconds]
<ssvb>
tkaiser: it's best to compare the schematics and/or fex files to be sure
engideavr has quit [Quit: Konversation terminated!]
<ssvb>
tkaiser: but yes, the dram vendor is different and also the placement of the dram chips is different on the pcb
<tkaiser>
ssvb: Hmm... it took Steven always some time to release schematic for a new board. Lets hope the best.
fredy has joined #linux-sunxi
<tkaiser>
ssvb: And I'm not aware that Xunlong released fex files for new boards (at least none for OPi One)
<tkaiser>
Figuring out what was needed to drive the new voltage regulator was trial&error and now we have a fex file in Armbian Github repo
<ssvb>
did they make any statements about the software compatibility with other boards?
<tkaiser>
Fortunately the rest remained the same compared to Orange Pi PC (minus 2 USB ports that are still there as solder points)
<tkaiser>
ssvb: Nope. Unfortunately not. Not even mentioned whether the new WiFi chip is compatible: 8189ETV vs. 8189FTV now
<ssvb>
the first users will probably have some fun trying to make these boards work properly, as usual
<KotCzarny>
:)
<KotCzarny>
my guess opipc fex will work out of the box
<tkaiser>
ssvb: I'm not that concerned since Steven is smart. All 9 (or 10?) H3 based Orange Pi share most pin mappings. Only expections: network and USB hub or not
<tkaiser>
KotCzarny: Nope, different Ethernet PHY.
<KotCzarny>
tkaiser, apart those changed parts
<tkaiser>
Read the link to Armbian forum link above.
staplr has joined #linux-sunxi
<KotCzarny>
tkaiser: for now its waiting game, 7-15 days of delivery
<KotCzarny>
we will see what's up when the boards arrive
<tkaiser>
KotCzarny: I'll watch linux-sunxi wiki, you'll create the device page and submit first memtester result. Thx ;)
<KotCzarny>
unless you took some speedier shipping
<KotCzarny>
tkaiser: sure, will do
<KotCzarny>
if it boots ;)
<KotCzarny>
and i hope he didnt make any mistakes or had time testing it before offering on ali
dev1990 has joined #linux-sunxi
<KotCzarny>
and i belive 2e could be just a note on opi+2 page
<tkaiser>
KotCzarny: I'll prepare a fex file for OPi Plus 2E in the meantime and if you don't mind it would be great if you could give an Armbian image based on that a try then.
<KotCzarny>
sure
<dave0x6d>
KotCzarny: did allwinner contact you?
<KotCzarny>
dave0x6d: huh? why? nope
<dave0x6d>
KotCzarny: their press team contact me.
<dave0x6d>
*contacted
<tkaiser>
dave0x6d: Me2
<KotCzarny>
i dont have any blog, and there are no allwinner employees on irc here
<KotCzarny>
direct them here
<dave0x6d>
tkaiser: did they do the same thing and copy-paste the press release from their github repo?
<KotCzarny>
it would be intersting ;)
<dave0x6d>
KotCzarny: one sec, will do.
<KotCzarny>
ask for someone speaking at least basic english ;)
<tkaiser>
dave0x6d: Maybe the other way around. First sent the press release and then opened an issue with it in their own Github repo ;)
<dave0x6d>
oh oops, you're right.
<dave0x6d>
not sure why my mail lagged by so much.
<dave0x6d>
tkaiser: oh yeah there's no way this is a malicious backdoor. Just a very stupid debugging backdoor.
<tkaiser>
dave0x6d: Do you call this a 'backdoor'? Not a simple local privileges escalation?
<dave0x6d>
tkaiser: heh, imo it is a backdoor because they should be using su.
<nove>
i like this one, "Isn't this what Android users have always wanted?"
<dave0x6d>
the front door (su) works fine.
<tkaiser>
nove: But isn't it true? That's the first thing they ask for...
<dave0x6d>
I'm not an Android guy, but can't you just flash any ROM you want with su?
<nove>
yes is true, but this only got in the news because of the keywords "backdoor" and "root", and so
<tkaiser>
dave0x6d: No idea. I used Android once to test out Pine64 boot showstoppers. And that's it :)
<willmore>
montjoie, I have H3 and A64 boards, let me know if you want me to do any soak testing or anything.
rellla has quit [Ping timeout: 244 seconds]
<dave0x6d>
tkaiser: I asked jduck and he didn't know of any reason why they couldn't use su.
<dave0x6d>
nove: of course =)
<dave0x6d>
that wasn't accidental.
<dave0x6d>
brb, food.
<KotCzarny>
dave0x6d: laziness
rellla has joined #linux-sunxi
<KotCzarny>
also, it makes a real hole in the system, where su is a legitimate and secure (if configured right) tool
<dave0x6d>
KotCzarny: but... but.. how is using 'su - root' harder than 'echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug'?
Amit_t_ has quit [Quit: Page closed]
<KotCzarny>
because you should have to authenticate
<KotCzarny>
whereas that /proc/ file was wiritable by ANYONE
tipo has quit [Remote host closed the connection]
tipo has joined #linux-sunxi
<tkaiser>
KotCzarny: Just FYI. Someone mailed me that all OS images he used prior to Armbian on his Orange Pi PC had sudo enabled without authentication.
<tkaiser>
And IIRC this is also the case on the original Raspbian. But I might be wrong here
<KotCzarny>
tkaiser, yeah, laziness
<KotCzarny>
but its easier to reconfigure os than recompile kernel
<KotCzarny>
(and rebuild image as its often the case with those vendor provided ones)
<tkaiser>
KotCzarny: With Armbian it was 'apt-get upgrade && reboot'