<simosx>
1. NAND Flash driver for A80 (on linux-3.4, bootloader)
<simosx>
2. encoder support for the video engine, API document and encoder demo.
<simosx>
(armhf encoder library for the mediacodec-lib)
<libv>
binary?
<libv>
really?
<libv>
shitstorm ahead.
<plaes>
:)
<libv>
simosx: seems like my predictions were right then.
<plaes>
lots of weird copyrights in the nand sources
<plaes>
Copyright(C), 2006-2008, uLIVE
<simosx>
Option A: be constructive. Option B: business as usual.
<libv>
simosx: being constructive does not help with this company.
<libv>
allwinner has very clearly proven that, time and time again
<simosx>
well, give me the list of things to change and let's see.
<libv>
i gave ben a list a week ago.
<libv>
and this is the result.
premoboss has quit [Ping timeout: 250 seconds]
<libv>
simosx: do you really think that i _only_ make public noise?
<simosx>
first, that (c) issue with the source. even the bq kernel had those issues.
<libv>
that's very minor
<simosx>
low hanging fruit.
<plaes>
yup
<libv>
turning the "open source" version of their cedar into modules clearly showed their plan for the future
<libv>
and we just arrived in the future
<libv>
the future of deliberately sustained GPL violation
<simosx>
it's like watching 'the thick of it' in replay here, but it's not funny this time.
<NiteHawk>
could that be a more general problem? e.g. Mali IP being covered by restrictive licenses / NDAs from ARM?
<libv>
i do not change my tune with the wind like malcom does.
<libv>
if that is what you meant with your statement there.
<libv>
malcolm even
<simosx>
the problem with malcom was that he became the cause of the recurring issues.
<libv>
and none of my noisemaking would be needed if allwinner didn't go out of its way to bend the rules
<libv>
simosx: so you are now suggesting that i am the cause of this?
<libv>
simosx: that is quite the logic leap.
<RSpliet>
NiteHawk: the problem is *not* that closed source software exists, it's that people break the rules by hiding open source software inside it
<libv>
RSpliet: i currently have more of an issue with people who know that things are wrong and who still try to either break the rules, or still try to talk good such relentless breaking of said rules.
<simosx>
there is the issue of communicating these complex issues. Instead of communicating the logic of the issues, what I see is just whipping. like malcolm.
<RSpliet>
libv: sure, don't judge by the mistakes people make, but by the way they resolve them...
<libv>
RSpliet: i do
<RSpliet>
libv: I know :-)
<libv>
RSpliet: allwinner has a very long trackrecord with making things worse than they were before
<libv>
and changes only happen after half the internet descends on it
<libv>
simosx: i have communicated that tons of times
<libv>
but allwinner clearly only understands pain.
<libv>
if there is no shitstorm, nothing improves with them
<NiteHawk>
RSpliet: if i understood that correctly, they (i.e. at least Allwinner) took some open source libraries and partly implemented them in silicone, with their "blob"s riding piggyback on top? i agree, that's clearly where the real violations are happening then
<libv>
NiteHawk: yes, that's one part of it
<simosx>
libv, you need to do better.
<libv>
simosx: i alone?
<libv>
simosx: so what are you going to do?
<libv>
simosx: further condone their behaviour?
<libv>
endlessly?
<libv>
until you have lost what little remains of your credibility?
<simosx>
libv, just write what needs to be changed, and let's see.
<libv>
simosx: been there, done that.
<plaes>
simosx: they know that the violations are there
<plaes>
as allwinner has even edited the GPL violations page on the wiki
<simosx>
plaes, i did not have a look at the recent changes, so no idea what you are refering to.
<plaes>
the problem is that Allwinner doesn't really trust the open source
premoboss has joined #linux-sunxi
<plaes>
they try to keep up with the crappy 3.4 kernel
<simosx>
'doesn't really trust the open source' is a loaded/sentimental statement.
<plaes>
so is most of your allwinner praising
<RSpliet>
plaes: the motivation for sticking with a 3.4 kernel is usually just money, lack of interest in upstream development (and security) and modus operandi
<RSpliet>
just check out how many "crappy 3.4" kernels there are on the codeaurora git repo's
<simosx>
development for the mainline is tougher than working on your own branch.
<plaes>
yup, though some other SoC makers are waking up
<mripard>
simosx: yes and no
Guest59362 has quit [Excess Flood]
<plaes>
one can even regularily spot mediatek and rockchip emails in the linux-arm list
<mripard>
it's short-term vs long-term
<mripard>
mainline is an investment
<Wizzup>
if allwinner doesn't want to support chips in the long term :)
<mripard>
you're losing money on short-term, to gain some long-term
<Wizzup>
which is mostly the case woth android
<RSpliet>
mripard: yeah, but the time-to-market for ARM SoCs is insanely short... you can't have upstream support from day one if you want your hardware to remain competetive unfortunately
<Wizzup>
with*
<mripard>
RSpliet: I never said that.
<RSpliet>
it's why most companies don't make the investment
<mripard>
that doesn't mean you just have to give it up entirely either
<simosx>
mripard, yeah, it's an investment for the long-term future of the products/SoCs.
<mripard>
and they end up with a crappy old kernel
<mripard>
that no-one really wants to use
<simosx>
mripard, my understanding is that there is difficulty with the choices on how to implement several things in a way that they will be included in mainline. That can take time, and requires different practices.
<RSpliet>
I don't think a lot of phone/tablet/set-top-box/NAS/... manufacturers truly care, as long as the kernel works and isn't obviously insecure. Public opinion is slowly changing, but slowly :-)
<mripard>
simosx: again, investment.
<mripard>
you're losing time because you can't make that quick and dirty hack
fredy has joined #linux-sunxi
sawtooth7 has joined #linux-sunxi
<mripard>
but the review process will prevent it to backfire.
<sawtooth7>
hi, do you know if it's possible to use MALI-400MP2 to do generic floating-point operations ?
<mripard>
(or at least a good portion of the possible backfires)
<jackdaniel>
is copyright/copyleft applicable to chinease law? (curiosity)
<simosx>
mripard, what would be a plan to get Allwinner engineers a bit more involved into the mainline process?
<simosx>
I definitely do not have a view of how much effort/work is required for the things still unresolved (in mainlining)
GPenguin has joined #linux-sunxi
<RSpliet>
sawtooth7: what do you mean with generic floating point ops? It's behind the AMBA bus, so I doubt you'd want to use it as an FPU
pekka301 has quit [Ping timeout: 256 seconds]
<simosx>
I think that those that would be interested, may not have either.
<RSpliet>
sawtooth7: OpenCL is unsupported for this generation of GPUs
<mripard>
simosx: that they actually start sending patches?
<RSpliet>
so I guess the answer would be no
<sawtooth7>
RSpliet oh no opencl ...
<sawtooth7>
would you know if A33 has NEON on each core ? i'd assume so but ....
<sawtooth7>
i've noticed cortex-a7 neon is 4 times slower than cortex-a8 already :-/
<RSpliet>
simosx, mripard: Money is always a good incentive. Can't we get cheap tablet manufacturers to abandon Allwinner unless they can use upstream kernels?
<RSpliet>
;-)
<sawtooth7>
allwinner is quite big in china :)
<sawtooth7>
come to shenzhen they're everywhere, together with rockchip
<mripard>
RSpliet: and you were the one that mentionned time to market...
<plaes>
:D
<simosx>
mripard, patches for which items in particular? there are so many things. if there was a list of bit-sized tasks, I think it would help. Perhaps something else that is concrete/structured.
<plaes>
well, better manuals
<mripard>
simosx: you mean like the one I provided you like 6 monthes ago
<mripard>
or the one that we have on our wiki ? :)
<jackdaniel>
patches for *anything* is better than nothing i think
<libv>
amazing that Allwinner does this now, now that the C.H.I.P. was such a massive success.
<RSpliet>
jackdaniel: not sure about that... judging by the code quality of what I've seen, documentation might be a lot more useful
<simosx>
mripard, that one from six months ago did not work well. my recollection was the focus changed as to which item is more important. almost there, but now a better choice would be something about the a83t.
<mripard>
except that nothing changed with the A83, really.
<mripard>
it's still the same drivers for the same IPs that are missing
<mripard>
they just put more cores in it
<plaes>
they haven't even officially released A23 manual
<simosx>
there is interest for mainlining and being active. does the SoC boot with mainline at all?
<plaes>
who's interest?
<plaes>
err.. interest by whom?
<mripard>
simosx: supporting new SoCs is cheap. It's supporting IPs that is hard
<mripard>
and yeah, I expect the thing to boot with nothing more than it's DT
pekka30 has joined #linux-sunxi
<libv>
shitstorm_start();
<plaes>
undefined reference to `main'
<libv>
:p
<plaes>
you should probably mark it as volatile :P
<libv>
:)
<libv>
put a while loop around it too
<simosx>
mripard, it would be great to demonstrate the booting of mainline. I do not know what is to put in the DT.
<WarheadsSE>
at leas they put it out there, even if they haven't fixed the licensing blobs @ the headers.. yet.
<jackdaniel>
for sec I tought it alarm channel ^_^
<jackdaniel>
s/it/it's/
<WarheadsSE>
:P
<WarheadsSE>
I am in many places jackdaniel
<jackdaniel>
I know, yet never saw you speaking on them ;]
BroderTuck has joined #linux-sunxi
<nove>
"and may be used only as expressly authorized"
<BroderTuck>
The newly released A80 nand sources all seem to come with an "All rights reserved" notice, rather than anything that can be called Open Source.
<nove>
that repository was passable as been fully "open source", and know they polluted with again "license issues"
<sawtooth7>
you should all come to China to understand they are far from willing to understand those kind of problems !!!!!!
<RSpliet>
sawtooth7: will that have even the slightest impact on *their* view of the world?
<nove>
if allwinner wants to be more than china, then allwinner has to do more than china (not offense to Chinese people and its wonderful culture and history )
<sawtooth7>
how many more chips would they sell if they played by the rules ?
<jackdaniel>
it's a question of kind "how long my buiseness would run, if I didn't use pirated version on windows in my office"
<RSpliet>
how long will they survive in the market if an open-source friendly SoC developer starts targeting the same market today? Would they still exist 3 years from now?
<sawtooth7>
i'd think it would be hard to take on that market, the price of their chips are insanely low
<sawtooth7>
those people who buy those low-cost tablets, do they care about open-source ?
<jackdaniel>
sawtooth7: it's not a point, all is cheap because they actually steal code (you can steal (or try to) copyleft as shown in an example)
<sawtooth7>
it'd think they're cheap because they manufacture huge quantities for their very large market
<jackdaniel>
hardware without software is hardly a market hit
<sawtooth7>
sure, i agree
<RSpliet>
jackdaniel: sawtooth7 is right that the avg. customer doesn't give a darn if their tablet runs an ancient 3.4 kernel; they wouldn't even know
<jackdaniel>
RSpliet: yes, but I'm talking about violating gpl - it's same kind of steal as using pirate software
<sawtooth7>
jackdaniel: but they don't think software piracy as we do
<RSpliet>
jackdaniel: the problem there is "corporate cultural" and a lack of legal force against them
<sawtooth7>
it will take some time for them to change
<jackdaniel>
so it's not about customers, but rather gpl'ed library creators, who are robbed
<sawtooth7>
robbing software - which is a virtual thing - is something they do not understand
<sawtooth7>
to them if you don't want to get "robbed" so you get copied, you must protect your source-code
<jackdaniel>
my point is, that saying about competiveness is faulty, since its based on taking goods (man-hours) without paying for them
<RSpliet>
jackdaniel: that hasn't had an influence on their price in the market today...
<sawtooth7>
i'd presume they must have occasional discussion about GPL at allwinner, must be fun to hear them debating ;)
<RSpliet>
is there an official Chinese translation of the GPL?
<libv>
sawtooth7: the answer to all our problems is C.H.I.P.
<nove>
RSpliet: yes, there is, and allwinner included in its repository
<libv>
even though i know that they are fraudes, they have wriggled themselves into a position where they have no other option but to force Allwinner, with an actual business case, to be more open
<jackdaniel>
RSpliet: maybe, I don't know, but it doesn't change a thing imho
<libv>
their overhyped product, their image, and Allwinners image, depend on Allwinner playing nice (and then some)
<sawtooth7>
C.H.I.P ? a $9 computer ?
<RSpliet>
yep
<libv>
the big rpi killer.
<libv>
well, biggish, only 2.something M usd
<sawtooth7>
what kind of CPU would that be ?
<libv>
a13 repackaged
<sawtooth7>
oh really
<RSpliet>
libv: I'm sure the RPi foundation is already shaking :-)
<RSpliet>
one of the founders is now involved in the LowRisc project
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
sawtooth7 has quit [Remote host closed the connection]
sawtooth7 has joined #linux-sunxi
naobsd has quit [Ping timeout: 248 seconds]
<sawtooth7>
like you said, software is everything
<sawtooth7>
the hardware of this C.H.I.P computer is not that impressive
<sawtooth7>
i wouldn't be surprised about that, they can make up those loss with all those peripheral modules though
markvandenborre has left #linux-sunxi [#linux-sunxi]
BroderTuck has quit [Quit: Page closed]
<sawtooth7>
that R8 SOC seems really cool !
<sawtooth7>
EDIT Update 08-06-2015: On the question why R8 cost is same as for quad core processor the response from Allwinner is:R8 is new IC just published especially on IoT, it is not like A33 this one had used on a large scale forTablet PC.
cajg has quit [Ping timeout: 276 seconds]
cajg has joined #linux-sunxi
<sunxi_fan>
hello, i wrote sometime ago about porting the "i2s" legacy sunxi 3.4 driver to mainline..
<sunxi_fan>
as suggested by mripard, the simple-sound-card has been the better route ( for what i can understand about the ALSA ASoC framework..)
<sunxi_fan>
now i have my first three modules set with:
<sunxi_fan>
the last one being my own single file module with the code ported from the init sequences of the 3.4 legacy driver.
<sunxi_fan>
at modules loading time, i have a bunch of messages. both from my own module and the other two (i'm using uda1380 as a sample codec connected to the I2C bus of a Cubieboard card).
<sunxi_fan>
the problem i'm facing now is that i'm at a point where the modules are hanging somewhere (the green led on the board is still flashing so the kernel is somewhere alive) and i do not have a clue..
<sunxi_fan>
i'm here asking some advice about how to proceed in kernel debugging..
<sunxi_fan>
..but i've got no message back at all..
<sunxi_fan>
if it's not too noisy i'd like to post the few lines of dmesg that show the sequence of initialization of the modules so maybe someone can help me about where i'm stuck..
<sunxi_fan>
here it it:
<sunxi_fan>
[ 62.933406] [AV]alloc ok sunxi_digitalaudio_probe
<sunxi_fan>
[ 62.938113] sunxi-i2s 1c22400.i2s: sunxi_digitalaudio_probe, [AV]dev err set priv into platform
<sunxi_fan>
[ 62.946969] sunxi-i2s 1c22400.i2s: [AV] set clock and rate on i2s, sunxi_digitalaudio_probe
<sunxi_fan>
the I2S are debug coming from my module, the same, more or less, present in the allwinner legacy driver..
<libv>
sunxi_fan: pastebin
<libv>
sunxi_fan: also, it might be wise to properly format all of that in an email to the ml
<sunxi_fan>
sorry if i spammed the IRC, it's really debugging at early time, i'd like not to spam the ML too.. ;-)
<sunxi_fan>
pastebin would have bin a better place for the debug messages, indeed. sorry again..
<libv>
it would not be spamming the ml
<sunxi_fan>
anyway, i'm at the end of this first "call for help". i.e. i'm at init time and i suppose the last bit of info are coming from "sound-dapm." of ASOC calling bias_level in uda1380.c codec then nothing comes back..
nicksydney has joined #linux-sunxi
avph_ has quit [Ping timeout: 246 seconds]
avph has quit [Ping timeout: 264 seconds]
avph has joined #linux-sunxi
<mripard>
sunxi_fan: pasting the code you're talking about would help.
<sunxi_fan>
more or less, i could post somewhere the "sound/soc/sunxi/sunxi-i2s.c". it's still very very kludgy because it's a "blend" between a I2S dai from a device using simple-card (IIRC i started from kirkwood-t5325.dts) and the legacy sunxi 3.4 sunxi-i2s.c (for the initialization values of registry..)
<mripard>
sunxi_fan: well, it all depends whether or not you actually want some help or not
<sunxi_fan>
then there's some stuff to be put in the cubieboard.dts for declaring the simple-card DTS
<sunxi_fan>
umh, right, some help would help a lot..
<sunxi_fan>
one issue i faced was related to the uda1380.c codec driver..
<philipp__>
I try ti use musb on SoC A20
<mripard>
where is the ext_codec label defined ?
<mripard>
never mnd.
<philipp__>
if I check extcon class I can see that cable is correctly detected (USB or USB_HOST)
<philipp__>
but after that nothing
cajg has quit [Ping timeout: 276 seconds]
<philipp__>
in device mode the host have a error "not enumerate"
cajg has joined #linux-sunxi
<philipp__>
I work with Hans de Goede's kernel
<sunxi_fan>
in "static int uda1380_probe(struct snd_soc_codec *codec)" ..
<sunxi_fan>
the check of platform data was bumping me out the probe step:
<sunxi_fan>
if (!pdata)
<sunxi_fan>
return -EINVAL;
JohnDoe_71Rus has joined #linux-sunxi
<philipp__>
And I configure gadget HID under the kernel (not in module) I probably forgot something but I don't not what?
<sunxi_fan>
are the platform data legacy of the past, and now everything should be passed on "device tree" structure?
<mripard>
yes
<sunxi_fan>
so i had to patch also that just to get info from the device tree about reset and power gpios.. BTW i do not have those gpios so i'd like to make them -EINVAL but i've not been able to do it using the device tree syntax..
<sunxi_fan>
i mean: "the codec breakout board doesn't have those GPIOs for hard reset and power, so this stuff is meanignless in my setup.."
<sunxi_fan>
the patch on uda1380.c about enabling reading data on DT instead of platform data puzzles me a bit, because i found another DTS with support for UDA1380 anyway.. arch/arm/boot/dts/ea3250.dts
<sunxi_fan>
so i've really wondering how it can read the params from the DT.. maybe because is using a "proprietary" device and not a simple-card approach?
<sunxi_fan>
..and the device driver is then going to pass the platform data structure to the codec when loading? really don't know.. i'm a bit out of this ALSA ASoC framework. it looks like quite modular and dynamic, but the debugging is not that easy.. :-)
<mripard>
you have an API to read data from the DT
<mripard>
the of_read_property_stuff
<mripard>
but usually, it's done by the framework for the generic things
avph__ has joined #linux-sunxi
avph has quit [Ping timeout: 252 seconds]
avph_ has quit [Ping timeout: 244 seconds]
<sawtooth7>
a23 & a33 datasheet say there are two SPI but i can only see SPI0 on PC0-PC3 , a83T also states 2 spis, SPI0 is located on the same pins and SPI1 on PG6-PG9
<sawtooth7>
could it be there on a23/a33 too ?
<sunxi_fan>
@mripard: this indeed is what i added in my patch on uda1380.c as in: "of_property_read_u32(np, "dac-clk", &pdata->dac_clk);", otherwise it would have broken out with if (!pdata) -> return -EINVALM; during uda1380_probe()
ricardocrudo has quit [Remote host closed the connection]
avph__ is now known as avph
p1u3sch1 has quit [Ping timeout: 256 seconds]
p1u3sch1 has joined #linux-sunxi
cosm has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
philipp__ has quit [Remote host closed the connection]
<wens>
sawtooth7: PA0~3
<sawtooth7>
oh like a10 then ?
<sawtooth7>
thanks :)
awe00 has quit [Ping timeout: 276 seconds]
<sawtooth7>
wait but ... a23/a33 don't have PAxx ports though
Dodger78 has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
premoboss has quit [Ping timeout: 246 seconds]
gzamboni_ has quit [Read error: No route to host]
<wens>
yeah... i think i screwed up a23 pinctrl driver
avph has quit [Ping timeout: 250 seconds]
cajg has quit [Ping timeout: 276 seconds]
cajg has joined #linux-sunxi
sawtooth7 has quit [Remote host closed the connection]
cajg has quit [Ping timeout: 276 seconds]
sawtooth7 has joined #linux-sunxi
enrico_ has quit [Quit: Bye]
sawtooth7 has quit [Client Quit]
<NiteHawk>
is there an 'official' limit for the 960mhz clock frequency on sun7i? a patch in march removed the "overvolted" 1008mhz @ 1.45v from sun7i-a20.dtsi, but i find that my a20 runs happily (and seemingly stable) at 1008mhz @ 1.4v
cajg has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
philectro has quit [Quit: Konversation terminated!]
mmarker has quit [Quit: ZNC - 1.6.0 - http://znc.in]
mmarker has joined #linux-sunxi
mmarker has joined #linux-sunxi
dev1990 has joined #linux-sunxi
awe00 has joined #linux-sunxi
reinforce has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
premoboss has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
domidumont has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
dack has joined #linux-sunxi
cajg has quit [Ping timeout: 276 seconds]
cajg has joined #linux-sunxi
pmattern has joined #linux-sunxi
<Turl>
NiteHawk: sdks, fex, and such
<NiteHawk>
turl: didn't allwinner use 1008mhz across a lot of configurations, too? i thought those places were where the frequency sets originated from
<NiteHawk>
i know that some a10 boards have been reported to be unstable at 1008mhz
<NiteHawk>
my actual question should probably be: is 1008mhz@1.4v (in contrast to 1.45v) considered incorrect ("undervolted") for sun7i? my impression is that it got primarily removed because of the voltage being 'out of spec'
<NiteHawk>
or put another way: if 1008mhz@1.4v should turn out to be stable for a sufficient number of people, would that justify bringing it back into the .dtsi?
<Turl>
NiteHawk: A10 are factory-clocked at 1008MHz and A20 at 960MHz
<Turl>
usually the unstability is due to memory configuration
<Turl>
or 912 was it? not sure now on the A20
<NiteHawk>
i think it's 960, that's what mainline u-boot uses too
ricardocrudo has quit [Remote host closed the connection]
cajg has quit [Ping timeout: 275 seconds]
cajg has joined #linux-sunxi
FDCX_ has joined #linux-sunxi
shineworld has joined #linux-sunxi
<shineworld>
hi all, I'm a newbie and I've an issue with an arm board running debian wheezy. When I run apt-get update / apt-get upgrade I gel a lot of: Err http://http.debian.net/debian-security/ wheezy/updates/main gnupg armhf 1.4.12-7+deb7u7
<shineworld>
503 Service Unavailable [IP: 128.31.0.66 80]
philectro has quit [Quit: Konversation terminated!]
FDCX_ has quit [Ping timeout: 246 seconds]
cosm_ has quit [Ping timeout: 256 seconds]
PaulFertser has quit [Ping timeout: 272 seconds]
Leo__ has joined #linux-sunxi
PaulFertser has joined #linux-sunxi
cajg has quit [Ping timeout: 275 seconds]
cajg has joined #linux-sunxi
<Leo__>
Hello, I need some help. I got an old tablet called Every E700, with A13 chip. I tried some firmwares using PhoenixCard (startup option) but without success. Searching for all web, I think I found the issue: the tablet dont use the common partitions, like nanda, nandc etc. This link have some info, showing the partitions: http://pastebin.com/6kAMfsJ5