<akaizen>
haha ive heard that so many times, actually getting that takes more time than what I am suggesting
<apritzel>
which may be already there, unless the SoC vendor is overly clever and keeps inventing new IP
<akaizen>
most boards dont use mainline uboot much less figuring out what they changed to make changes to add tftp / netboot
cptG has quit [Ping timeout: 276 seconds]
<apritzel>
that's why developing upstream U-Boot support is as crucial as getting the kernel to run
<akaizen>
tell that to every X Y Z SoC / board manufacturer and then get them to implement that
<apritzel>
unfortunately many SoC/board vendors didn't get this message yet
<akaizen>
I'll wait
<akaizen>
exactly ;p
<apritzel>
and that's why we are here ;-)
<akaizen>
it took them like 3-5 years just to believe in open source and look into working with mainline
<apritzel>
because I gave up waiting for them
<akaizen>
rk and aw just started doing that
<akaizen>
Anyway thanks apritzel for pointing me to sd-mux, that is really the closest solution we have in mind. SD emulaiton would be the best but this might do for now
<akaizen>
Also once you have an automated build system, the pace of development goes up like 10x
<apritzel>
akaizen: oh, btw. AFAIK agraf was working on SD emulation
<apritzel>
using a Beagle Bone Black with that fancy realtime processor
<apritzel>
most probably because he wanted to solve this very same issue for SuSE
<akaizen>
heh
<akaizen>
you should have said taht at the beginnig :)
<akaizen>
and if you understood the problem already why ask all the questions
<apritzel>
because SD emulation is quite tricky ;-)
<apritzel>
you have to be very quick in reacting on commands
<apritzel>
akaizen: and you wanted to have something that is already working
<apritzel>
(at least my understanding)
<akaizen>
anything worthwhile is usually tricky
<akaizen>
true, rather not invent something if a good solution already exists
sarietta has quit [Remote host closed the connection]
sarietta has joined #linux-sunxi
<akaizen>
apritzel: ah thats helpful to know, the SD micro controller needs to be fast.. so it sounds like microSD <-- microcontroller -- buffer --> usb ->> host computer
<apritzel>
definitely
<akaizen>
with USB 3, thats one fast SD card :)
sarietta has quit [Read error: Connection reset by peer]
<apritzel>
and even this MCU needs to be quick and real-time capable
sarietta has joined #linux-sunxi
<apritzel>
well, the speed would be most likely be limited by the SD emulation
<apritzel>
IIRC agraf said that he needed to bit bang the protocol to make an SD host controller happy
<akaizen>
really? i dont know much about the protocl but shouldnt the host only be sending read and write commands
<akaizen>
and teh sd card is actualy worrying about putting them on hte nand
<akaizen>
hence the bottleneck
<apritzel>
that's the theory, yes
<apritzel>
but in reality there seem to be strict (and short) timeout definitions to react on commands
<apritzel>
which is hard to fulfil with just a generic SPI controller implementation on any MCU / SoC
<apritzel>
and remember: most SoCs/MCUs just have a SD _host_ controller in hardware, not capable of SD device support
<apritzel>
so you _may_ be lucky with using the SPI controller, but need to bit bang the other pins SD cards use
<apritzel>
and this will only get you support for the 1-bit protocol
<akaizen>
Yes, I read some thing somehwere but thats super slow
<apritzel>
so to summarise: there may be easier solutions to solve this initial SoC/board bringup problem ;-)
<akaizen>
I've yet to find / hear of anything as universal or seamless
<akaizen>
but I'm def open to it
<akaizen>
The biggest hurdle I've heard is that the high speed SD protocl is propritary / tricky
<akaizen>
but this was all 2004-2012, now in 2016. the future is here! anything is possible!
<apritzel>
AFAIK the SD protocol is still proprietary :-(
<akaizen>
yea
<apritzel>
even in 2016 Tomorrowland ;-)
<akaizen>
how does the linux kernel implement it
<apritzel>
hardware covers this, AFAIK
<akaizen>
theoretically, I should be able to take my emulator plug it into my host sdcard reader and host usb and mount it and r/w to it to test it.. almost like al oopback device
<apritzel>
akaizen: well, you said it: "theoretically" ;-)
<apritzel>
akaizen: feel free to go ahead and develop this thing
<apritzel>
meanwhile I swap SD cards for the first month or so, then switch to USB protocols like FEL or even TFTP booting
<akaizen>
exponential vs linear acceleration ;)
<akaizen>
the better tools we have the farther and faster we can go
jernej_ has quit [Ping timeout: 244 seconds]
kaspter has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
<akaizen>
OLPC has a fully open source SD driver :)
Axl__ has joined #linux-sunxi
sarietta has quit [Remote host closed the connection]
Axl__ has quit [Ping timeout: 244 seconds]
sarietta has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
tsuggs has quit [Read error: Connection reset by peer]
sarietta has quit [Remote host closed the connection]
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 244 seconds]
cnxsoft has joined #linux-sunxi
_mamalala_ has joined #linux-sunxi
_mamalala has quit [Ping timeout: 244 seconds]
pg12_ has quit [Ping timeout: 276 seconds]
pg12 has joined #linux-sunxi
tlwoerner has quit [Quit: Leaving]
Putti has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
cnxsoft1 has joined #linux-sunxi
IgorPec has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 264 seconds]
cnxsoft1 is now known as cnxsoft
Putti has quit [Ping timeout: 264 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
tainox has joined #linux-sunxi
jernej_ has joined #linux-sunxi
tainox has left #linux-sunxi [#linux-sunxi]
smooker has joined #linux-sunxi
fire219 has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
jernej_ has quit [Ping timeout: 264 seconds]
IgorPec has quit [Ping timeout: 264 seconds]
IgorPec118 has joined #linux-sunxi
smooker has quit [Remote host closed the connection]
<jelle>
KotCzarny: couldn't find it anywhere for a reasonable price
<KotCzarny>
eink carta + touchscreen
<jelle>
and heard eink is kinda a bitch :-)
apritzel has joined #linux-sunxi
<KotCzarny>
+ wifi + linux
<KotCzarny>
jelle, eink carta is BEST for reading
<jelle>
KotCzarny: no, I mean running mainline
<KotCzarny>
uhhum
<jelle>
as in drivers for eink
<KotCzarny>
though i would be pretty satisfied if i could simply run my own apps
<apritzel>
jelle: so that translates into: "interesting opportunities for upstream Linux contributions"?
<jelle>
apritzel: haha
<jelle>
apritzel: I've found getting firmware to load in a touchscreen driver already challenging enough with a full usable datasheet
sarietta has quit [Ping timeout: 272 seconds]
<fvogt>
apritzel: Hi, I've build your arm-trusted-firmware fork (allwinner and allwinner-scpi) and I get the following on each boot: ASSERT: mmap_add_region <111> : mm_last->size == 0. Would increasing MAX_MMAP_REGIONS fix that?
<apritzel>
fvogt: did you change or add anything to the tables?
<fvogt>
apritzel: No, I built it without changes: "make PLAT=sun50iw1p1 all -j8"
<fvogt>
Just tried MAX_MMAP_REGIONS = 32, same assert
<apritzel>
let me check (I usually build with DEBUG=1)
robogoat has joined #linux-sunxi
<fvogt>
apritzel: I tried both DEBUG=0 and DEBUG=1
<fvogt>
With DEBUG=0 it just freezes
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 272 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<apritzel>
fvogt: mmh, that's really weird, from the code I can't really see how this should happen
<apritzel>
and I have never seen this, IIRC
<fvogt>
apritzel: Me neither, should I add some debug output to mmap_add_region?
<apritzel>
fvogt: yes please, maybe this insertion algorithm has some bug
<apritzel>
and nobody triggered this before, since all the regions happened to be in order already
<apritzel>
fvogt: what is your compiler version?
<fvogt>
apritzel: Ok, will do that and report back
<fvogt>
apritzel: gcc version 6.2.1 20160830 [gcc-6-branch revision 239856] (SUSE Linux) - Should I try a different compiler?
<apritzel>
no, that's fine
<apritzel>
I think 4.8 & friends had some bugs, but anything halfway recent should be fine
<apritzel>
and yours seems pretty recent, in fact ;-)
<fvogt>
Maybe even too recent, I'll try a slightly older one
Putti has joined #linux-sunxi
<apritzel>
fvogt: I wonder if that mmap array is ever correctly initialized, can you add: " ... = {0};" to that array declaration line?
<fvogt>
apritzel: Will do all three, gcc-5, debug output and {0}
<apritzel>
fvogt: thanks!
<apritzel>
fvogt: upstream ATF seems to have extra code to cope with overlapping regions, not sure if that matters here
<fvogt>
apritzel: It looks they partially rewrote the code
<fvogt>
apritzel: Still doesn't work, it asserts in the first call to mmap_add_region already
<apritzel>
fvogt: I wonder if you could dump the array before mmap_add_region() gets called for the first time
<apritzel>
fvogt: you could try to define DEBUG_XLAT_TABLE
<fvogt>
If the assert is it it's likely going to print out an endless stream of nonsense
fvogt has quit [Quit: Konversation terminated!]
fvogt has joined #linux-sunxi
<fvogt>
Meh, lost connection. Did I lose any messages?
apritzel has quit [Read error: Connection reset by peer]
<Xilokar_>
fvogt: nope
<fvogt>
Xilokar_: Thanks. Did my last message end up here? "... endless stream of nonsense"?
<Xilokar_>
yep !
paulk-collins has quit [Ping timeout: 272 seconds]
Putti has quit [Ping timeout: 272 seconds]
yann has quit [Read error: Connection reset by peer]
ninolein_ has quit [Quit: No Ping reply in 180 seconds.]
Ixnus has joined #linux-sunxi
ninolein has joined #linux-sunxi
<Ixnus>
jelle: I'm searching for that device, if I find one at good price will let you know.
apritzel has joined #linux-sunxi
<KotCzarny>
ixnus: what is 'good price' ?
<KotCzarny>
here its sold for ~100usd (no frontlight version)
<fvogt>
apritzel: I got further, it printed out an infinite amount of garbage, so I added a memset to 0 in the initialization. Now it gets further, until the next assert
<Ixnus>
KotCzarny: <50E
<fvogt>
apritzel: I guess somehow bss is not zeroed out
<KotCzarny>
ixnus: cool, i might be interested too
sarietta has joined #linux-sunxi
yann has joined #linux-sunxi
<apritzel>
fvogt: so how many calls to mmap_add_region() now before it asserts?
sarietta has quit [Ping timeout: 244 seconds]
<Ixnus>
KotCzarny: ok, will let you know too, for sure ;) , the more devs have it , the better the support
<fvogt>
apritzel: Six, it asserts in init_xlation_table now
<KotCzarny>
im not a dev, but im on the hunt for the best ebook reader for me ;)
<KotCzarny>
(well, im a dev, but more from the app side, than hw support)
fvogt has quit [Quit: Konversation terminated!]
<Ixnus>
you can test stuff on it.
fvogt has joined #linux-sunxi
arete74_ has quit [Ping timeout: 276 seconds]
kaspter has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
fvogt has quit [Quit: Konversation terminated!]
fvogt has joined #linux-sunxi
Ixnus has quit [Quit: Page closed]
sarietta has joined #linux-sunxi
Worf has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
sarietta has quit [Ping timeout: 272 seconds]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
Xilokar_ is now known as Xilokar
<montjoie>
apritzel: do you have an A64 branch wih more recent kernel than a64-v5 ?
<apritzel>
montjoie: not publicly, no
<apritzel>
still undecided whether I should push one with firmware clocks or with the a64-ng clocks
<montjoie>
I need to test Crypto Engine RSA on A64 but need latest akcipher
<montjoie>
will try backport
<apritzel>
montjoie: yeah, backporting a64-v5 shouldn't be too hard
<apritzel>
I remember other people here doing that already
<apritzel>
montjoie: if not you could try any of MoeIcenowy's branches
|Jeroen| has quit [Quit: dada]
iamfrankenstein1 has joined #linux-sunxi
cds has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 244 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<montjoie>
apritzel: in final only two patch missed
Worf has quit [Quit: Konversation terminated!]
sarietta has joined #linux-sunxi
kaspter has joined #linux-sunxi
sarietta has quit [Ping timeout: 244 seconds]
fvogt has quit [Quit: Konversation terminated!]
fvogt has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
<fvogt>
apritzel: I got it to not assert without any code tweaks, just by adding "--set-section-flags .bss=alloc,load,contents" to objcopy
<fvogt>
Now it just freezes without any output except for mmap_add_region calls
fvogt_vps has joined #linux-sunxi
imcsk8 has quit [Ping timeout: 240 seconds]
Putti has joined #linux-sunxi
imcsk8 has joined #linux-sunxi
The_Loko has joined #linux-sunxi
jernej_ has joined #linux-sunxi
sarietta has joined #linux-sunxi
<montjoie>
so RSA fail the same on A64 than H3
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
sarietta has quit [Ping timeout: 272 seconds]
fvogt has quit [Quit: Konversation terminated!]
<FergusL>
Anything to know about using pthread on ARM (32 bit)? Seems a program fails to work because of threading. The program executes normally, only events that are supposed to happen in a thread loop aren't happening... What's in the said loop is tested and works outside of a thread, and the same program on x86 runs well, the events are happening
yang has joined #linux-sunxi
<apritzel>
FergusL: what do you mean with "events"? Just in general some output or action? Or anything Linux specific like perf events?
<FergusL>
Hm, specific to linux I guess but what's inside the loop does work, http://users.suse.com/~mana/seqdemo.c this program works on x86 and ARM, I've just tested it again
<apritzel>
We may both miss something in pthreads calls
orly_owl has joined #linux-sunxi
<FergusL>
Hm...
<apritzel>
but it works on arm64 ...
<FergusL>
HA! I have a Pine64 as well
<FergusL>
I'll try that asap
<apritzel>
oh wait ...
<apritzel>
I had a taskset on this shell :-D
<apritzel>
so sorry, works for me even on ARM(32)
<FergusL>
what could that mean?
<FergusL>
HA
<FergusL>
I was inside a tmux session, could that explain as well?
<apritzel>
maybe systemd is doing weird things here?
massi has joined #linux-sunxi
<FergusL>
erh :/
<KotCzarny>
systemd is evil
<FergusL>
well at least I can probably control that in some way?
<KotCzarny>
best way is to uninstall it
<KotCzarny>
:)
<KotCzarny>
but due to its evillness and lies, many distros are unable to replace it with something sane already
<FergusL>
I'm afraid it would break many things on my image
<KotCzarny>
if you have spare sd card try armbian jessie, you can remove it safely there
<apritzel>
FergusL: does it work if you replace "pthread_create(...) with midiLoop((void*)&data)?
<FergusL>
Ok the thing is that I added usb midi in the kernel, it was pushed to Armbian git but I don't know if it has landed in the published images yet :/ and I was ok with writing C today, but not with recompiling a kernel and creating a new image ><
<FergusL>
I have to move i'm already late for my geeky music rehearsal! But i'll try that as soon as I get there
<FergusL>
apritzel: about taskset, maybe I could run it inside tasksel? setting it to use all 4 cores of the H3
<FergusL>
and for what it's worth, also trying as root :D
<FergusL>
can you share your test programs?
<FergusL>
KotCzarny: thanks I'll try that as well !
<KotCzarny>
systemd is similar to m$ windows, it tries to nanny user with (often) broken defaults, not to mention broken code
<apritzel>
KotCzarny: while I agree with you on systemd and avoid it as well, just removing systemd isn't the solution to FergusL problem ;-)
<KotCzarny>
apritzel, maybe, but i didnt notice anything similar on my boards
<apritzel>
maybe the AW based kernel has offlined all secondary cores or so
<KotCzarny>
which app should i use to check here?
<apritzel>
KotCzarny: for offlined cores? /proc/cpuinfo for a start
<KotCzarny>
nope, for mt/events
<FergusL>
that's the core of the problem, actually, I have no idea what is causing this exactly
<FergusL>
it might even be a comibation of two things that only happen in my small quickly written program
<FergusL>
I wish tkaiser could shime in about the consumption tweaks he made!
<FergusL>
I might try that as well
<FergusL>
brb
<KotCzarny>
FergusL: consumption tweaks are on armbian forum thread
cnxsoft has quit [Remote host closed the connection]
pg12 has quit [Ping timeout: 244 seconds]
horigome has joined #linux-sunxi
pg12 has joined #linux-sunxi
<jemk>
FergusL: I don't know if this is the reason for your problem, but you can't use alloca in init_midi():117, it will be invalid later in the thread
sarietta has joined #linux-sunxi
sarietta has quit [Ping timeout: 244 seconds]
<maldata>
tkaiser: there was one already... sun7i-a20-hummingbird.dts.
<maldata>
NiteHawk: I checked dmesg, and it says all CPUs started in HYP mode, but I do not have a /psci node in the device tree
<apritzel>
maldata: how many CPUs are up? just 1?
<maldata>
apritzel: yes. Two are reported in /proc/cpuinfo, two are reported in lshw. However, lshw says CPU0 is running and CPU1 is disabled.
orly_owl has quit [Ping timeout: 244 seconds]
<apritzel>
maldata: is that with upstream U-Boot now?
<maldata>
apritzel: yes, the 2016-09 branch
<apritzel>
so then it should enable the PSCI code in U-Boot and provide the DT node
<apritzel>
or do you see an error message from U-Boot?
<maldata>
yeah, it is enabled in the u-boot config. The only error I see from u-boot is "bad CRC, using default environment"
<maldata>
is it possible that something is left out of the mainline kernel's dts?
<apritzel>
maldata: you could add "#define DEBUG" in various PSCI related source files in U-Boot to tell you what it's doing
<apritzel>
maldata: normally U-Boot would insert a PSCI node into the existing DT
<apritzel>
maldata: (I take it you load and pass a DT in U-Boot)
<maldata>
apritzel: correct
<NiteHawk>
that's the way it's supposed to be - however, i haven't checked that with A20 on a current U-Boot release (2016.09). maybe something changed?
<NiteHawk>
maldata: what kernel version are you using?
<maldata>
NiteHawk: 4.7.5
<NiteHawk>
ok, that should be just fine
<NiteHawk>
so my impression too is that something is missing/afoot from the U-Boot side of things (missing psci node)
<maldata>
before we get into this any further... what's the right way to confirm that only 1 CPU is running? I don't want to keep chasing this if lshw is just giving me garbage.
<apritzel>
maldata: I was wondering about that as well: if /proc/cpuinfo shows two CPUs, then there should be two, really
<maldata>
I can see in dmesg that there ARE two messages from psci, and it shows that "SMP: Total of 2 processors activated"
<maldata>
but even if I stress the CPU, lshw always shows that CPU1 is disabled.
<apritzel>
lshw is quite x86-ish, I wouldn't be surprised if this is a misreport
<NiteHawk>
yes, i seem to recall that lshw was unreliable for that
<NiteHawk>
i get "cpu:1 DISABLED" too on a bpi that has both cores active
<apritzel>
maldata: with "I do not have a /psci node in the device tree": where did you check this?
<apritzel>
the .dts file has none, as U-Boot inserts this
<apritzel>
but you should see it in /proc/device-tree and /sys/firmware/devicetree
diego_r has quit [Ping timeout: 276 seconds]
diego_r has joined #linux-sunxi
<maldata>
apritzel: /proc/device-tree/psci exists and has stuff in it. /sys/firmware/devicetree/ exists, but only contains a directory called "base"
orly_owl has joined #linux-sunxi
<apritzel>
maldata: well, yes, go into them ;-)
<apritzel>
so PSCI seems to work then
<NiteHawk>
list that "base" ;)
<NiteHawk>
maldata: what does "cat /sys/devices/system/cpu/online" output?
<maldata>
sorry, I don't really know what I'm looking for here, I was looking for a psci directory. Yes, /sys/firmware/devicetree/base/psci exists and has the same contents as /proc/devicetree/psci
<apritzel>
maldata: those directories are a filesystem-like representation of the device tree
<apritzel>
if you like the normal .dts way, try: dtc -I dtb -O dts /sys/firmware/fdt
<apritzel>
or: dtc -I fs -O dts /proc/device-tree
<maldata>
that's interesting. The dts shows psci and two CPUs, although the two CPUs do not have identical entries. Also, the /proc/device-tree way doesn't work (error says it's a directory)
|Jeroen| has joined #linux-sunxi
<apritzel>
maldata: mmh, ancient dtc version, then?
<apritzel>
maldata: you would hope that at least the "reg" property is different in each cpu node ;-)
<NiteHawk>
maldata: what does "cat /sys/devices/system/cpu/online" output?
<FergusL>
jemk: Ha, I didn't know. Does it still make sense the same code works on x86_64?
<maldata>
apritzel: dtc version 1.4.0. And yes, the reg values are different.
<maldata>
NiteHawk: "0-1"
<jemk>
FergusL: possible, behaviour is undefined, maybe arm handles alloca/stack different
<apritzel>
maldata: so what is your issue here exactly? ;-) Everything seems to be correct, then
<NiteHawk>
maldata: then all is well, you have both cores active. you were probably just misled by that lshw output :P
<maldata>
apritzel: my issue is that lshw is a dirty liar.
BenG83 has joined #linux-sunxi
<apritzel>
always been ;-)
<KotCzarny>
maldata, nah, its just a foreigner
<KotCzarny>
:P
<NiteHawk>
canadian? :D
<maldata>
for what it's worth, this is BY FAR the most helpful IRC channel I've ever used. I appreciate all your help here... learning a lot.
<KotCzarny>
that's because you have devs present here, not just fanboys
<apritzel>
maldata: but yeah, those "asset listing" tools are usually subtly wrong on ARM, applies to dmidecode (if available at all) and lscpu (bigLITTLE) as well
sarietta has joined #linux-sunxi
<as0d70apf>
but im a fanboy?
<as0d70apf>
:)
<KotCzarny>
what makes you one?
<as0d70apf>
just picked up my orange pi 2 plus this morning
<as0d70apf>
i like small arm devices that run linux, i guess that's pretty muc it
<as0d70apf>
much*
<KotCzarny>
you just have problems with impulse shopping
<as0d70apf>
lol
<as0d70apf>
true
<KotCzarny>
but almost everyone here suffers from it
<as0d70apf>
hope to have some time this weekend to install debian on it :)
<as0d70apf>
anyway, time to go home, weekend!
<KotCzarny>
btw. you should've picked up opi+2e probably
<as0d70apf>
i think i have that one, the 16gb emmc and 2gb memory
<KotCzarny>
both have 2gb and 16gb emmc
<KotCzarny>
what differentiates is that crappy sata bridge is dropped on 2e
<KotCzarny>
and crappy internal usb hub
<KotCzarny>
which makes your usb ports faster and uncrippled
<KotCzarny>
(and you can always connect external usb enclosure anyway)
sarietta has quit [Ping timeout: 272 seconds]
<as0d70apf>
oh right, yeah i guess i should have gotten that one instead then, i'll learn some day maybe
<KotCzarny>
if you arent throughput freak it will work anyway
<as0d70apf>
it's replacing a sheevaplug, i think i'm ok with the performance :)
<KotCzarny>
oh, so you need some sata then, you will be amazed how crappy gl830 is
<KotCzarny>
;)
paulk-collins has quit [Quit: Leaving]
Leepty has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
<horigome>
How much effort is needed to make i2s and the audio codec work in the mainline kernel branch of the H3 chip?
<horigome>
I have used FA NanoPi NEO and an image I made using the Armbian kernel compilation tools. I would like to have the nice things in the mainline kernel but for my project I need sound...
netlynx has quit [Quit: Ex-Chat]
<horigome>
No linux audiophile or masocist with a lot of spare time that wants to get his hands dirty with linux kernel audio development?
codekipper has joined #linux-sunxi
<KotCzarny>
isnt there few examples of i2c cards already?
<codekipper>
horigome: I've got the audio codec, i2s and spdif probing on my orange pi 2
<codekipper>
but I've not got the prcm bit in yet successfully and the clocks for the rest seem out
<horigome>
KotCzarny: So if I were to have a i2c audio codec ic chip I should be able to get audio?
<codekipper>
short term usb audio is the only solution, but i2s/spdif shouldn't be too much effort
<KotCzarny>
horigome: ask codekipper, as he already dabbled in the topic
sarietta has joined #linux-sunxi
<horigome>
codekipper: Great, I suspect it should be more of filling in some blanks? Any idea how much time would be required for the implementation? Is there any substantial difference between audio on kernel 3.x and 4.x?
<codekipper>
it depends on your needs..the codec works fine on 3.4 but looks horrible
<horigome>
My needs are pretty basic, I just want to use a ic chip to play sound that is generated on the H3. Using on onboard codec for playback and recording is a plus.
sarietta has quit [Ping timeout: 244 seconds]
<codekipper>
gh
<codekipper>
if you can apply patches and wanna play around with mainline then I can push the patches somewhere...they are messy thou
<codekipper>
you're looking at using a i2s chip?
<horigome>
codekipper: that's fine with me. Now I just want something that works, regardless of messiness
<horigome>
in the end I think so yes.
orly_owl has quit [Quit: leaving]
<codekipper>
then i would sit with 3.x or use usb on mainline
<horigome>
codekipper: ait, is there too much that needs to get done before an i2s chip can be used?
<horigome>
Also btw, does the OP2 get very warm? I have a NanoPi NEO and it gets pretty hot.
<codekipper>
I don't think so....everything looks to be in place just when I played the audio(without having a codec connected)..the 5min track played for a fraction of the time
<codekipper>
something is up with the clocks which I've not been able to investigate
<horigome>
Oh I see
<codekipper>
I've kept my finger away from it
<horigome>
Which kernel version were you using?
<codekipper>
but heard that it can get hot
<horigome>
Well okay, that seems to be the general case with the H3 chip..
<codekipper>
I've always used my-hobby patches ontop of Hans' sunxi-wip...unless pushing upstream
cds has quit [Ping timeout: 240 seconds]
premoboss has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<horigome>
codekipper: If I were to use the orange-pi-4.7 I should not expect to get the audiocodec working, right? Do you have patches for that branch?
<codekipper>
audio codec is an all together different beast...I've not got the dai and codec working together yet
<horigome>
all right, so you use USB audio instead?
<codekipper>
I prefer silence!
<horigome>
Very minimalistic
<codekipper>
shhhhhh
<horigome>
I need more caos
<codekipper>
I was playing with the patches today...re-organizing stuff. But haven't had a chance to run on any hw yet
<codekipper>
just compiled
<codekipper>
if you want any audio on h3 mainline today then usb is the only way...if you wanna invest some time then I would say i2s/spdif is your next best hope
diego_r has quit [Quit: Konversation terminated!]
matthias_bgg has quit [Quit: Leaving]
massi has quit [Remote host closed the connection]
BenG83 has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: Leaving]
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
apritzel has quit [Ping timeout: 244 seconds]
codekipper has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<horigome>
codekipper: could I use some code, f.x. from the Raspberry Foundation as a basis for the i2s/spdif code for the H3?
codekipper has joined #linux-sunxi
afaerber has quit [Quit: Ex-Chat]
<codekipper>
horigome: No...the drivers have been delivered for earlier Allwinner socs and there is little to do to get them working probing with the H3.
<horigome>
sorry for my noobness but what do you mean by probing?
<codekipper>
However...I'm not sure if all the things that these drivers need is working yet.