<hno>
arm-linux-gnueabihf-gcc -dumpspecs > specs; edit specs as mentioned above; copy it to lib/gcc/arm-linux-gnueabihf/<version>/
<hno>
and hope that u-boot is happy with gcc 4.7. The bare-bone compiler is 4.6.
merbzt has quit [Ping timeout: 264 seconds]
bsdfox has quit [Read error: Connection reset by peer]
<Turl>
hno: wiki wiki
<Turl>
:P
Gujs has quit [Ping timeout: 272 seconds]
steev has quit [Ping timeout: 272 seconds]
Gujs has joined #arm-netbook
steev has joined #arm-netbook
Sternennebel has quit [Quit: Leaving.]
rsalveti has quit [Excess Flood]
rsalveti has joined #arm-netbook
rsalveti has quit [Changing host]
rsalveti has joined #arm-netbook
Guest20013 is now known as hp__
<hno>
Turl, Linaro bug report more likely.
popolon has quit [Quit: Quitte]
L84Supper has quit [Ping timeout: 260 seconds]
L84Supper has joined #arm-netbook
stefanro1 has joined #arm-netbook
stefanro has quit [Ping timeout: 272 seconds]
mSquare has joined #arm-netbook
<libv>
hrm, i can handily kill my mele by: (from serial) firing up the fb (modprobe disp, lcd, hdmi), then running top. Then sshing to it and logging in.
mSquare1 has quit [Ping timeout: 256 seconds]
<libv>
if i am not running top, then the display loses sync for a bit, but survives
<libv>
cpufreq, and both display and ethernet being fired up at the same time for the first time?
<Turl>
huh?
<Turl>
you're running top on fb or via serial?
<libv>
serial
<Turl>
why does fb fail then? o.O
<libv>
the thing hangs :)
<libv>
stone-dead
<Turl>
ouch
<libv>
but even the slight loss of sync is curious
<Turl>
what output btw?
<libv>
some reclocking
<libv>
blinking cursor :)
<Turl>
yeah but hdmi, vga or what?
<libv>
hdmi
<libv>
hah.
<Turl>
libv: if you want to, try reverting both of the 'sata fix' patches
<libv>
reclocking while interrupts are flying and them not being properly marshalled?
<Turl>
hno: btw, the patch I sent to the ML fixes the weird screen distortion on boot
drachensun has quit [Quit: Leaving]
<libv>
i fear that the only explanation left for what i think were mmc issues is the full linaro images i was using, switching back between hf and el reveals no difference with the alip image
<Turl>
what mmc issues do you get libv?
<libv>
well, i was blaming mmc because there are a lot of errors with mmc being spewed and mmcqd/0 tended to eat quite a bit of cpu time, and there was a lot of waiting going on
* Gumboot
wonders if he missed http://apc.io/ altogether, or just dismissed it for its inadequate CPU.
<libv>
Gumboot: it's VIA
<libv>
Gumboot: stay away
* libv
says with more 9.25ys of experience
<Gumboot>
I read somewhere it's ARM11, but I'd normally expect VIA to be selling x86.
<Turl>
I saw that one on newegg today I think
<libv>
Turl: trying with reverting the other patches first
<libv>
check out their kernel source releases
<libv>
and you will agree with me
<libv>
try to find out what mali is on board this wm8750 from the apc site
<Turl>
libv: btw, mali was stalling funnily today
<libv>
and the frustration you feel while trying to navigate this site in trying to get real specs, will make you steer clear of via
<libv>
Turl: i have never ever stalled mali with all my lima hacking
<Turl>
it printed errors on dmesg about the MMU being on a weird state :P
<Turl>
libv: clock it to 400Mhz and run a bit of GL stress testing
<lundman>
i wired my mali with 220v, and it crashed! bad design i say!
<Turl>
a run of "Antutu" android app on 2D+3D testing is enough
<libv>
not on telechips (mali200, haipad), not on amlogic (400, zenithink zt-280)
<libv>
never ever crashed it
<libv>
and believe me, i have thrown an amazing amount of crap at it
<libv>
at most individual jobs fail, or crap or nothing is rendered
<Turl>
yeah but this was a hw stall :P
<libv>
you can immediately run other things without noticing
<Turl>
probably due to heat
<libv>
well, don't overclock it :)
<Turl>
I didn't OC it knowingly
<libv>
it's an amazingly stable gpu
<Turl>
but this sata fix switched the mali clock source from 960Mhz to 1.2Ghz :P
<libv>
there is nothing, and there will be nothing like it
<Turl>
320->400Mhz on mali
tekzilla has quit [Ping timeout: 248 seconds]
<libv>
i am sure that t6xx will crash on a dime
<libv>
but i would like to be pleasantly surprised :)
<Turl>
I noticed they seem to be dropping "libUMP" for the newer malis
<Turl>
and using DMA buf stuff
<libv>
makes sense
<libv>
the nice thing about dma buf is that the usual suspects didn't press it out like clearing sinusses
<libv>
like most other things they have done so far
tekzilla has joined #arm-netbook
<libv>
it is committee designed, sure, but better that extreme of the scale (where it actually has a chance of covering anything beyond intels usecase), than the idiocy we have had to endure for the best part of the last decade
<Turl>
did you see the discussion where nvidia wanted to un-gpl-mark the symbols
<Turl>
?
<libv>
parts of it
<libv>
loads of noise
<libv>
nvidia will not change
<libv>
all they did was scare off others
<libv>
ok, both sata patches reverted in my current kernel
* libv
straps in and presses 'Go'
<libv>
hah
<libv>
maybe a few frames were buggered
<libv>
there was some blue streak in part of the display
<libv>
_much_ better!
<libv>
the thing hardlocked before
<libv>
Turl: going back to stage and applying your patch
<libv>
but man, this thing needs work!
<libv>
why the hell do i have to load the lcd module to get hdmi working!!!
<Turl>
libv: because you didn't fix it yet? :P
<Turl>
j/k
<Turl>
the allwinner code is a mess :(
<Turl>
they seem to want to reuse every single byte of code ever written
<libv>
yes, copy paste is what this tree is about
<libv>
disp is about a mb, my guess is that i can get that down below half
<libv>
but it will take a lot of time and work
<Turl>
there's some pdfs and docs on disp too
<libv>
i already converted the two xlses
<libv>
but the pdfs were just too much
<libv>
i have google translate overload now.
<libv>
ok, strapping in
<libv>
hrm, crashed on its own accord
<libv>
nothing unusual really, according to my experiences with this hw so far
<libv>
stable on the second go
<libv>
Turl: good catch indeed.
* libv
halts and tries again
<libv>
3x solid
<Turl>
libv: any chance you can try sata while you're at it?
sv is now known as discopig
<libv>
and restored stage, and immediate crash with my crashing procedure
<libv>
Turl: who cares, this code is a serious regression
<libv>
Turl: we have the means to prove it too
<libv>
stage: crash. your fix: stable
<libv>
f-ing googlegroups though.
<libv>
surely another ml provider can be found somewhere
toxicpsion has quit [Ping timeout: 260 seconds]
<libv>
at least the old interface is sensible.
<libv>
Turl: imho, this patch should hit more than stage immediately :)
<Turl>
libv: I guess I can push it to stage
<libv>
Turl: mnemoc will agree tomorrow, let me handle that :)
<libv>
err s/me/him/
<Turl>
:P ok
rz2k has joined #arm-netbook
<libv>
Turl: i am actually a split personality of mnemoc
<Turl>
heh
<libv>
Turl: i now have control of his brain now, and i am intending to build my private army :p
<rz2k>
libv: I've approved your msg to ml and added you to whitelist. damn gmail antispam kills various messages every day.
<libv>
it all started with visiting support groups, and bob and marla
<libv>
eh?
<libv>
how else would google groups have allowed me to answer to this email than through their web interface?
<Turl>
libv: via email? >.<
* libv
hadn't bothered to subscribe before an hour ago
<Turl>
:)
<rz2k>
you can subscribe to it and asnwer with topic I guess
<libv>
Turl: with no reply-to ids being shown the thread will be broken
toxicpsion has joined #arm-netbook
<libv>
thank google for their megalomania and attempting to reinvent everything
<jelly-home>
I thought the 256KiB mentioned somewhere _was_ L2
<discopig>
512k L2 cache
<jelly-home>
ooh
<discopig>
according to a few sites
<discopig>
not bad i guess
rellla has joined #arm-netbook
avernos has quit [Ping timeout: 246 seconds]
avernos has joined #arm-netbook
avernos has quit [Changing host]
avernos has joined #arm-netbook
cat_x301 has joined #arm-netbook
cat_x301 is now known as help
help is now known as Guest91768
sspiff has joined #arm-netbook
pawel5870 has joined #arm-netbook
tzafrir_laptop has joined #arm-netbook
popolon has joined #arm-netbook
<ZaEarl>
I think someone needs a new translator. I just received this in an email, "Cortex - A9 is so far in flat products adopt the most advanced core, comprehensive processing power is the mainstream introductory MID processing power decuple, hardware performance hit the mainstream online"
<RaYmAn>
or they just need to stop using google translate =P
mysteryname has joined #arm-netbook
eebrah has quit [Remote host closed the connection]
<mnemoc>
or better, learn english
<RaYmAn>
english is overrated ;)
<mnemoc>
the opossite :p english is dumb enough so anyone can learn it :)
<mnemoc>
my "formal" english went up to colors and months :|
<mnemoc>
but people seems to understand my grammar mess and non-sense,... even when I speak
merbanan has joined #arm-netbook
<Maqs>
most of the time I'm criticised for being too formal, using few discourse markers etc. \o/
ssspiff has joined #arm-netbook
<mnemoc>
:)
<specing>
ZaEarl: lol
sspiff has quit [Remote host closed the connection]
rellla has quit [Ping timeout: 255 seconds]
rellla has joined #arm-netbook
mSquare has quit [Ping timeout: 260 seconds]
<popolon>
chinese is simpler than english, no grammatical conjugation, no grammatical agreement/concord, no grammatical gender (but on 3 characters, even no difference on speak)
<popolon>
simplier
<Maqs>
you should all learn german. it's simple. ;)
<popolon>
but english is easier for german or latin family language speaker
<mnemoc>
popolon: but chinese has an awful amount of glyphs :<
<rellla>
Maqs: +1
<popolon>
not so far
<popolon>
214 only
mSquare has joined #arm-netbook
<mnemoc>
uhm
<Maqs>
aren't there simplified versions with syllabary? or was that japanese?
<popolon>
other are combination of those 214 characters but the word is in a square instead of a line
<mnemoc>
214 glyphs and no fancy grammar.... sounds even affordable
<Maqs>
ain't nobody got time for that ;-)
<popolon>
for japanese you need to add hiragana and katakana and there is grammatical conjugation
<popolon>
and lot of honorific twist inherited from korean
<Maqs>
plural is just ol (from english all).. etc.
<popolon>
looks like french créole (used in american and african french islands
<Gumboot>
I'm just slightly baffled by Simplified Chinese. The half-arsed explanation I got once was that it's a syllable per character, and simpflified breaks a few things into multiple characters, which implies multiple syllables. So it must change the spoken language as well.
<Maqs>
popolon: yes, it's a contact language spoken in papua new guinea... some call it a creole, some a pidgin. depends :)
<popolon>
gumboot : simplified chinese is only about characters, some chinese characters are simplified the same way in japanese
<Maqs>
it's quite amazing how easy it is.. in case one knows the vocab and does not confuse it with english :-)
<popolon>
about writting I mean
<popolon>
pronounciation in chinese is always 1 character = 1 syllabe
<popolon>
but in japanese a character (if they use japanese pronunciation, not chinese one, has both characters have several pronunciation) can represent several syllabs
<Maqs>
i'll just stick with english.. sounds a lot easier :-)
<popolon>
I like this kind of language, simple but good enough to describe any kind of idea
<Gumboot>
popolon: But that's my point. If it's 1 character per syllable, and simplified uses multiple characters for some things, then isn't that going outside of just written?
<ZaEarl>
I did a game once with simplified and traditional chinese language options. Glancing through the data files I could see no difference between the two!
<popolon>
simplified only simplified the shape, changing the keys
<Gumboot>
Perhaps it's the case that some of them got _too_ simple, and the collisions needed to be clarified.
<popolon>
in traditionnal or simplified form, that's the same about pronunciation
<Gumboot>
I've seen things written down both ways and they definitely have different numbers of characters.
<popolon>
畫<= traditionnal for painting (used in taiwan/hk/macao/singapour)
<popolon>
画 <= used in mainland china and japan
<Gumboot>
Now why's that not rendering on my screen/
<Gumboot>
?
<popolon>
only the bottom part of the char is kept
<popolon>
Gumboot, just because you don't have international fonts
<mnemoc>
or utf-8 not properly configured
<Gumboot>
The latter.
<Gumboot>
I got latin mojibake.
<mnemoc>
i see the glyphs... but they are so small I can't notice any difference :<
<popolon>
in japanese the top horizontal bar is linked to the field (from rice pad) : 田 by a little vertical stroke, not in simplified chinese, but any japanese or chinese don't see that :)
<Gumboot>
Actually, UTF-8 normally works. It's just this channel.
<mnemoc>
it's not a per-channel thing :)
<popolon>
Gumboot, I guess you configured freenode with iso-8859-1
<Gumboot>
Not deliberately, I didn't.
<cat_x301>
popolon: not sure if yes for the answer, but firefox 10.0.7 :D
arokux has quit [Remote host closed the connection]
arokux has joined #arm-netbook
<mysteryname>
Hey, I'm having a problem building the u-boot for sunxi, Where the make file says there is no arm-linux-gnueabi-gcc command, however I have arm-linux-gnueabi-gcc-4.6 is there a quick fix for that?
<mnemoc>
install gcc-arm-linux-gnueabi to get the symlinks
<Gumboot>
Actually, following instructions looks like a good way to make things worse.
<Gumboot>
Freenode must surely be a utf-8 network, right?
<popolon>
generally yes, most channels use UTF8
<mysteryname>
mnemoc: I thought I installed it?
<mnemoc>
mysteryname: i can't know if you did :)
<mysteryname>
mnemoc: It's in my PATH and I'm able to build a really small *.c file using arm-linux-gnueabi-gcc-4.6 however I don't seem to have vanilla gcc for the make file to see.
avernos has quit [Remote host closed the connection]
<Turl>
mnemoc: do you recall me telling you guys my screen was doing weird stuff on early boot btw?
<Turl>
mnemoc: the patch fixes that too :p
pawel5870 has quit [Quit: Leaving.]
pawel58701 has joined #arm-netbook
pawel58701 has quit [Client Quit]
pawel5870 has joined #arm-netbook
<mnemoc>
so it's all about the overclocked pll6
<Turl>
yeah
<Turl>
mnemoc: the only fear I have is, well, sata :<
pawel5870 has quit [Ping timeout: 245 seconds]
<mnemoc>
can test sata atm, will do tonight
<Turl>
:)
<mnemoc>
hopefully others can report first
avernos has joined #arm-netbook
avernos has quit [Changing host]
avernos has joined #arm-netbook
pawel5870 has joined #arm-netbook
<lundman>
adeswfo
slash_random has joined #arm-netbook
avernos has quit [Ping timeout: 246 seconds]
<lundman>
ok I just changed the clock to tmpSclk->clk->rate = 9999999999;
<Turl>
lundman: it's over 8000!
<Turl>
slash_random: o/
<lundman>
got to get it over 88 before it will go back in time!
<Gumboot>
Does the A10 fit into this whole unification thing in Linux 3.7? That's the fruit of Linaro's effort, right?
<mnemoc>
Gumboot: not yet, but will
<Gumboot>
I actually don't know either way about Linaro's involvement, but my understanding is that they set out to bring some coherency to the ARM platform. I don't know how well non-members fit into that.
* Gumboot
finds it odd that despite all the fear that BSD licenses would allow corporations to "steal all our work", these corporations are all still mashing their binary-only blobs into a GPL kernel.
<mnemoc>
thing is corporations don't care about the license at all
<Turl>
Gumboot: BSD kernels aren't nearly as compatible as linux
<mnemoc>
and GPL enforcement ends up been even more harmful
<Gumboot>
Turl: None of them are compatible. That's why they're adding their blobs.
<Turl>
Gumboot: supporting an ARM chip on linux is comparatively easy
<Gumboot>
Corporations do care. I've been restricted to contributing only to BSD projects because of the infection risks to my employer.
<Turl>
and you instantly acquire support for a crapload of usb peripherals and the like
<Turl>
*BSD doesn't even offer official ARM support I think
<Gumboot>
OpenBSD has a little. I have to assume NetBSD has a lot more. Don't know about FreeBSD.
<Turl>
your employer has -ETOOMANYLAWYERS
<Gumboot>
They all do.
rsalveti has quit [Ping timeout: 252 seconds]
<Turl>
'infection' is lawyer bs talk, it's not hard to comply with the GPL
<Gumboot>
You'd be surprised at how difficult people find it.
<Gumboot>
As an SoC vendor, you need only worry about the peripherals you actually etch into the silicon. Linux's huge collection of drivers is mostly immaterial.
<Gumboot>
Real contamination probably isn't the greatest risk. Perceived contamination is.
<Turl>
a vendor cares on the other hand, because if they sell you something with a USB port they don't want you claiming 'it's broken' because your peripheral is not supported
rsalveti has joined #arm-netbook
<Gumboot>
I really have never noticed a compatibility issue with a USB device on any BSD.
<Gumboot>
Except for when the controller itself isn't properly supported.
mysteryname has quit [Ping timeout: 260 seconds]
<Turl>
I haven't actually used *BSD to comment either, but I've seen really weird USB hardware I wouldn't be surprised if *BSD didn't support
<Gumboot>
I wouldn't be sure that an Android device would come bundled with the appropriate modules for a situation like that.
<Turl>
yeah, it probably doesn't
<Turl>
stuff like the chromebook on the other hand, I'd expect it did
<Gumboot>
What's a weird USB device, anyway? Like a TV tuner or something?
<Gumboot>
I might actually be a bit annoyed if I discovered that my android device didn't support that. Maybe something weirder.
<Turl>
Gumboot: no, more like a seemingly 'standard' device, but that requires some quirks to operate
* Gumboot
is reminded of the blacklist/whitelist arrangements in some late PATA controllers.
<Gumboot>
Anyway... I'd best go to work, or I won't be able to buy pointless crap anymore.
<Turl>
:P
rz2k has quit []
silentaa has quit [Ping timeout: 245 seconds]
silentaa has joined #arm-netbook
<libv>
don't have a suitable low power sata disk that i want to sacrifice for a10 testing right now :)
<Turl>
china needs to sell cheap sata disks :<
<libv>
i think they are cheap enough, i just do not have any around :)
<libv>
postage & customs are the real killers imho, and having to wait X days
<libv>
maybe i am just amazon spoiled :)
techn_ has quit [Read error: Connection reset by peer]
<bfree>
not sure sata spinning disks are cheap enough thanks to the flood/gouging, I'm pondering a ssd for my cubie as basically same price as the cheapest spinning disks! I've a few months to decide though :-/
<Turl>
bfree: on $/GB, HDDs still have quite a considerable bit ahead
<bfree>
sure, but I don't forsee needing much space really so an SSD looks tempting to me
orly_owl has quit [Quit: leaving]
drachensun has joined #arm-netbook
<traeak>
get an older ssd, sata2 won't be able to fully push an SSD
ol1ver has quit [Quit: ol1ver]
<bfree>
yep, considering that (though as maybe I'd end up swapping it elsewhere at some point not tooo pushed) ... would rather a Samsung 830 or so (reliability, flashing) but the older OCZs seem to have crashed in price to tempt me
ol1ver has joined #arm-netbook
silentaa has quit [Ping timeout: 252 seconds]
slash_random has quit [Ping timeout: 256 seconds]
robws has quit [Read error: Connection reset by peer]
silentaa has joined #arm-netbook
robws has joined #arm-netbook
<libv>
pfff, this stuff is way fragile
<traeak>
what's way too fragile?
<traeak>
i just used the mele as an opportunity to upgrade a laptop drive, put the old drive in the mele
pawel5870 has quit [Ping timeout: 276 seconds]
<libv>
my mele
<libv>
i just threw a new kernel over the the u-sd, and now uboot is buggered for some reason
<RaYmAn>
that should only really happen if the card is partitioned wrongly (such that writing a file accidentally overwrites the u-boot sectors?)
<libv>
it was booting fine before
<libv>
but i guess i have to go clear the first bit and reinstall uboot again
<libv>
all because i cped over the stage kernel, which actually has the exact same code as the kernel that i ran last night
<libv>
so rather fragile really
<traeak>
heh, not *that* fragile
<traeak>
you can fix this all in software
<traeak>
compared with scratching the mobo to expose a lead to short to force it into service mode
mSquare has quit [Ping timeout: 260 seconds]
L84Supper has quit [Remote host closed the connection]
<libv>
i have a local copy of that branch, but there is no point in keeping it anywhere else
<lkcl>
t0dbld: Hexxeh is a "burst-mode" IRC user :) best to ping him with a PM or gchat
<hno>
libv, I power mine from USB, never seen any booting issues. But otoh I only have UART & SD connected, and don't do anything fancy such as framebuffer or the like.
<libv>
yeah, display and network seem to eat a bit more power
Quarx has quit []
<hno>
But still. 1A@5V is plenty. Maybe it did not provide a stable regulated 5V power?
<libv>
with 2.5A it seems pretty happy
<libv>
i do not know this is 10EUR universal switching psus
<libv>
so not a proper lab psu
<libv>
i would have to dig out the mele box to find out what it needed originally
<libv>
ah, underside says 2A
slash_random has joined #arm-netbook
<mnemoc>
libv: so libv_disp ready for stage?
<libv>
mnemoc: yeah, i'd guess so
<mnemoc>
cool
<mnemoc>
thanks :)
<libv>
my hyundai should be here tomorrow though, but slapin said that the display is simply not working with the sunxi kernel
<mnemoc>
ow
<libv>
i will be opening it up immediately, attaching serial, and seeing what is attached
<libv>
for an lcd
<mnemoc>
:)
<libv>
people are playing with xbmc on android as well, right?
<Maqs>
they are.. but nothing a10/mali specific so far afaik
<libv>
is that xbmc using android infrastructure then (as android can offer different colour space buffers for you, and the hw composer then should do things properly), or is xbmc talking to the sunxi disp directly?
<libv>
because there is no infrastructure for tracking who is doing what
<mnemoc>
android provides a "player"
<mnemoc>
which other players just wrap
<Maqs>
the only thing i can tell is that hardware acceleration with xbmc on android does not work
<Maqs>
or at least not with a10/mali
<libv>
ok, so the (incorrect) use case of xbmc going around surfaceflinger should not be supported indeed
bsdfox_ has quit [Read error: Connection reset by peer]
<libv>
should more than a single application use disp at this point, should that be allowed at this point?
<Maqs>
i think the thought is to support the platforms directly rather than making a detour using android-stuff
<libv>
ah, but this guy is not involved with the specific a10 xbmc port
<Maqs>
i don't know whether empat0 ports xbmc for android as well or only to linux
<Maqs>
s/for/to/
<ibot>
Maqs meant: i don't know whether empat0 ports xbmc to android as well or only to linux
<libv>
because even for the simplistic versioning handshake i want to track which /dev/disp opener has which version, so i can pr_warn if someone does not do the version check
dfletcher_ has joined #arm-netbook
<libv>
i also do not want test apps from being unable to poke at things... and do not want to overcomplicate things or do any rewriting of the disp interface
<libv>
so i guess i'll just track #define, and then refuse further opens if more than #define try to keep /dev/disp open
hp__ has quit [Ping timeout: 276 seconds]
dfletcher__ has quit [Ping timeout: 276 seconds]
<Maqs>
i'm really looking forward to something more lightweight than xbmc with hardware decoding
<traeak>
android?
revident has joined #arm-netbook
<techn>
Maqs: there was some post on ML
<techn>
ok.. it's no good
rellla has quit [Quit: rellla]
<slash_random>
hi people. I've purchased an A10 based tablet (from Gemei) and I'd like to plug an usb-serial adapter (ftdi based). Could any body point me out which would be the easiest way to recompile the kernel and still keep (when possible) the original android 4.0.3?
<Turl>
mnemoc: I could set up a symlink to avoid downloading it twice, but android devices often need extra hacktastic patches on top of the tree (*cough* touchscreen *cough*) :P
<t0dbld1>
Turl: that depends does his touchscreen manufacturer still exist *cough zatab*
<Turl>
mnemoc: the main issue is that integrating more with the BSP means 'deintegrating' the android build itself :<
<Turl>
t0dbld1: haha
<t0dbld1>
:-)
<mnemoc>
Turl: you can see it differently. refactoring it so it can be used for different devices without manual intervention
<mnemoc>
instead of "deintegrating"
<mnemoc>
obviusly that doesn't need to affect the repos you are already using for the zatab
<mnemoc>
i suppose it only affects the device tree, for which you already have a not-zatab template
<Turl>
mnemoc: what do you mean by "without manual intervention"?
<mnemoc>
that no human needs to edit the device/foo to get basic support
<Turl>
mnemoc: you need a device tree to build android
<mnemoc>
sure
<Turl>
devices don't get magically configured out of nowhere :<
<mnemoc>
our devices are VERY similar
<Turl>
and so different at the same time
<Turl>
an android build with the wrong userspace libs for the g sensor, misconfigured camera, wrong touchscreen driver loaded, isn't useful really :<
<mnemoc>
more than a per-board overlay dir?
<Turl>
mnemoc: the device trees are just a bunch of knobs you can tune, all the common sunxi stuff is on the common device tree
<Turl>
(eg the actual code for gralloc, hwcomposer, sensors, display, etc)
<Turl>
that went unmaintained when we jumped over to jellybean :< I should redo it one day
<mnemoc>
:'(
<Turl>
mnemoc: worry not, cubie 1G is likely to get support in the not so far future :p
<lundman>
iwant jb
freakazoid0223 has quit [Ping timeout: 256 seconds]
<t0dbld1>
thats what hes working on
<mnemoc>
i want a template for jb, not jb for the cubie
<mnemoc>
but i would be happy having both :p
<t0dbld1>
hah
<t0dbld1>
template for jb ? download sauce , build device tree, hit make ... repeats steps 2 and 3 after fixing errors
<mnemoc>
template for the device tree
<Turl>
mnemoc: you look like a sed power user :P that's what the template was anyway
<t0dbld1>
well the tree for another allwinner device will be pretty damn similar to the zatabs use that and than you jsut gotta fix all the difference in libs
<mnemoc>
Turl: having the template, I can populate it, no problem with that part :)
<mnemoc>
but i don't want to learn android internals at all :p
<Turl>
mnemoc: zatab + s/zatab/DEVICE/g was the template, pretty much :)
<mnemoc>
:D
<t0dbld1>
lol welll than pray all your binary libs and bits work
<t0dbld1>
:-P
<Turl>
t0dbld1: they're all the same :P
<t0dbld1>
than wahts his struggle :-)
<t0dbld1>
hit make and flash :-)
<mnemoc>
then what was all the BS you told be before about how impossible it was to have generic support? :<
<hno>
mnemoc, when you have time then please try uboot-patchqueue on your devices.
<Turl>
mnemoc: it'll still be a zatab build though, until you adjust it to fit your device
<hno>
it's the tree that is being prepared for mainline submission, and there have been some changes.