<oliv3r>
[1004998.467861] usb 1-5: Manufacturer: Allwinner
<oliv3r>
[1004998.467862] usb 1-5: SerialNumber: 20080411
<oliv3r>
this means its not in fel mode, right?
<oliv3r>
i was hoping it would boot to fel mode :(
<oliv3r>
Turl: i think they control several sections with 1 bit
<oliv3r>
Turl: it's in the datasheet that way, and their chinglish is hard to understand sometime
<oliv3r>
Turl: but i think its 1 bit per address line or something? or maybe it's just 1 bit and the rest nop
<oliv3r>
i don't know :)
<oliv3r>
but, the kernel with the nand fix boots, it refuses to mount /system though (nandd) so i have a running kernel with running initramfs, /cache is mounted, but not nandd (/system)
<oliv3r>
nvm, it's running an old kernel; so it probably boot recovery mode!
<oliv3r>
also, while the kernel boots and I can access android, i can no longer obtain root permissions and the hardware engine gets permission denied errors: http://paste.debian.net/245070/ is a short paste of the log
<calris_>
oliv3r: and another idea - .rodata and .bss do not really need to be in the 20kiB loaded from MMC
<calris_>
oliv3r: .bss is already not part of the 20kiB (it's located in SDRAM at the moment)
<calris_>
oliv3r: But the cool thing is, we could actually use SPL to load it's own .rodata from the MCC
<oliv3r>
calris_: TrustZone-capable processors start executing in Secure state on power-on, if the boot loader does nothing to change the security state, all software will run as Secure (removing any security benefits).
<calris_>
oliv3r: Of course, that is provided the MMC driver does not need .rodata
<oliv3r>
calris_: how can .bss be in SDRAM if SDRAM isn't available/initialized
<Turl>
oliv3r: my bet is that you didn't upload the modules .ko to match the new kernel
<calris_>
sdram is initialised before .bss is accessed
<Turl>
s/upload/update/
<oliv3r>
Turl: i did :p
<oliv3r>
Turl: but would that prevent me from having root?
<Turl>
if you mean su by root, no
<Turl>
su is just a suid binary
<oliv3r>
Turl: i get 'permission denied'
<oliv3r>
so how did a kernel swap break that? ramdisk is exactly the same
<oliv3r>
Turl: and how can i best fix it?
<oliv3r>
i know i have to fix the ramdisk anyway, cause there's stupid modules being loaded i don't have anymore and won't use/need
<oliv3r>
(initramdisk loads modules)
<Turl>
oliv3r: idk, did you check permissions to see why it's denying them?
<oliv3r>
calris_: i'll admit i know nothing of .rodata, .bss etc :p but SPL does of course put the boot1 loader into sdram; that's its sole purpouse, load mmc driver, read boot1 to sdram
<calris_>
SPL loads U-Boot into SDRAM
<oliv3r>
calris_: boot1/u-boot yes sorry :)
<oliv3r>
i was thinking of boot0's sole purpose; but it's identical yeah
<oliv3r>
Turl: you mean permissions on the su binary?
<oliv3r>
oh, wait
<oliv3r>
Turl: to be able to su, you need the binary. if /system doesn't get mounted (where su is on) it can't su :)
<oliv3r>
of course, why can't it mount /system :)
<oliv3r>
i'll just copy the su binary into my initramfs for now
calris_ has quit [Quit: Page closed]
hansg has joined #linux-sunxi
<oliv3r>
Turl: where is your android tree again? can i copy your initrc/ramdisk?
<Turl>
techn_: I just saw your pull req, can you set the branch to pull to correctly on it?
<oliv3r>
Turl: i've put su into the initramfs under /sbin
<oliv3r>
so should hopefully work now :)
<oliv3r>
Turl: i'll have to talk to you abotu init.sun4i.rc sometime; not so sure it's 'up to date' or even correct; but i don't know anything about this stuff, so don't know
e-ndy_ is now known as e-ndy
<Turl>
oliv3r: ok, feel free to email or msg me about it anytime
<shineworld>
[ 3.690000] mmc0: new high speed SDHC card at address 4107
<Turl>
or just enable that option on kernel (CONFIG_LBDAF) if you don't want to touch fs
<shineworld>
I will re-compile the android with new option
<shineworld>
thanks for help
<Turl>
you're welcome
wingrime has joined #linux-sunxi
<oliv3r>
Turl: for example, why does sun4i.rc use /mnt/sdcard where it seems that /storage/ is more common these days
<Turl>
what branch are you looking at?
<oliv3r>
Turl: oh excellent question
<oliv3r>
i alwas forget that; i assume master is good for some reason :)
<Turl>
master is ics
<Turl>
aka the oldest :P
<oliv3r>
Turl: so jb is best
<oliv3r>
ok, i'll compare that and probably use that :)
<oliv3r>
yeah that looks much better
<oliv3r>
Turl: ok then why is uevent listing all device entries? i thought it should list only unique to sun4i entries, since both uevent.rc and uevent.{target}.rc are loaded?
hramrach has joined #linux-sunxi
<oliv3r>
ok this is strange, i'm sure i've added my own kernel; but it boots the old kernel, with my new ramdisk?!
vicenteH has quit [Ping timeout: 248 seconds]
<oliv3r>
oh bah, android doesn't work at all; i kept dd-ing the file to /dev/nandc instead of /dev/block/nandc so i never loaded a new kernel
<mnemoc>
Turl: thanks for the URLs. will try to adapt soc-detect to something similar
<oliv3r>
what is boot.scr; and why is it optional for hwpack, but required for android (yet the make file doesn't depend on boot.scr)
gzamboni has joined #linux-sunxi
<hramrach>
it tells the boot loader what to do
<oliv3r>
boot.script :D i guess when building an android image that gets loaded by boot.axf it's not important
<hramrach>
if you have one already the hwpack does not need to provide a new one. Actually it should not to be as compatible as possible with different devices and boot methods
<hramrach>
I don't do android so I have no idea what does it need boot.scr for
<hramrach>
you can get away with compiling arguments int u-boot and kernel
<oliv3r>
hramrach: sunxi-bsp fails on missing boot.scr ;)
<mnemoc>
oliv3r: for android boot.scr seems to be mandatory.
<mnemoc>
but linux it's optional. and uEnv.txt is prefered anyway (uEnv.txt is plain text, boot.scr needs to be pre-compiled)
<oliv3r>
ok so how do I tell mkbootimg that it has to use a boot.scr (which fails to build atm, but I can sort that later)
<mnemoc>
touch boot.scr ?
<mnemoc>
I doubt u-boot will die if the file is empty
<shineworld>
well my system is perfectly working now :)
<shineworld>
just to match specs have you run Antutu bench on cubie-ics ? I'm interested to match RAM/CPU and FLOAT values (first three in bench result) ... overall float because I use intesively float
<shineworld>
what I was amazed is Float result : 164 ... my Xperia X8 (running Cyanogenmod 7) with armv6 reach 217 and is only a 600Mhz
<shineworld>
don't matter... works
<mnemoc>
using the fantasy governor?
<shineworld>
always ondemand
<mnemoc>
by default ondemand is very slugish
<shineworld>
could be something changed in antutu from 3.0 to 3.2
<shineworld>
do you use onsmartassv2 ?
<mnemoc>
i don't use android except on my nexus devices
<shineworld>
ah ok ... I use only android
<mnemoc>
and there I use (rooted) stock images from G.
<shineworld>
linux was an easter egg found inner :)
<mnemoc>
:)
<shineworld>
however I'm ready to move to a more fresh android version for cubie
<mnemoc>
for the sake of testing try using 'performance' instead of 'ondemand'
<shineworld>
what repo do you suggest ? (there are so much forks in git ..)
<mnemoc>
linux-sunxi's obviusly
<mnemoc>
noticed on what channel you are? :p
rellla has quit [Remote host closed the connection]
<shineworld>
yeah, but I've saw that there are a lot of guys (like Turl) that often mention other git places (or I'm doing confusion with chat) :)
<mnemoc>
devs have personal repos
<mnemoc>
but stuff converges on linux-sunxi's repo
<mnemoc>
back in 15m
<shineworld>
uhm... I'm lost
<mnemoc>
if you want to make a long term image, use linux-sunxi's sunxi-3.0
<shineworld>
I don't find android sources and that page make me confusion about where git could be : http://linux-sunxi.org/Android
<mnemoc>
if you want to help testing new patches, use stage/sunxi-3.0 or (after a direct recomendation) a personal branch of a dev
<mnemoc>
if you want to help testing 3.4 on android, use stage/sunxi-3.4
<shineworld>
ah ok !
ZaEarl has quit [Quit: Ex-Chat]
<shineworld>
my mistake was thinking that linux-sunxi manages a repo of android sources, instead it manages the kernel matter ... I'm falled in wrong :) sorry for mistake
ZaEarl has joined #linux-sunxi
n01 has quit [Read error: Connection reset by peer]
<mnemoc>
shineworld: turl maintains the CM repos for sunxi, but haven't convinced him to move that in yet
n01 has joined #linux-sunxi
ganbold_ has quit [Remote host closed the connection]
<Turl>
oliv3r: those files are based on AW's so they might contain uncleaned extra stuff
<Turl>
mnemoc: yw
<mnemoc>
Turl: I'm still shocked by your choice of calling sun4i "everything except sun6i"
<Turl>
it's not everything except sun6i
<Turl>
it's "sun4i-compatible"
<mnemoc>
:)
<Turl>
if sun6i isn't there'll be a sun6i driver and anything compatible with it will use it
shineworld has quit [Quit: Leaving]
<Turl>
say, sun8i or whatever
<mnemoc>
ok. the sun4i-compatible thing makes sense
<mnemoc>
:)
<Turl>
mnemoc: when the idea "clicks", it makes a lot of sense :)
<mripard_>
mnemoc: the point was with the introduction of A31, if we didn't change that, we would have had, for example two compatibles for the watchdog
<mripard_>
a sunxi-wdt
<mripard_>
and a sun6i-wdt
<mripard_>
which didn't make any sense
<mripard_>
(plus what said Turl )
<mnemoc>
mripard_: in the case of -wdt, why can't the same .ko handle both?
<Turl>
mripard_: Mike already merged the clock compatible rename btw
<mripard_>
mnemoc: it can, it's not really a matter of how it's implemented
<mripard_>
but more what is the behaviour, and are those two compatible
<mripard_>
and the fact is that, even if it's a tiny difference, they aren't
<mripard_>
but you can definitely have a single driver that handle both cases
<mnemoc>
what I fear is to end up having sunNi-foo.ko in mainline and with an N that does't match the family name
<mripard_>
hmmm, I see your point
<mripard_>
but keep in mind that while the internal code organization can change at any time
<mripard_>
the dt binding can't
<mnemoc>
from a code perspective, sunxi-foo/sunNi.c and sunNi_ prefixed methods inside a sunxi-foo.ko with proper compatibility ot matching should work cleanly
<mripard_>
so we can always address a bad module naming
<mripard_>
not a bad compatible choice
<mnemoc>
having sun4i-foo.ko modules loaded on a sun5i sounds awful
<mnemoc>
and having sunNi-foo.ko for each sounds even worse
<mnemoc>
while the same sunxi-foo.ko + ot matching voodoo will know what to use
<mnemoc>
and keep it clean from a code and a lsmod/user perspective
<mripard_>
to me, having a sunxi-wdt.ko stuff, but you know, it's sunxi, but without sun6i, sun7i, and whatever name will follow
<mripard_>
+sounds awful
<Turl>
mripard_: is there any work pending on pinctrl?
<mripard_>
Turl: more or less, why?
<mnemoc>
what I'm telling is that sunxi-wdt.ko should handle them all, BUT use ot matching to know what specific soc compatibility to use
<Turl>
mripard_: because Linus asked if we want to take the clock pinctrl patch via him or other tree
<mripard_>
Turl: and yes, I saw that mike merged it
<mripard_>
ah, yes, I saw the mail
<wingrime>
mnemoc: can we join "sun4i-i2c" and "sun5i-i2c" naming ?
<wingrime>
mnemoc: will it break compat?
shineworld has joined #linux-sunxi
<mnemoc>
and instead of sun4i-foo.c and sun6i-foo.c, sunxi-foo/sun{4,6}i.c + glue.c
<mripard_>
mnemoc: like I can said, we can always figure that later if that's not convenient enough for you
<mnemoc>
mripard_: i'm not telling what is convenient for me. I'm asking for not making sunNi-foo drivers and handling the N diff within dts and inside the driver, to keep lsmod and user sanity
<wingrime>
mnemoc: can you apply mine unification patches
<mnemoc>
wingrime: sunxi-i2c should be fine
<mnemoc>
wingrime: poke me again in ~2h, really busy with $work$ and working from a coffee shop :
<mnemoc>
:|
<Turl>
mnemoc: at least you're drinking good coffee I hope
<wingrime>
:|
<mnemoc>
Turl: indeed :)
<mnemoc>
mripard_: sooner than later a diff within one particular soc will arise and this split away policy will become even uglier
<mripard_>
mnemoc: if your only concern is about probing, send a patch to add a module alias to sun5i whatever
<mripard_>
like I said, we'll see when that SoC comes to do whatever's needed to make it clean
* mnemoc
shuts up and returns to his dog washing job
<Turl>
mnemoc: did you get to use sunxis for washing dogs yet?
<mnemoc>
it seems I'll be stuck with via-based "industrial" din-rail computers for a while
<wingrime>
Trul:mnemoc: how about to add revision and serial to cpuinfo
<wingrime>
Trul: a13 manual says that cpu have unical number
FergusL has left #linux-sunxi ["Quit"]
<mnemoc>
wingrime: the soc-detect branch has the change to allow retriving it
<mnemoc>
in theory
<wingrime>
"in theory"?
<wingrime>
what a problem
<Turl>
it doesn't work reliably yet
dolence has joined #linux-sunxi
<dolence>
hello everyone!
<Turl>
hi dolence
<dolence>
please, I'm a bit confuse regarding installing X + mali drivers on debian linux-sunxi
<wingrime>
mnemoc: I need you apply my PM, device.c , cedarx unification patches , expectly device.c, I want remove some SUN4I snd SUN5I defines, for make naming "sunxi-i2c",so I need patch device.c for it too
<mnemoc>
wingrime: ok
<wingrime>
mnemoc: all patches for 3.4 and now seems have one line conflict with last patch
<dolence>
after compilling kernel with mali400 enabled as module and installing rootfs on SD card, I wasnt suposed to have a mali400.ko module file?
<wingrime>
dolence: mali rebuilds every time after make
<techn_>
Turl:
<dolence>
3.4 sunxi
<dolence>
should I be using stage?
<techn_>
Turl: rechecked my pull request.. looks really weird :(
<wingrime>
dolence: can try, it should be more fresh
<dolence>
wingrime, I will do it, ty again
<wingrime>
dolence: are you set "arch"
<techn_>
Turl: why I have your commits in that request?
<wingrime>
dolence: stupid question
<wingrime>
dolence: are you used "make modules"
<dolence>
I'm doing: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j 3 uImage modules
<dolence>
it's buildind ohter modules
<dolence>
*other
<techn_>
Turl: ok.. manifest uses jellybean
<techn_>
Turl: I'll redo pull request
<dolence>
wingrime, which mali driver are you using? binaries or lima one?
<wingrime>
none
<wingrime>
I not need mali for testing ui
<wingrime>
mali for opengles only for now
<rz2k>
<wingrime> dolence: mali rebuilds every time after make - if you feel like want to rewrite mali kbuild - feel free to do that.
<rz2k>
s/kbuild/makefile/
<wingrime>
rz2K: threre is more interesing stuff to do
<rz2k>
hint: that makefile is a total mess consisting of ARM top notch production
<dolence>
wingrime, I wish to run an opencv application running webcam on fullscreen
<wingrime>
dolence: now it hard
<wingrime>
dolence: usb have some problems with web cams
<dolence>
hmmm drivers nto working?
<dolence>
*not
<wingrime>
dolence: not, some problems related usb-host code
<wingrime>
dolence: with big "messages"
<wingrime>
dolence: you should try get some shots
<wingrime>
form webcam
<dolence>
ok
<wingrime>
ssvb: what with "xv" for playing video?
rz2k has quit []
<ssvb>
wingrime: xv should be relatively easy to implement, that's in my todo list
<ssvb>
wingrime: are you using mplayer?
<wingrime>
ssvb: make it hi prior, becose I want see video even without cedarx
<wingrime>
ssv: mplayer the best
<wingrime>
ssv: vlc too heavy
<ssvb>
yeah, cedarx is the primary reason why I did not consider xv a really critical feature
<wingrime>
ssvb: in current state cedarx notusable
<ssvb>
I have not tried it myself yet :)
<wingrime>
ssvb: As i readed manual a13 can have layers even with alphablending
<ssvb>
yes, except a13 has only one scaler (a10 has two of them)
<wingrime>
ssvb: we need use one layer for cedarx/xv output and crop/scale to window
<wingrime>
ssvb: like mouse one
<ssvb>
if somebody uses "fb0_scaler_mode_eable" option in fex, then this scaler is wasted
<wingrime>
ssvb: send patch to kernel for prevent this
<ssvb>
one get the ability to arbitrarily change screen resolution at runtime with fbset in scaler_mode
<ssvb>
also scaler_mode is needed for interlaced hdmi output
<wingrime>
ssvb: #ifdef for sun5i
<mnemoc>
it seems a12 and a10s have g2d...
<wingrime>
ssvb: agh... we still can't differ a13/a12
<mnemoc>
wingrime: that's what my soc-detect branch tries to do. will give it another try tonight
<wingrime>
mnemoc: need someone who can look at g2d register base at a13
<ssvb>
well, it's up to the user to provide suitable configuration, the xorg driver can just try to get a scaled layer and if this fails - log a reasonable error message with a hint
<mnemoc>
i have an a13-olinuxino.... in a yet-to-be-determined box
<ssvb>
the hardware cursor does not need a layer, also there are some sort of 'sprites' which I never tried to use
<wingrime>
ssvb: layers seems to be for videooverlay defenetly
<ssvb>
wingrime: there is ioctl for requesting a disp layer, and it may fail
<wingrime>
ssvb: it looks disp code still crap...
<wingrime>
mnemoc: patch time :>
<mnemoc>
ok ok
<ssvb>
wingrime: well, if ioctl fails, then we know that there is no suitable layer available
<wingrime>
we need cpuinfo with soc-detect for userspace stuff also
<ssvb>
wingrime: yes, disp driver is 'crap' but it does not cause too many problems
<mnemoc>
wow... I have a nand patch from Turl stared since oct 2012
<wingrime>
ssvb: less crap than usb)))
<paulk-desktop>
hi, I want to build uboot for a chinese nuclear tablet
<paulk-desktop>
what's the uboot config to use?
<wingrime>
paulk-desktop: a13?
<paulk-desktop>
yep
<mnemoc>
nuclear is the generic name for a13-android
<wingrime>
paulk-desktop: read manual on github
<mnemoc>
u-boot needs board specific details
<paulk-desktop>
which branch to use from github also?
<mnemoc>
sunxi is the stable branch
<mnemoc>
but you need to add your board
<mnemoc>
and submit it's .fex
n01_ has joined #linux-sunxi
n01_ has quit [Read error: Connection reset by peer]
<mnemoc>
wingrime: [linux-sunxi] [PATCH] sunxi: unify sun4i and sun5i platform devices to single.eml doesn
<mnemoc>
wingrime: [linux-sunxi] [PATCH] sunxi: unify sun4i and sun5i platform devices to single.eml doesn't apply on stage/sunxi-3.0 nor stage/sunxi-3.4
<wingrime>
ok drop it
<wingrime>
I make it again
<mnemoc>
wingrime: if you have it already rebased, can you paste me the git-format-commit ?
<wingrime>
mnemoc: I make it with unification i2c naming
<wingrime>
in single commit
<mnemoc>
so I wait for a v2 ?
<wingrime>
whait
<wingrime>
i try rebase this
<libv>
mnemoc: how did the move go?
<wingrime>
newer tryed this
<wingrime>
mnemoc: wait v2 , try apply cedar and pm
<mnemoc>
libv: pretty well. unfortunatelly I still don't have electricity :| and today is the last working day of this week for them
<libv>
mnemoc: whut? ouch
<mnemoc>
national holidays :\
<libv>
mnemoc: in germany electricity is never shut off even when the place is not inhabited for a few months
<mnemoc>
bad week to move to a 0km apartment
<libv>
0km?
<mnemoc>
libv: this is first activation
<libv>
ah, ok
<libv>
new :)
<mnemoc>
waiting for the counter to be installed :p
<mnemoc>
yes. new :)
<slapin>
hno: ping
<mnemoc>
rented directly to the company who built if, and failed to sell it after 2y...
<libv>
mnemoc: so you bought it or are renting it?
<slapin>
hno: hi, have you rebased u-boot patches for recent queue and what is the status with patch submission?
<wingrime>
mnemoc: strange I just merged stage but merge have differences with device.c
<mnemoc>
libv: renting. but cheaper than the old, and ... new :)
<wingrime>
mnemoc: what patch writing to you ?
<libv>
ah, too bad, i think one could make a steal on buying a place in spain right now
<libv>
it will really pay off in a decade or so
<mnemoc>
they haven't dropped the prices a cent
<mnemoc>
pretty stupid
<libv>
hah, their own problem then
<libv>
no wonder the economy is not moving
<mnemoc>
ack
<libv>
if they refuse to drop prices to meet the market...
<mnemoc>
rent prices are going down. but contracts limited to 5y
<libv>
heh
<libv>
they will have to give that one up
<libv>
because before they do, noone will invest in anything new anymore
<libv>
and those places just get run down
<libv>
nobody ever spends money on doing up a place he does not own
<libv>
a side effect of ultra-low intrest rates perhaps?
<libv>
the banks indirectly own those houses but are not making any money off of that loan and the economy stagnated because of it
<libv>
and none of the politicians do anything about it
<mnemoc>
the bank of my region received more money to be saved from bankrupcy than what the gov needs to reduce in spending...
<libv>
all propping up the real estate sharks which still bet on the economy picking up on its own and offloading overpriced houses
<libv>
amazing
<mnemoc>
86m2 on a minor province capital with dead economy, 360k euro
<mnemoc>
and the average rent for that size in this area is 480E
<mnemoc>
don't know what they smoke
<libv>
so they hope to make up for the "value" of the house in 60 years?
<libv>
smart
<mnemoc>
very
<libv>
that's actually even more expensive than what one of the gcc guys and his gf just bought
<libv>
and they will have a nice penthouse 500m away from work and the nuremberg city wall
<oliv3r>
mripard_: yeah i just wanted to find the mail
<oliv3r>
was doubting myself if it ever got sent :)
<mripard_>
it was only sent to the netdev ml
<mripard_>
but not to myself or any other recipients :)
* mnemoc
goes back to the darkness of his new apartment, bye
<oliv3r>
mripard_: sorry
<mripard_>
but I remembered our discussion, so it's not a big deal
<mripard_>
no, that's fine :)
* hramrach
hands mnemoc a torchlight
<mripard_>
it's the web interface that's broken, you had no idea :)
<oliv3r>
mnemoc: as long as you can merge patches :D
<mripard_>
mnemoc: good evening
<oliv3r>
mripard_: btw, sun7i looks to be very much alike sun45i again
<Turl>
mripard_: the uart rework patches are not on arm-soc yet are they?
<mripard_>
oliv3r: ok
<mripard_>
Turl: no, they're not
<mripard_>
I tried to push gkh into merging your serial patch for 8250_dw, and failed miserably :)
rellla has joined #linux-sunxi
ibrah has joined #linux-sunxi
eebrah has quit [Ping timeout: 272 seconds]
<Turl>
mripard_: ok, all sent
theOzzieRat has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
ibrah has quit [Ping timeout: 252 seconds]
simosx has joined #linux-sunxi
simosx has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
dolence has quit [Quit: Saindo]
ganbold_ has joined #linux-sunxi
ganbold has quit [Read error: Connection reset by peer]
n01 has quit [Ping timeout: 240 seconds]
<techn_>
android gadget support wont compile in stage/sunxi-3.4.. /android/kernel/allwinner/common/drivers/usb/gadget/android.c:1565: internal compiler error: in dwarf2out_finish, at dwarf2out.c:18906
<techn_>
propably becouse softfloat build :/
fredy has quit [Ping timeout: 256 seconds]
Guest24544 has joined #linux-sunxi
torqu3e has quit [Quit: torqu3e]
<Turl>
techn_: sounds like the compiler bug Epsylon3 was hitting the other day
torindel has quit [Ping timeout: 256 seconds]
torindel has joined #linux-sunxi
<hramrach>
well, I did build the gadget
<hramrach>
at any rate ICE is always compiler's fault
<hramrach>
the code may be wrong but the compiler should do something sane regardless
<techn_>
hramrach: it builds ok when I build it via sunxi-bsp.. but if I build it with android toolchain it fails
<hramrach>
I build with normal Debian gcc
<hramrach>
make menuconfig, etc
<hramrach>
and floatness should not affect kernel build presumably