Turl changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
popolon has quit [Quit: Quitte]
steev has quit [Read error: Connection reset by peer]
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
steev has joined #linux-sunxi
wingrime has quit [Ping timeout: 240 seconds]
ojn has joined #linux-sunxi
juanfont has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
Gerwin_J has quit [Quit: Gerwin_J]
pwhalen has quit [Ping timeout: 264 seconds]
pwhalen has joined #linux-sunxi
naobsd has quit [Quit: Page closed]
kaspter has joined #linux-sunxi
rz2k has quit []
<libv> aha, a new datapoint... 3.0 kernels had the 8192cu for my hyundai a7hd's wifi
<libv> and this worked just fine
<libv> the 8192cu driver enables/disables the relevant sunxi usb bus
<libv> which it still does under 3.4
<libv> the 8188eu does not enable/disable the required sunxi usb bus, and now we suddenly need to start hacking the script.bin to disable this for us.
<libv> s/disable/enable/
kaspter has quit [Remote host closed the connection]
Seppoz has joined #linux-sunxi
<Seppoz> anybody can help with this kernel error?
<Seppoz> im not running on cubieboard btw
wolfy has quit [Ping timeout: 252 seconds]
<libv> Seppoz: we are at 3.4.75 atm, give that a whirl first and see if the issue reoccurs
<Seppoz> ok
<libv> Seppoz: to trigger the bug, you can should also be able to run e2fsck -f /dev/mmcblk0p2
<Seppoz> let me update the kernel first
<Seppoz> is there any knows bugs with e2fsck?
<Seppoz> on 3.4
<libv> Seppoz: this looks like a bug in our mmc driver
<Seppoz> has there been fixes on .75?
<libv> no idea
<Seppoz> i will just give it a shot
<libv> perhaps mnemoc knows
<Seppoz> i will let you know how that turned out
<Seppoz> too late for me anways
<Seppoz> speak tomorrow
<Seppoz> thanks
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
hero100 has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
egbert has quit [Ping timeout: 246 seconds]
egbert has joined #linux-sunxi
Seppoz has joined #linux-sunxi
kivutar has quit [Quit: Ex-Chat]
bsdfox has quit [Ping timeout: 246 seconds]
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
bsdfox has joined #linux-sunxi
<wens> andhe: the function name to bit number is found in drivers/pinctrl/pinctrl-sunxi-pins.h
<wens> which is just copied from the user manuals
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
jt6562 has joined #linux-sunxi
prasannapete has joined #linux-sunxi
torbenh4 has quit [Ping timeout: 245 seconds]
torbenh3 has joined #linux-sunxi
wens has quit [Read error: Connection reset by peer]
wens has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
futurisk has quit [Ping timeout: 260 seconds]
futurisk has joined #linux-sunxi
HdkR has quit [Ping timeout: 272 seconds]
wens has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
wens has joined #linux-sunxi
<Turl> ohai wens
<wens> Turl: hi
Seppoz has quit [Ping timeout: 240 seconds]
hero100 has quit [Quit: Leaving]
<wens> I'm doing a clock renaming series atm
<wens> also want to merge apb1_mux into apb1
<Turl> wens: iirc I already did that, check my tree
HdkR has joined #linux-sunxi
Seppoz has joined #linux-sunxi
<wens> ah, i see it
hipboi has joined #linux-sunxi
<wens> so you haven't submitted the remaining patches for merging
<Turl> indeed
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
jt6562 has quit [Quit: Page closed]
Akaizen has quit [Read error: Connection reset by peer]
Akaizen has joined #linux-sunxi
[7] has quit [Read error: Operation timed out]
bsdfox has quit [Read error: Operation timed out]
TheSeven has joined #linux-sunxi
bsdfox has joined #linux-sunxi
bsdfox has quit [Ping timeout: 264 seconds]
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
bsdfox has joined #linux-sunxi
Seppoz has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
slapin has quit [Ping timeout: 245 seconds]
slapin has joined #linux-sunxi
jelly-home has quit [Ping timeout: 265 seconds]
hurtigbuffer has joined #linux-sunxi
hurtigbuffer has quit [Ping timeout: 240 seconds]
cajg has quit [Ping timeout: 272 seconds]
hurtigbuffer has joined #linux-sunxi
t3st3r has quit [Ping timeout: 240 seconds]
t3st3r has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
Seppoz has quit [Changing host]
Seppoz has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
hurtigbuffer is now known as jelly-home
bsdfox has quit [Ping timeout: 246 seconds]
bsdfox has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
Seppoz has joined #linux-sunxi
HdkR_ has joined #linux-sunxi
HdkR__ has joined #linux-sunxi
HdkR has quit [Ping timeout: 240 seconds]
HdkR__ is now known as HdkR
HdkR_ has quit [Ping timeout: 263 seconds]
jt6562 has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 246 seconds]
<jt6562> I need the User Manual of A10s, anybody help? TKS
<mrnuke> jt6562: http://bit.ly/1cqqUDv
<jt6562> I can only find A10, but A10s
<mrnuke> A10s, that's sun5i, right?
<jt6562> yes. You mean that A10s likes A13?
<mrnuke> yeah. You might find what you need in the A13 manual
<jt6562> OK, thank you.
TheSeven has quit [Ping timeout: 240 seconds]
Seppoz has quit [Ping timeout: 240 seconds]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
cajg has joined #linux-sunxi
Quarx has joined #linux-sunxi
FR^2 has joined #linux-sunxi
sspiff has joined #linux-sunxi
sspiff has quit [Changing host]
sspiff has joined #linux-sunxi
<oliv3r> libv: 713b but the PCB does say Q8something i belive (see foto)
<mrnuke> oliv3r: aah, just the man I wanted to brag to
<mrnuke> oliv3r: I did the udelay thing for your uboot. it works: https://github.com/mrnuke/u-boot-sunxi/commit/592e73990903270982e5268cf62acad184d9c9e0
<oliv3r> mrnuke: thanks for the patch! i'll try to test it and merge it
ssvb has quit [Remote host closed the connection]
<oliv3r> mrnuke: ML is prefered though :)
<mrnuke> I've heard about the ML
* mrnuke shrugs
n01 has joined #linux-sunxi
<oliv3r> mrnuke: i'll do a weget github.patch :p
<oliv3r> no worries
<oliv3r> i'm easay
<mrnuke> thanks. much appreciated
<n01> 'morning
<oliv3r> the first time
<oliv3r> after that i'm expensive :p
<mrnuke> hehe
<oliv3r> i should look up what USEC_TO_COUNT does
<mrnuke> it's defined like 10 or 20 lines above
<oliv3r> i don't see that in the patch!
<oliv3r> but it's a sunxi thing? i thought it's a u-boot thing
<oliv3r> ah i see it
<mrnuke> yeah, it was already defined, just not used
panda84kde has joined #linux-sunxi
<oliv3r> wait, so the original code was usec * (24 * 1000 * 1000) / 1000 / 1000?
<oliv3r> why?
<oliv3r> that's just silly
<oliv3r> there's better ways to round
<mrnuke> my favorite is the "repetitive hammer strike" :p
<oliv3r> mrnuke: i'm inclined to init the timer before gpio
<wens> it might even overflow
<oliv3r> wens: i think that was the reason for mrnukes patch; it could overflow :)
<oliv3r> wens: he did call himself the overflow police!
<wens> ah yes
<mrnuke> oliv3r: feel free to init it wherever you want (as long as it's before ram init)
<mrnuke> wens: it overflowed when I put a 10 second delay
<mrnuke> that's how I found there was a problem
<mrnuke> (yeah, printf, then delay, watching console with a stopwatch -- don't tell me you guyse _never_ did that)
n01 has quit [Ping timeout: 246 seconds]
<oliv3r> mrnuke: well watchdog_init is the m ost important I feel; so it resets the board in case of problems etc; then the clocks obvioulsy as nothing will work without the clocks. so gpio vs timer; timer is internal and more 'core' then gpio :)
<oliv3r> anyway, that's my take on it, but i'm often wrong
n01 has joined #linux-sunxi
<mrnuke> yeah, timer is pretty hard-"core". there no clock to ungate for the timer module
Quarx|2 has joined #linux-sunxi
<oliv3r> i'll swap it when i merge your patch
<mrnuke> it's a free world :)
<oliv3r> mrnuke: you did the sdelay -> udelay math?
<mrnuke> yeah
<mrnuke> i put a READ_TIMER(); sdelay(1000000000); READ_TIMER()
<mrnuke> 125 million ticks, plus 12 to 14
<oliv3r> yeah if we can get rid of sdelay all together, that's a good thing
Quarx has quit [Ping timeout: 246 seconds]
vector80 has quit [Read error: Connection reset by peer]
<oliv3r> so its off by 12-14 clock cycles? that's pretty acceptable :p
<oliv3r> i'm very happy that we don't depend on clock anymore
vector80 has joined #linux-sunxi
<oliv3r> cpu clock :p and have a reliable time source for it now
<oliv3r> i guess the only problem arrises when sdelay is < 0x50 and udelay(1) is actually 'too long' but I don't think anybody will loose any sleep over that
<mrnuke> I think the 12-14 ticks has to do with branching to sdelay, and a few missed branch predictions
<mrnuke> you know, the clock at that point is 384 MHz (coiincidence?)
<oliv3r> i know too little about dram controllers etc, to know wether the dram init is really time dependant, or related to the mbus/cpu-speed
<oliv3r> mrnuke: what do you mean? the CPU clock is 384 MHz?
jt6562 has quit [Ping timeout: 272 seconds]
<mrnuke> it's set up from PLL1 at 384 MHz before the PMU is initialized
bbrezillon has joined #linux-sunxi
<oliv3r> does u-boot init pll1 or the BROM?
<oliv3r> (I don't know the brom entirely by heart :p)
<oliv3r> but i assume that there's some default in there too?
<mrnuke> it's done in clock_init or s_init (uboot side)
<mrnuke> yeah, in clock_init_safe(). If my bitmath is right, that hardcoded value ends up being 384MHz
<oliv3r> ok cool
<oliv3r> i wonder as what the brom runs the CPU at
<oliv3r> i wouldn't be supprised if the BROM runs at 24 MHz
<mrnuke> my advice, forget about the BROM. assume it does nothing useful, and leaves no useful defaults
<oliv3r> oh absolutly
<oliv3r> but i'm documenting it for 2 reasons
<oliv3r> a) to learn asm and how it works
<oliv3r> b) freedom/privacy sakes
<oliv3r> it'll take 1 blob out of the equation
<oliv3r> also we know it's a GPL violating one
<oliv3r> Turl: are you busy?
<mrnuke> oh, definitely document it, just don't worry about it when writing hardware init code
<mrnuke> GPL violating? How did that happen?
<oliv3r> i think u-boot assumes that the chip is in 'prestine shape' e.g. 0.
<oliv3r> mrnuke: well the BROM is compiled C code turned ROM
<oliv3r> they used linux libs for certain tasks (linux/u-boot)
<Turl> oliv3r, sleepy and on phone :) sup
<oliv3r> memset/memcpy is blalantly copy/pasted
<mrnuke> it being ROM doesn't violate GPL v2
<oliv3r> Turl: i kinda got stuck in understanding what happens here: https://github.com/oliv3r/Allwinner-Info/blob/patch-1/BROM/ffff4000.s#L2325
<oliv3r> Turl: don't read it now, just don't forget about it :p
<mrnuke> so, no source for the BROM?
<oliv3r> Turl: they jump to this point from various times in the function
<oliv3r> Turl: how can they popo the stack several times (and why are they passing arguments via r0, that they overwrite anyway
<oliv3r> mrnuke: so if i steal the linux kerenl, compile it and store the binary in ROM it doesn't violate the GPL?
<oliv3r> but what if its EEPROM?
<Turl> restores callee-saves?
<Turl> it's the exit point I suppose
<oliv3r> ohh
<oliv3r> yeah i did see that it never exists
deasy has joined #linux-sunxi
<oliv3r> or i haven't found any return yet
<oliv3r> (return as in branch lr or anything)
<oliv3r> ohh wait
<mrnuke> oliv3r: That's tivoization. it's forbidden by GPLv3, but GPLv2 permits it (as long as the source code is available, that is)
<oliv3r> it pops the PC from the stack
<oliv3r> mrnuke: but if there's no source, then that's a GPL violation i mean
<mrnuke> well, then yeah, it is
<oliv3r> mrnuke: we have no BROM source, so it's a violation of the GPL was my understanding
<mrnuke> what really eats me up about the BROM, is that by trying to make it unbrickable, they introduced a huge security breach
<oliv3r> Turl: of course! ok i'll have to write that down or I forget ;)
<oliv3r> Turl: i haven't seen pop used to exit a function before; but makes sense i suppose :)
<oliv3r> Turl: thanks!! :)
<oliv3r> mrnuke: how so?
<oliv3r> i wish it WHERE upgradeable :)
<Turl> yw :) read about prologue and epilogue on asm
<Turl> pop on pc sounds like a jump i suppose :p
<oliv3r> (and still keep it 'safe'
<oliv3r> Turl: it does indeed, but i'm new to this, i never really done anything with asm :)
<oliv3r> i mean, they could have made the BROM eeprom, and allow it to be programmed like any flash chip (via special pins if needed)
<oliv3r> sure that requires special setups and the like, but BROM would never get updated anyway or hardly ever
<oliv3r> the BROM has some bugs and is kinda messy
<mrnuke> oliv3r: the thing is, even if you put hardcore crypto verification, and put the firmware in a write-protected SPI chip, I can still just plug in a micro-sd and bypass all that. As far as making it upgradeable, the chip would no lenger be unbrickable
<mrnuke> (it being the BROM)
<mrnuke> it could have gone the way of bootstrap pins. Then by shorting those pins, you select the boot source. Harder to bypass in hardware, especially if the shortcircuit is done right under the BGA
<oliv3r> mrnuke: well if you develop such a system, you simply don't connect mmc0 and mmc2 :p
<oliv3r> mrnuke: i think if you have such hardcore requirements, you simply don't connect these ports
<oliv3r> but yeah
<mrnuke> all I have to do is cut a trace off the firmware chip, and it boots into FEL
<mrnuke> still a huge security backdoor
<oliv3r> true
<oliv3r> well their lack of security, is amazing for us :p
<oliv3r> it gives us tons of flexibility :)
<mrnuke> ideally, if an attacker manages to sabotage the boot firmware, the system should just refuse to boot
<oliv3r> you mean by signing it :p
<oliv3r> but yeah
<mrnuke> sure, it's flexible, and unbrickable
<Turl> A31 does the pin thing
<Turl> check the wiki
<oliv3r> i wonder how the A23 does it
<oliv3r> libv extract the brom! :D
focus has quit [Remote host closed the connection]
focus has joined #linux-sunxi
<mrnuke> UARGH!! "go to fel mode if failed" Still a security problem. I short the MISO pin on the SPI chip, and get to FEL. not good
<oliv3r> but it makes it unbrickable!
<oliv3r> i guess for simple consumer devices that's more important
<oliv3r> though yeah, they should have made that behaviour completly optional via pins on the bottom of the package
<oliv3r> true, security through obscurity
<andoma> or efuses
<oliv3r> but then it's not unbrickable anymore
<oliv3r> hardware you can 'hide' in a box
<oliv3r> so as long as you can't access it, it is save, but still servicable
<oliv3r> if an attack has physical access, all bets are off anyway
<andoma> still, for some type of equipment you'd rather have bricked devices and send new to your customer than having a hackable device
<oliv3r> well of course
<oliv3r> i guess you can't have 1 design/chip to please all markets
<oliv3r> as it is always with security, it is either easy/user friendly, or secure
<oliv3r> these are inherently always at eachothers opposites
<andoma> yeah and i don't think AW have focused their engineering effort on the security stuff that much
<oliv3r> nah; but i think in the market they aim for, it's completly irrelevant
<andoma> exactly
<oliv3r> and unbrickability is much more important
<oliv3r> since this is all about end users, who want a device that works, and some service technician/OEM has to quickly and easily be able to revive the device again
<mrnuke> "<oliv3r> true, security through obscurity" ? Really. You complain about having no prior assembly experience, yet you managed to almost completely RE the BROM
<mrnuke> :P
<Turl> easy flashing by factory >*
<oliv3r> so yeah, if you want a10 for something moderate secure, fine, hide the hardware; if you want hardcore security, get something else :)
<oliv3r> mrnuke: not sure how the quote and your statement relate; but yeah, i never written a line of asm
bsdfox has quit [Ping timeout: 264 seconds]
<oliv3r> mrnuke: never read any really either, maybe 10 lines :p
<Turl> if your device is empty, it boots to fel
<oliv3r> mrnuke: but asm is easy, and I have turl :)
<oliv3r> also good point Turl, factory has to be able to flash it when it comes from the factory -> fel :)
<oliv3r> this chip is all about ease of OEM integration!
<oliv3r> *note to self, fosdem point
<mrnuke> oliv3r: most assembly I ever wrote was asm("nop"): A few times I even did the infamous asm("dmb") :p
<mrnuke> oliv3r: how about a "never go to FEL" pin ? hacker boards leave that alone, secure systems short it GND (or VCC)
<oliv3r> Turl: if ldr r0 'needs to make sure mov r1, r0 has happened (it alwas has hasn't it) then there's better ways no?
arete74_ has joined #linux-sunxi
<oliv3r> mrnuke: yeah but then you have the 'how will the OEM program the tablet'
arete74 has quit [Read error: Connection reset by peer]
<mrnuke> maybe they used the nop instead of a memory barrier?
<oliv3r> mrnuke: they don't pre-program the flash etc, they just asmble the devices, and write flash to it :)
<oliv3r> well obvioulsy this is a compiler 'optimization'
<oliv3r> does a nop even consume a cpu cycle?
<oliv3r> i would think so
rellla has joined #linux-sunxi
<HdkR> 1 CPU cycle per nop
<Turl> I believe registers are always coherent
<mrnuke> yeah, nop comsume a stage in the pipeline
<Turl> nop is probably sleeping or aligning
<oliv3r> this goes above my level of comprehension :p
<mrnuke> Turl: wait, aren't the periptherals on APB/AHB, so consistency might be an issue without a memory barrier?
bsdfox has joined #linux-sunxi
<Turl> the mem stuff is after the nop
<oliv3r> the only reason i can see, is that mov r0, #constant appearantly is 'faster' then mov r0, r1
<oliv3r> but i thought that mov was guaranteed to be 1 cycle on arm anyway
<wens> i must have done something wrong. clock rename patches over my wifi branch results in divide by 0
<oliv3r> but yeah taht's the diff, constant vs reg
<oliv3r> mrnuke: i can't test your patches! i didn't bring my cubie2
<mrnuke> it really seems that that NOP is meant as a stupid memory barrier. there's no alignment that it achieves
<HdkR> Not using EOR for clearing a reg, sad D:
<Turl> wens, compare debugfs summary
<oliv3r> HdkR: i think they used a very old compiler for this
<oliv3r> i see a lot of pointless memory copying
<oliv3r> (pointless because i don't understand the underlying problems :p)
<HdkR> hehe
futurisk has quit [Remote host closed the connection]
<Turl> 'nite :)
<oliv3r> Turl: sleep well
<oliv3r> see you in a few hours :p
<Turl> :p
<oliv3r> anybody with a cb2 awake?
<mrnuke> oliv3r: oh noooo. the world will never have known the coolness of my patch on Jan 3rd
<mrnuke> Turl: good night (UGT)
gzamboni_ has joined #linux-sunxi
<oliv3r> anybody with a cb2 awake?
<wens> oliv3r: sup?
<oliv3r> mrnuke: i shouldn't push this patch without some testing, as it may break things for some people
<oliv3r> can you see if that boots normally? :)
<Turl> what patch?
<oliv3r> Turl: your sleeping
<mrnuke> oliv3r: no problem. Testing is always good.
<Turl> :p
<oliv3r> Turl: mrnuke made dramc use udelay (and fixed the overflow with it) instead of sdelay
<mrnuke> see, my patches are so cool, they keep Turl awake
<Turl> oh cool :)
<Turl> haha
<oliv3r> see :D they are cool
<oliv3r> Turl: which in turn allows dramc to be initted more reliably (esp. at higher clock freqs)
<mrnuke> <- coreboot developer
<oliv3r> mrnuke <- u-boot hacker
<oliv3r> mrnuke: will you attend fosdem?
<Turl> yeah I saw your patches on gerrit
<HdkR> <- big idiot
<Turl> :)
<mrnuke> LOL
gzamboni has quit [Ping timeout: 264 seconds]
<HdkR> I wanted to join in too...
<oliv3r> Turl: coreboot gerrit or do we have gerrit and I don't know about it yet?
<wens> oliv3r: looks good :)
<Turl> coreboot
<mrnuke> oliv3r: no, I'm in Texas. not enough casheroo to make it
<oliv3r> HdkR: we all have our strengths :)
<oliv3r> mrnuke aww; I will bring some coreboot goodies to fosdem if the mailman is nice to me
<n01> yay for goodies
gzamboni_ has quit [Remote host closed the connection]
<mrnuke> ooh, goodies :D
<oliv3r> i realize i haven't uploaded the last version; but http://oliver.schinagl.nl/gallery/v/geek_stuff/dspif/
<oliv3r> it's a micro PCB, that allows you to switch between 2 SPI flash devices
<Turl> btw, will coreboot bring us any practical benefits over uboot?
<oliv3r> the idea herein is, you plug it into your board, have 1 smd flash device to play with, and have your original bios in the socket
<oliv3r> Turl: seabios etc
<Turl> seabios.. sounds familiar
<mrnuke> Turl: coreboot is supposed to only do hardware init, and launch what we call a "payload"
<Turl> so it's a SPL in uboot terms
<mrnuke> so that payload can be anything you want, a BIOS (SeaBIOS), UEFI (Tianocore), GRUB2, etc
<mrnuke> exactly
<mrnuke> I'm launching uboot from within coreboot
<mrnuke> so uboot is the payload, for example
<Turl> cool :)
<Turl> the more the merrier, at least until tjere's bugs :p
<Turl> h*
gzamboni has joined #linux-sunxi
<mrnuke> so you can even implement crypto verification of payload and later OS
<mrnuke> chromebooks do this, where coreboot resides on a write-protected part of the flash, and verifies anything from the unprotrcted part before launching it
<mrnuke> bugs are easy to fix. it's free software in the end
<Turl> yeah, but triage pain is bigger when only half the people see the bug :)
<Turl> some people here wanted barebox btw
<n01> i'd like to have barebox on cb
<oliv3r> Turl: sleep! sleep now so you can get up early! :)
<oliv3r> the only reason why i would be against these efforts, is spreading resources thinner; the obvious advantage is, bug squashing (e.g. patches as the dram timer one)
<mrnuke> once you coreboot, you never go back
* mrnuke hides
<oliv3r> heheh
<oliv3r> i want to get coreboot running on my systems for ages
<oliv3r> but a) they aren't fully supported yet
<oliv3r> b) can't afford the downtime in case of trouble (until i have my dspif modules ;)
<oliv3r> c) to much on my plate for the next century
<oliv3r> and one of the boards i'd love to have coreboot running on, my HP microserver N36L has a solderd SMD bios chip :S
<oliv3r> mnemoc: did you fix fastcgi? :D
<mrnuke> I mean, really not a problem: http://www.pomonaelectronics.com/images/large/6109.jpg
<oliv3r> i did see those
<oliv3r> i guess i could run a bus-pirate to fix that
<oliv3r> :)
<oliv3r> mrnuke: so you write coreboot for the N36L, N40L and N54L; and i'll flash it to my board :)
<oliv3r> the bios flash chip is really close to the front, so it IS accessable
<oliv3r> and i could flash coreboot; if it doesn't work; flash bios back
<oliv3r> mrnuke: http://www.coreboot.org/pipermail/coreboot/2011-May/065218.html it has been discussed int he past of course
<oliv3r> corebooot here would be awesome, default bios is slow :(
<mrnuke> send me a board
hansg has joined #linux-sunxi
<oliv3r> mrnuke: :p
<mrnuke> AMD stuff is not that hard
<oliv3r> mrnuke: i should buy myself an upgraded version and send you the old board :p
<oliv3r> mrnuke: oh this one should be relativily easy
<oliv3r> and those microservers ARE awesome
<hansg> oliv3r, hi, good morning
<oliv3r> hansg: Hey hans!
<hansg> oliv3r, I believe I have a solution for the ahci stuff.
<oliv3r> hansg: allready?
<hansg> Let me send you a mail with my latest patches.
<oliv3r> hansg: you are steamrolling patches!
<oliv3r> hansg: sure!
<hansg> oliv3r, sleep is for the weak :)
<oliv3r> heh; i find myself short on time to hack on things! :(
<hansg> To be honest no night work is involved. I had a bit of a backlog of PTO, so I took 2 weeks off.
<mrnuke> patches by mail? isn't github faster?
<oliv3r> mrnuke: github isn't a libre service! :p
<oliv3r> reviewing wise, i prefer e-mail too; though github does make it easy
<n01> and make a review on github is impossible
<mrnuke> gerrit? Really guys, the ML patches are hard to keep track of
<mrnuke> we used to do ML on coreboot up until a few years ago. Maan, was it a pain
<mnemoc> github is worse :p
<oliv3r> mrnuke: we don't get THAT many patches to be fair
<n01> oliv3r mnemoc something like trac?
<n01> it could be awesome
<mnemoc> trac only works well with svn
<oliv3r> i don't think we get that many patches to be honest
<n01> there is no git integration?
<mnemoc> yes, but stinks
<n01> hoo ok
<hansg> oliv3r, you've got mail. Let me know what you think of things, and also if you want me to send it upstream or want to do it yourself.
<mnemoc> oliv3r: what was the url for the needed things for mailman?
<mnemoc> oliv3r: thanks
<oliv3r> hansg: i'll look; but you are probably far smarter then me anyway :p
wingrime has joined #linux-sunxi
<oliv3r> hansg: ah you kinda went with the 'old' approach there then
<oliv3r> hansg: I wonder if he'll accept it, i think the ahci_platform.c integration will have to happen anyway, as more soc will 'join' we need a proper ahci_platform + libahci framework aynway
<oliv3r> hansg: i'd probably use sunxi_setbits and sunxi_clrbits or the sunxi_ahci_pre_start_engine() though
notmart has joined #linux-sunxi
gzamboni has quit [Ping timeout: 240 seconds]
rellla has quit [Read error: Connection timed out]
gzamboni has joined #linux-sunxi
rellla has joined #linux-sunxi
<mrnuke> BTW, where does the name "sun" in sunxi come from?
<oliv3r> mrnuke: china
<oliv3r> mrnuke: Allwinner's internal name for the a10 platform was 'sun4i'
<oliv3r> when A13 came, it was bumped to 'sun5i'
<hansg> oliv3r, have you seen the line numbers? A driver using some sort of generic ahci_platform is not going to be smaller then one doing things itself. All the core functionality is already taken care of by libahci, trying to abstract / generalize the glue is just not going to work well, a generalized glue core is just going to be quite large and ugly and will likely need to be extended for each new platform driver anyways
<oliv3r> so sunxi, making the 4, 5 variable X, made sense :)
<hansg> With the actual glue drivers staying aprox as big as they are without a glue core ...
<oliv3r> hansg: i think it will actually be bigger then 350 lines, probably around 1000 :) but i think it will allow any new platform driver to 'hook in' more easy
<oliv3r> hansg: but I'll gladly let you pick that fight with the maintainer :D
<hansg> As for using sunxi_clrsetbits good idea, making that change now
<mrnuke> oliv3r: ooh, so allwinner, named it "sun[number]i"
<hansg> oliv3r, ok, so shall I submit my version upstream then (once done testing) ?
<oliv3r> hansg: i think same for resume/suspend (clrbits) but only glanced there
<oliv3r> hansg: yes! Ack-by: Olliver Schinagl <oliver@schinagl.nl>
<oliv3r> mrnuke: yeah, ironically; the latest sdk, 2 years after we started to name it sunxi, they started to do sunxi-ing it too :)
<mrnuke> haha
<oliv3r> what's even more funny; some e-mails hans and I exchange, are in english
<mrnuke> BTW, is the linux SPI driver functiona;(or existent) I couldn't get a /dev/spi when I last booted
<oliv3r> while both of us are native dutch :)
<oliv3r> mrnuke: for mailine, mripard is working on it
<oliv3r> in 3.4 i'm not sure
<oliv3r> and i don't think we have it in u-boot
<n01> hansg where did you get the info for lradc?
<oliv3r> i did see some duplexing patches pop by the ML for 3.4; so it should work there
<hansg> oliv3r, yeah, I find that when talking computer stuff English is just more convenient, also I write so much English professionally I need to think harder to write Dutch then English :)
<mrnuke> I think I tried sunxi-devel, or sunxi-next
<oliv3r> hansg: i agree ;)
<oliv3r> mrnuke: that's mainline stuff; mripard is working on it, but i haven't seen any patcehs yet
<oliv3r> n01: what info?
<hansg> n01, data-sheet + android driver
<oliv3r> hansg: btw, i'm not sure i like your lradc patches :p
<hansg> oliv3r, can you explain ?
<n01> hansg: ok then I definitely missed something when writing my driver (that's why it didn't work)
<oliv3r> hansg: technically they are fine, but shouldn't we have a generic (lr)adc driver in the iio? framework, and then have a 'bridgin' thing that would work on any adc? (theoretically even on the TS)?
<mrnuke> oliv3r: so that would be on top of linux-next, right?
<hansg> oliv3r, have you read my latest reply to mripard about this ?
<oliv3r> (as the TS is just an adc too if configured as such)
<oliv3r> hansg: no, i'm still reading the ML
<oliv3r> i'm almost caught up though, stupid hollidays
<oliv3r> 310 unread mails left
<hansg> oliv3r, he was making the exact same argument, but the lradc is specifically designed for input purposes, it has button down and up interrupts, there is no way to map that through IIO
<oliv3r> hansg: so iio needs to be extended :p
<hansg> oliv3r, it also does things like debouncing the input. Same for the ts
<oliv3r> hansg: fiar nuff
<oliv3r> but still; special iio additions ;)
<oliv3r> but i admit, i wasn't aware of that
<hansg> No, just no. The whole lradc driver currently is 200 lines, n01's attempt at an IIO driver is bigger, without the glue + special additions + ...
diego has joined #linux-sunxi
<hansg> I always greatly prefer KISS when possible. Or to quite Linus: "Perfect is the enemy of good"
panda84kde has quit [Ping timeout: 240 seconds]
<oliv3r> hehe, I suppose if the need would really arrise, someone should just extend the IIO framework and maybe then we could consider it
<oliv3r> yeah very true
diego is now known as Guest17272
<oliv3r> perfectionism is not a positive thing!
<hansg> n01, any progress on doing a mfd driver for (one of) the axpXXX chips ?
<n01> hansg: I'm stuck on a nasty problem about irq managing
<n01> I'm still trying to figure it out
<oliv3r> hansg: with all this steamrolling; don't forget to update the wiki page :p
<hansg> oliv3r, erm, can I delegate that to someone? (ie you?)
<oliv3r> pfew, i'll try to gmane your e-mail + sunxi then and go from there
Guest17272 is now known as panda84kde
<oliv3r> hansg: lradc, ts, ahci, mmc?/
<hansg> oliv3r, yes those are all working. If you want to put names to them I did lradc + ts, you did AHCI, David Lanzendörfer did MMC
<oliv3r> i thought oyu did more!
<hansg> oliv3r, more in general see my "sunxi-devel branch updated" mails to the list where I try to give status reports of what is happening in the sunxi-devel branch
<oliv3r> it felt like i saw more patches
<oliv3r> ah yeah; good point
bob__ has joined #linux-sunxi
<hansg> I mainly take others work and merge it into sunxi-devel. Granted I did also do some of the mmc and ahci work :)
<oliv3r> hansg: and USB i think
<oliv3r> or i think you said you where gonna clean it up a bit?
<oliv3r> and add ohci?/
<hansg> EHCI is currently all arokux work, but yes EHCI works in sunxi-devel too
<wens> i'm thinking of re-doing usb
bsdfox has quit [Ping timeout: 246 seconds]
<wens> at least the clocks, resets, phy and ohci
<wens> but i need to get gmac out the door first :(
<hansg> arokux said he wanted to try and do it himself, but I've just got a go ahead from him to take a shot at doing it myself. So that is my plan for today after pushing out the new ahci patches
bob__ has quit [Client Quit]
<oliv3r> ok i'll put your name down on OHCI then
<mrnuke> wens: EHCI debug gadget driver. I'm counting on you, brother
<wens> OTG?
<hansg> wens, as said I plan to work on it today, so please coordinate to avoid doing double work. arokux has already solved the reset bits in the clk register in a cleaner way (but not pushed out the patches anywhere yet) so I'm going to keep using the hackish approach there for now. I plan to focus on writing a phy driver for the phy registers in usbc0 which are shared with usbc1 and usbc2
<oliv3r> wens: i thought you where hacking on the OTG driver using the invent...something driver?
<hansg> wens, I'm talking OHCI + EHCI here. Getting usbc0 / otg to work should be feasible to, we've patches in sunxi-3.4 to use musb instead of allwinners own code, those should be a good starting point
<oliv3r> inventra*
<wens> oliv3r: i started looking at it, but the shared part should be done in a phy driver
<mrnuke> wens: no idea what you have to do, but I'd love if this could work on the cubieboards: http://www.coreboot.org/EHCI_Gadget_Debug
<wens> hansg: I'll wait for your phy driver then
<hansg> wens, ok
<hansg> wens, note the otg bits of it likely will be incomplete but it should provide you with a starting point
bsdfox has joined #linux-sunxi
bsdfox has quit [Changing host]
bsdfox has joined #linux-sunxi
<wens> I'm looking at both sunxi-3.4 and A23 SDK
<oliv3r> what was the german guy called working on the Transport Stream driver?
<oliv3r> and who was working on the security system again?
<oliv3r> montjoie[home]: I think wasn't it?
<cajg> Has anyone tried the experimental/sunxi-3.10 kernel? Would it be madness?
<cajg> (I'd like to try lxc on the MK802)
<wens> oliv3r: Montjoie on security system
<oliv3r> cajg: yes, that will be madness
<cajg> ok, thanks oliv3r
<oliv3r> cajg: unless you need nothing besides nfs
<cajg> oliv3r in what sort of time frame do you think it will not be madness?
<oliv3r> woppr
<oliv3r> cajg: 12 months
hramrach has quit [Ping timeout: 240 seconds]
<oliv3r> woprr: Ah you where working on the transport stream driver where you not? :)
panda84kde is now known as diego__
<woprr> yes
<oliv3r> woprr: ah Hi! cool i'll write your name down then
<woprr> down where?
<oliv3r> on the wiki :)
hramrach has joined #linux-sunxi
<woprr> k, thx
<oliv3r> woprr: just so that everybody knows who's working on what etc
<oliv3r> woprr: weren't you designing your own tunerboard too?
<oliv3r> just so I know i'm not an idiot, the audio stuff somewhat works like the video stuff right?
<woprr> was busy with a homebrew DLP-link 3D shutter glasses system but I'll continue the TSC dvb-driver soon, the testing hardware is going to be ready soon, too
<oliv3r> we have an audio engine, and 4 possible outputs, ac97 -> analog out, i2s for digital out, hdmi for digital out and spdif, each can be clocked and used individually as output?
<wens> audio stuff?
<oliv3r> wens: very cool
<oliv3r> wens: well i know we have 3 sunxi audio drivers right now, do we not? sunxi-codec, i2s, spdif
<wens> i think you would count them as seperate sound cards
<woprr> the driver will pass the full ts to the userspace if the TSC allows it
<oliv3r> i thought sunxi-codec was basically ac97 stuff
panda84kde has joined #linux-sunxi
<wens> sunxi-codec is the onboard audio codec
<oliv3r> woprr: that should be cool; i take it the TS driver will require dma?
<wens> iirc there is no allwinner driver for ac97
<oliv3r> wens: yeah, i'm looking at the clock register list as to what devices we have, and the i2s, ac97 and spdif are 3 seperate clocks; + hdmi, though that may be i2s or spdif re-routed?
<oliv3r> wens: i think sunxi-codec is ac97?
<wens> not sure about hdmi
<oliv3r> wens: ah no, there's audio_codec_clk
<oliv3r> i should grep the ac97 clk register
<woprr> oliv3r, yes the TSC will not work without if the published manual is correct
<wens> the audio codec driver looks nice
<oliv3r> but i thought that the ac97 stuff, was to take the digital codec output and make it analog
diego__ has quit [Ping timeout: 240 seconds]
<montjoie[home]> oliv3r I work on the SS driver, I expect to release this month
<wens> but i can't wrap my head around alsa soc structure
<oliv3r> montjoie[home]: no rush; just documenting
<wens> oliv3r: that's right, but then you'd need another chip
<montjoie[home]> if someone can write that I will mainline after
<oliv3r> wens: maybe they integrated this into the SoC though
panda84kde has quit [Client Quit]
<oliv3r> e.g. sunxi-codec -> i2s; sunxi-codec -> spdif, sunxi-codec->ac97
<wens> oliv3r: my take is that, the builtin codec only takes 2 channels
<wens> ac97 can take 6
panda84kde has joined #linux-sunxi
<oliv3r> wens: maybe they violate the spec!
<wens> so if an OEM wants to do a STB, they might choose ac97 over the builtin one
<woprr> the V(B)E(?) has some nice 3D format processing features it seems, but that should be usable if the HDMI transmitter can drive >=100Hz... ?
<oliv3r> well isn't ac97 codec chips used on motherboard with only 1 headphone jack etfc
<woprr> ...only
<wens> oliv3r: depends on the codec
<oliv3r> woprr: i think the display engine can't do 100 Hz at high resolutions, not enough memory bandwith
<woprr> k
<oliv3r> woprr: we now advise people to run 50 Hz refresh rates if they want to drive Full HD panels @ 32 bit
<woprr> k
<oliv3r> wens: yeah i don't understand how all that fits together anyway :p
<woprr> ^^
<oliv3r> wens: i just guesstimated :p
<wens> oliv3r: i would say the audio codec is a complete soundcard
<wens> whereas the i2s, spdif, hdmi ones are only transports, i.e. no codec
<oliv3r> so what IS ac97? i thought it was a spec of some sort, and i know there's chips that do that, i just thought they take a digital input and make it analog
paulk-collins has joined #linux-sunxi
<oliv3r> wens: i probably should first learn what ac97 really is :)
<oliv3r> paulk-collins: you are attending fosdem right? are you going to the f-droid talk? as it mentions replicant in the notes
<oliv3r> wens: also isn't audio on hdmi multiplexed with the video data on the same lvds pins?
<paulk-collins> oliv3r, that depends on whether my talk is accepted or not
<paulk-collins> but most likely, I'll go
<wens> oliv3r: iirc AC97 just a transport standard, think maybe i2s + control lines
<paulk-collins> and yes, I'll be at the F-Droid talk as well as tours
<paulk-collins> yours*
<oliv3r> paulk-collins: the sunxi talk is at the same timeslot as the f-droid slot :(
<paulk-collins> ahhh
<oliv3r> complain at #fosdem!
<paulk-collins> lol yeah :)
<oliv3r> i am actually thinking of asking to reschedule that bit
<oliv3r> i think sunxi is atleast interesting for android users, and so is f-droid, those two talks kinda relate
<wens> oliv3r: see the hdmi block diagram, there's a fifo for audio data
<paulk-collins> oh that would be great, I'd love to attend both
<oliv3r> paulk-collins: me too
<wens> so much to do , so little time
<oliv3r> yeah :(
<oliv3r> i'm lucky I can do so much during $work hours
<mrnuke> oliv3r: boss is on vacation?
<oliv3r> mrnuke: no, lots of 'free' time :p
<wens> oliv3r: you can take a look at the AC97 section in A20 manual, the link frame format pretty much says what AC97 is about
<oliv3r> or time i get to use myself, as long as i sit at my desk and answer the phone
<oliv3r> wens: yeah i was looking at the wikipedia and there it says 'the ac97 codec is the analog component of the arch'
<wens> home time
<mrnuke> LOL
<oliv3r> wens: drive safely
ZetaNeta has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 245 seconds]
<oliv3r> i think someone started to look at the smartcard reader aswell
FunkyPenguin has joined #linux-sunxi
<hansg> n01, about the axp support, if you have some code you would like me to take a look at (does not need to be working) just push it somewhere and I can see if I can get it to work. For testing the interrupt the power button is a nice simple test case
<hansg> See the powerbutton support in my axp152 driver
<hansg> n01, ah that reminds me, I think I know what your problem might be. I've a hack to get the external interrupt used bu the axp to work somewhere, let me look it up.
<hansg> n01, are you testing with an A20 ?
<hansg> If so you need to poke an extra bit to get the ENMI irq used by the axp to work.
<n01> hansg: yep
<n01> hansg: extrabit?
<n01> in the tree you can find: an irqchip for managing NMI and system controller, the mfd driver and the misc-input driver to control the power button
<hansg> Note that patch is a gross hack, having an irqchip for the NMI sounds right, if you've that your probably already poking the bit ...
<n01> hansg: yes thank you, already done that.
<hansg> n01, I'm currently looking into usb stuff, may be a few days before I'm done with that. When I'm done I'll take a look at your code and see if I can get the power button to work.
<n01> the problem is that when you press the button the IRQ chain is called but when the irq thread is called it looks like the interrupts are disabled and my board hungs
<n01> hansg: thank you. I'll work on it this we also. I'll push everything on that branch
<hansg> n01, is your irq chip also clearing the nmi (first non define chunk of https://github.com/linux-sunxi/linux-sunxi/commit/39737aadf86dd273865168db9332ca65c5df805c) at the nmi irchip level, as well as inside the axp chip ?
<hansg> It sounds to me like your exiting your interrupt without clearing the interrupt source, and it keeps re-entering it
<hansg> n01, wrt working on it this weekend, if you find a fix before I get around to it please drop me a mail.
<n01> the nmi is cleared in the NMI irqchip. The problem is that you cannot clear the NMI pending register if you don't clear ahead the pending bits inside the axp
<n01> hansg: I'll do
<hansg> n01, right, you must first clear the bits in the axp, that should be done by the interrupt handler in the mfd
<hansg> Then on exit of the interrupt handler clear the NMI pending in the irqchip
<hansg> I assume it is possible to do something in the irqchip after calling the handler? (I've never written an irqchip driver myself)
<n01> uhm, actually the irq thread is called with IRQF_ONESHOT so the line should be cleared after the irq thread
<n01> my idea is that there is samething wrong in the interaction between my irqchip and GIC
<n01> btw, the problem is that I cannot clear the bits in axp because when I enter the irq thread for accessing axp, my interrupt are kind of disabled and I cannot get the i2c interrupts -> deadlock
<hansg> You are not doing irq_reg_writel(mask, gc->reg_base + ct->regs.ack); from handle_irq
hipboi has quit [Quit: Leaving]
<n01> afaik it is done in handle_level_irq or handle_edge_irq
<n01> that's why I specify chip.irq_ack
<hansg> Ah, I see, you're probably right
<oliv3r> mripard: A20 has a register that lists the Secure JTAG Password, how do you feel on adding that to the SID driver to display it aswell?
<oliv3r> mripard: actualyl, nvm; it's a write-only register, e.g. to SET the jtag passwword
<hansg> n01, Ok, so if you look at axp152.c in the sunxi-3.4 sources you'll see the trick to solve this there. Disable the irq in the irq handler, and call schedule_work to schedule a work function which can do i2c read / write transfers
<hansg> Then in the work function when you're done re-enable the irq, and make sure that the re-enable code in the irqchip first clears the irq before enabling it (which I believe you already do)
<hansg> Does that help ?
<hansg> (as in does that help you to continue working on this, I understand that you cannot actually try this in a few seconds_
<libv> oliv3r: i do not like the fact that the inet patches got squashed.
<libv> oliv3r: 3.4 has regressed in several ways
<libv> compared to 3.0
<libv> this is why we now need these script.bin changes
<oliv3r> does the previous version work with 3.0?
<n01> the work is already scheduled with irq_threaded_request() in the mfd driver when I call regmap_add_irq_chip(). Actually I don't know if the irq for NMI is disabled. Have to check on that
<oliv3r> i thought we stopped supporting 3.0 a while ago
hramrach has quit [Remote host closed the connection]
<libv> oliv3r: on my hyundai a7hd i now need the same change as well
<libv> oliv3r: i never needed it on the 3.0 kernel it was running previously
<n01> hansg: :) yeah, I'm planning a busy we ;)
<oliv3r> good poitn
hramrach has joined #linux-sunxi
<oliv3r> libv: i can re-push them splitted then
<libv> oliv3r: nah, leave it for now
<hansg> n01, AFAIK (not sure on this at all) threaded irq handlers cannot sleep just like regular irq handlers, iow you really need to use a worker to do the i2c transfers.
bsdfox has quit [Ping timeout: 246 seconds]
<libv> oliv3r: imho script.bin should be treated as something fixed, which you grab once and which never again needs to be changed (for the same functionality)
<oliv3r> libv: i guess that'll be impossible for 3.0 vs 3.4 cases though
<libv> sunxi-3.4 should be fixed to work just as well with the same script.bin
<oliv3r> i guess since we dropped 3.0 support ...
<n01> hansg: hooo, ok, I'll check that also. thank you for the pointer
<libv> oliv3r: we cannot go and fix up _all_ script,bins
<oliv3r> libv: i think you are right; but then we divert sunxi script.bin from allwinner script.bin
<libv> oliv3r: and then also tell new board submissions to fix up their script.bin
<libv> oliv3r: because that is what sunxi-3.4 requires right now
<oliv3r> libv: i still have the patches so can easily pusht hem splitted
<libv> oliv3r: we do not require it for development boards
<oliv3r> yeah
<libv> oliv3r: that's rather a non-issue
<oliv3r> but that's an interesting problem
<libv> oliv3r: the big issue is that we have broken script.bin compatibility with android
<oliv3r> there's 3.0 script.bin; lichee-3.3/3.4-script.bin and sunxi-3.4 script.bin
<libv> which puts us, like with the dt stuff, on the same level as other SoCs
<libv> only good for development boards
<oliv3r> i think the sunxi-3.4 changes are from lichee-3.3 changes
<libv> here is one part of the issue btw: https://github.com/linux-sunxi/linux-sunxi/issues/158
<libv> there were some changes to usb power management
<libv> the other issue is that 8192cu is no longer functioning as before
<libv> and 8188eu is not a worthy replacement as it does not power up/down the usb busses like 8192cu did
wolfy has joined #linux-sunxi
<libv> 8192cu no longer working on the same hw is a direct regression
<oliv3r> they didn't allwinner-fy the driver yet
<libv> oliv3r: again, unacceptable, as that now requires hacking script.bin
<libv> which explains why the 8188eu hacks are now badly spread all over our wiki
<oliv3r> i think this will be a mess you can't easily fix
<oliv3r> since when the first script.bin's where out, aw dind't think several things through
<libv> and why half the devices simply have no working wifi
<oliv3r> so one fix, breaks older stuff
<libv> it breaks a20
<oliv3r> that is indeed quite crap
<libv> "quite crap" == "totally unacceptable"
<oliv3r> we should check git history, if it was an Allwinner patch or a sunxi patch that caused the incompatibility
<oliv3r> but there are various sunxi-script.bin extentions iirc
<libv> the usb bus powering is partly explained here: https://github.com/linux-sunxi/linux-sunxi/issues/158
<libv> 8192cu regressing to no longer work under sunxi-3.4 was not properly dug out
<oliv3r> i only read the top and bottom; first they where trying to find out what caused the breakage; and the bottom it was noted that it wasn't being powerd, but i saw no real fix yet
<libv> people have just been using 8188eu
<oliv3r> ah ok
<libv> _and_ were then forced to hack their script.bin
FunkyPenguin has quit [Ping timeout: 264 seconds]
FunkyPenguin has joined #linux-sunxi
bsdfox has joined #linux-sunxi
focus has quit [Remote host closed the connection]
TheSeven has joined #linux-sunxi
netlynx has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 264 seconds]
<andhe> wens: If I've understood things correctly (which is not very likely), for uarts there's nothing that reserves the (gpio) pins and configures them (like direction).... only pin muxing is done in the pinctrl-sunxi driver based on devicetree information. See mmc (sunxi-mci) driver for an example of a driver which on top of the pin muxing request's the pins and sets their direction. Serial drivers on the other hand only seems
<wingrime> oliv3r: have we any docs about CAN?
<wens> andhe: there is a uart driver, which should reserve the pins
<wingrime> oliv3r: whats is it?
<oliv3r> wingrime: CAN bus, used in cars etc?
<oliv3r> wens: welcome home!
<wingrime> oliv3r: we have any docs for our CAN IP?
<oliv3r> wingrime: the doc you just linked! and yeah we've put it in dl.linux-sunxi.org/A20 i think
<oliv3r> lets not ask where he got it from
<andhe> wens: again, to my understanding: drivers/tty/serial/8250/8250_dw.c is the driver used and I can't spot it doing any gpio/pinctrl related stuff.... also grep gpio drivers/tty/serial/8250/* returns nothing. Also, uart pins are not listed as requested in /debug/gpio
<wingrime> mnemoc: ^^^
<wingrime> oliv3r: also, Audio Video Sync are simple timer , why you put it in "Hard" section?
<oliv3r> wingrime: mnemoc put the doc up allready
jinzo has joined #linux-sunxi
jinzo has joined #linux-sunxi
<libv> techn__ is responsible for the two changes which get blamed in https://github.com/linux-sunxi/linux-sunxi/issues/158
<libv> right?
<oliv3r> wingrime: yeah it's simple, probably should have been under a nother section :) but i kept going on all the VPU stuff, so it just followed
<oliv3r> techn__: is this true?
<andhe> wens: I'll try to dig more when I have more time... (need to run now, just wanted to share what I looked at yesterday)
FunkyPenguin has quit [Ping timeout: 240 seconds]
<wens> andhe: as i understand, pin reserving is done by the driver core
FunkyPenguin has joined #linux-sunxi
hansg has quit [Ping timeout: 264 seconds]
Seppoz has joined #linux-sunxi
<libv> hah...
<libv> not set on sun7i
<oliv3r> i think it was said a few times that sun7i_Defconfig was a bit messy/not well maintained
<libv> it is set on my a10 kernel, so that does not explain the regression there
Seppoz has quit [Ping timeout: 240 seconds]
<libv> this might magically give me working gadget support.
prasannapete has quit [Quit: prasannapete]
<libv> but it remains to be seen how this will influence a10
Seppoz has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 240 seconds]
FunkyPenguin has joined #linux-sunxi
<oliv3r> why hasn't Puneet B not been shot yet?
<oliv3r> looks like he refuses to read anything on the wiki
bsdfox has quit [Read error: Operation timed out]
<libv> new mail?
<oliv3r> possibly old
hansg has joined #linux-sunxi
<oliv3r> it was about flashing u-boot to his mmc
Seppoz has quit [Ping timeout: 240 seconds]
<libv> heh, on a10, 8188eu simply finds the device... this script.bin change is only needed for sun7i, due to bad sun7i defconfig
<libv> not that it is associating though...
<libv> so 8188eu is allwinnerised
<hansg> libv, those rtl wifi's have pretty poor reception, you likely need to get closer to your accesspoint
bsdfox has joined #linux-sunxi
<libv> hansg: any closer, and it'd be measured in centimeters :)
<libv> hansg: also, it worked fine on sunxi-3.0...
<libv> so this is not a hw issue
Seppoz has joined #linux-sunxi
<wens> broke my kernel again :(
<oliv3r> yay olimex!
ganbold_ has joined #linux-sunxi
<oliv3r> yes they where
HeHoPMaJIeH has quit [Quit: Leaving]
kaspter has joined #linux-sunxi
focus has joined #linux-sunxi
Seppoz has quit [Ping timeout: 240 seconds]
<oliv3r> mnemoc: sunxi-3.4: make life easier for rtl8188etv users.
<oliv3r> mnemoc: needs merging :)
Eyal_ has quit [Ping timeout: 252 seconds]
<mnemoc> oliv3r: please ack it on the ML and I'll merge it to stage once back at home
<oliv3r> doen
<libv> hold off a bit
<libv> sun7i_defconfig changes coming up
<libv> i needed to disable two drivers just to get it to build
<mnemoc> I won't be at home in at least 4h
<mnemoc> so you have time to send patches :p
<libv> also, the rtl8188etv fix should really be fasttracked
<libv> it is not a fundamental change that can break other bits
popolon has joined #linux-sunxi
<libv> and it's been around for many many months
<oliv3r> was too busy with puneet-B mails!
<oliv3r> OMG
<oliv3r> i switch back to my mail client, to finish my mails
<oliv3r> guess what mail is up; PUNEET B!
<oliv3r> i shit you not
hansg has quit [Remote host closed the connection]
<oliv3r> i should stop responding to puneet mails; i'm starting to become mean! :(
Eyal_ has joined #linux-sunxi
Eyal_ has quit [Ping timeout: 245 seconds]
<oliv3r> 'how big is the linux-sunxi community'
<oliv3r> mnemoc: do you ahve an estimate?!
<mnemoc> no idea... look at the subscribers list of the ML
<oliv3r> i can't see that
<oliv3r> hence, why i ask you!
<n01> oliv3r: I want also the ratio male/female
<oliv3r> n01: there's females on our list?
<oliv3r> mnemoc: i found it; thanks
<n01> dunno, maybe lurking :)
<mnemoc> doubtful
<oliv3r> heh, i joined rather late on the ML
<oliv3r> Giulietto Emme is a girl!
<oliv3r> or on the pic it looks like it
<n01> italian name
<oliv3r> i joined apr 24th on the gg ML
<oliv3r> it's caro's alter ego
<oliv3r> what ever happened to empat0
<mnemoc> oliv3r: there is an 'o' at the end. so it's male
<n01> OMG she is from my hometown
<oliv3r> 0, not o
<mnemoc> Giulietto
<oliv3r> n01 said its a she
<mnemoc> n01: go for it :p
<mnemoc> funny, a female in the list and just happens to live in the same town as n01
<mnemoc> maybe n01's alter ego?
<n01> mnemoc: nope, my hometown not the one i'm living now
<mnemoc> ow
<oliv3r> not ugly either
<mnemoc> n01: but you can bring a cubietruck next time you visit your parents and meet her ;-)
<oliv3r> maybe n01 has a fan
<n01> hahaha, still I'm scared she is not a "she"
<n01> name is definitely a male name
<mnemoc> birth mistakes :p
<oliv3r> i hate the word 'necessary'
<oliv3r> i never know how to spell ti
eyal has joined #linux-sunxi
<mnemoc> oliv3r: don't forget the french ecole which is using A20 boards for their operating systems class
<mnemoc> also impressive
<oliv3r> ah yes, worth a mention; i hadn't forgotten
<oliv3r> anyhow, to summarize, we have almost 600 mailing list memebers.
<mnemoc> including one female-looking member!
<n01> mnemoc: nope, he is a male. just checked
<mnemoc> :(
<n01> :(
<mnemoc> so forget about bringing your cubietruck when visiting your parents next time
<oliv3r> n01: so the pic is a lie?
<mnemoc> gf pic?
<oliv3r> no more cake for you
kaspter has quit [Ping timeout: 264 seconds]
<n01> oliv3r: yes :(
<mnemoc> damn keyboardco, a week and they still haven't shipped my filco majestouch ninja
<n01> mnemoc: I bought a poker 2 and an ergodox
<n01> poker 2 arrived yesterday, ergodox not shipped yet
<mnemoc> uh, that poker 2 thing is almost frameless
<oliv3r> mnemoc: i wonder if i would like a keypad-less keyboard
<n01> mnemoc: it's a 60%. really nice
<mnemoc> i have a full das keyboard at home, with clicky blue switches. for work I'm finally going to try keypad-less... but keeping the arrows
<mnemoc> also first time with brown switches.... or my coworkers will kill me
ZZambia has joined #linux-sunxi
<n01> I prefer clears, but browns are ok
<ZZambia> Hi there
<mnemoc> damn, another italian
<n01> :D
<ZZambia> :D
<n01> hi fellow italian
<ZZambia> hello you all
<ZZambia> guys, anybody got serious with the video encoder in the A10/13/20?
<ZZambia> i'm new to this plat, found only a few bits of info out there
<mnemoc> in the ML there is a huge thread about video encoding
<ZZambia> can you point me out plz
<mnemoc> oliv3r: http://www.overclock.net/t/538389/mechanical-keyboard-club-now-powered-by-koalas/3220#post_14148181 <---- wishing to replace my crapkeyboard from work with this one
<oliv3r> i want an atmel based keyboard :D
<oliv3r> so i can have opensource firmware for it
<n01> oliv3r: join the ergodox club ;)
<oliv3r> mnemoc: i know i googled it
<mnemoc> oliv3r: :)
<oliv3r> ergodox looks nice
<oliv3r> but can i hack the firmware!
* mnemoc hates keyboards not looking like keyboards
<oliv3r> it looks OSS
<oliv3r> well there's a BOM
<oliv3r> gerber files
<oliv3r> i think i want an ergodox
<n01> :D
<oliv3r> but the PCB is allready missing things
<oliv3r> RGB leds obviously
<oliv3r> only flaw i find, is that it has a Microchip in it :)
<ZZambia> mnemoc: thx a lot
<mnemoc> ZZambia: yw
<oliv3r> ah it's only an IO expander, it runs on a teensy
<libv> hrm, teensy is non-free iirc
<oliv3r> well that should be easily replaceable
<oliv3r> as teensy runs on an AVR
<oliv3r> teensy 2.0 was atmega32u4
<libv> yeah, still have two rotting in a drawer
<libv> since... ow... 3+ years :)
<oliv3r> well atmega works with avr-gcc
<Dreadlish> well, it should.
<oliv3r> and while the bitmask of the chip isn't opensource ... hardware? The code can be GPLv3+ if you wish it to be
<oliv3r> dunno if teensy is OSWH; but olimex covers that end
<libv> i think it was something with the bootrom iirc
<atsampson> yes, the Teensy bootloader's not open source
<oliv3r> you can write your own bootrom, and LUFA (the usb bootloader) is opensource and runs on it
<wens> reminds me of a custom keyboard talk I went to
_massi_ has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
<ZetaNeta> hi
<ZetaNeta> is there any "Olinuxino vs CubieTruck" page?
<oliv3r> opensource vs openschematic :)
<ZetaNeta> because i personally expected CT to cost around ~80 eur... before i came to shop page
<ZetaNeta> oliv3r, "As long as gentoo will get there, its not a problem"
<ZetaNeta> I am not into "recreating" it
<ZetaNeta> but opensource is a good thing
<ZetaNeta> But i am more worried about the features
<oliv3r> ah
<oliv3r> research it; document it :)
<ZetaNeta> oliv3r, Genius! That was my plan in case i wont find anything
<oliv3r> :p
<ZetaNeta> Does olinuxino support powering sata drives "off the board"?
ZZambia has left #linux-sunxi [#linux-sunxi]
<ZetaNeta> or it needs a special thingy for this, like cubie does?
<Wizzup> the cubie doesn't need anything special
<Wizzup> it just needs 2A
<Wizzup> works fine for my 2.5" HDD
<ZetaNeta> Wizzup, You realize that SATA got 2 plugs
<ZetaNeta> DATA, and POWER
<Wizzup> Yes, cubie has both.
<oliv3r> ZetaNeta: depends on your drive, a 5V only drive, no problem, 12V requires additional power (like the cubietruck)
<ZetaNeta> Wizzup, o.o
<Wizzup> ... wow :P
<Wizzup> What cubie do you have
<ZetaNeta> Wizzup, "None yet"
<oliv3r> cubie123
<Wizzup> I am talking A20s (and A10)
<oliv3r> and olimexino-a20
<oliv3r> all 4 i think can do 5V only sata drives without a problem
<Wizzup> depending on the W the take
<ZetaNeta> and the 12?
<Wizzup> but typically it works
<oliv3r> but if you get 3.5 drives, that need 12V (I don't think ssd's use it ever) yeah you need extra plug (on all 4)
<ZetaNeta> I heard that Olinuxino can take 6-16V... and it gives me some ideas
<ZetaNeta> oliv3r, Nonono, i am taking the laptop kind
<Wizzup> then it should be fine
bsdfox has quit [Ping timeout: 264 seconds]
<ZetaNeta> i like how olinuxino got its own "small ecosystem", when you can get all you need from 1 page
<ZetaNeta> while with cubie....
<WarheadsSE> well, the 12v and 5v busses are seperate, so that would be an interesting wiring harness
<oliv3r> ZetaNeta: there exist laptop drives that require 12V
<ZetaNeta> oliv3r, :P
<oliv3r> ZetaNeta: no joke
<oliv3r> ZetaNeta: we found that out the hard way, drive wouldn't work; because ... no 12V (2.5" drive)
<oliv3r> but you'd be lucky to find that
<ZetaNeta> s/l/unl
<Wizzup> Isn't it written on the drive :)
<oliv3r> but not on the 'buy now' page :p
<oliv3r> ZetaNeta: buying from olimex is GREAT to support them; and i strongly encourage it
<oliv3r> but you probably can get cheaper :)
<ZetaNeta> buying from olimex is cheaper
<oliv3r> really? wow
<ZetaNeta> atleast you pay for delivery only once
<oliv3r> can't say which brand it is, let alone the label
<ZetaNeta> while with cubie....
<oliv3r> nor if it does what you want
<ZetaNeta> i need something like a 128gb ssd
<ZetaNeta> than a 500gb hdd
<oliv3r> western digital has a 'hybrid' drive :)
<oliv3r> 2 drives, 1 plug
<ZetaNeta> because the thing is, that this setup will be in my backpack
<ZetaNeta> hooked up to a 65ah car battery
<ZetaNeta> (Yes, masochist, no more questions)
<ZetaNeta> I am going to make a ps3 joystick controlled mp3 player with camera
* ZetaNeta know how hard it is to reinvent something using ready details
bsdfox has joined #linux-sunxi
eyal has quit [Remote host closed the connection]
shineworld has joined #linux-sunxi
<ZetaNeta> anyone know if olimex sells camera modules of any kind?
ganbold_ has quit [Ping timeout: 264 seconds]
w00tc0d3 has joined #linux-sunxi
gzamboni has quit [Ping timeout: 246 seconds]
<ZetaNeta> lime sold out :(
eyal has joined #linux-sunxi
<mnemoc> that's good!
<mnemoc> go lime go
<jinzo> so that's ~50 right?
<jinzo> and the new run is 2k if I remember right?
<ZetaNeta> Anyone know cubie/olinuxino compatible camera?
<ZetaNeta> I need "very very HDish camera"
<ZetaNeta> to work with it
<mnemoc> didn't the first production batch go on sale already?
<ZetaNeta> i thinked of buying a GoPro or Sony AS15
gzamboni has joined #linux-sunxi
<ZetaNeta> But those are action cameras, having alot of feature i dont need
<ZetaNeta> And cant stream HD in realtime
<ZetaNeta> And even if they could, i would need to "Spend a month with wireshark"
<ZetaNeta> to actually find how to get the stream
jinzo has quit [Read error: Connection reset by peer]
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
vector80 has quit [Quit: Konversation terminated!]
<wolfy> ZetaNeta: I was very happy with Logitech HD WebCam C920 ( on cubie 2 )
<ZetaNeta> wolfy, Can it be used in portable?
<ZetaNeta> With all the shaking and etc?
<wolfy> ZetaNeta: I've also tested a microsoft lifecam hd 3000 but it had a very nasty autofocus feature and we ditched it
<ZetaNeta> And... i mean the "bigger than my HDTV" picture. Not the "webcamish HD"
shineworld has quit [Quit: Leaving]
<wolfy> both do autofocus.. otherwise no idea how they behave when shaked.
<ZetaNeta> wolfy, Thats the main thing
agath_at_work has joined #linux-sunxi
<wolfy> sorry. our use case involves camera fixed on top a 24" monitor :)
<ZetaNeta> I am going to attach one either on my shoulder, either in my jacket, in the "camera pocket"
<ZetaNeta> And walk around, recording for +12 hours
<wolfy> gopro all the way
<ZetaNeta> Thats why i been talking about 128gb ssd and a car battery
<ZetaNeta> gopro doesnt last that long
<ZetaNeta> and even if i am taking a action camera, it shall be Sony AS15
<ZetaNeta> its better
<ZetaNeta> I want Cubie/Olinuxino to manage the recording it down to ssd
<ZetaNeta> not the camera
<wolfy> I have colleagues who bought gopros and they are amazing. filmed while biking, bungee jumping, snorkeling ...
<wolfy> and by biking I mean mountain biking
<ZetaNeta> wolfy, Gopro: 6 hours in low quality, 64gb card, not considering the battery
<ZetaNeta> NOT GOOD
<agath_at_work> I hope I am not asking something already present in a FAQ (even if my searches didn't return any result yet). I'm running Arch Linux on a Cubieboard2 (Allwinner A20), and the watchdog does not work. I am trying to figure out how to update the kernel.
<ZetaNeta> My construction: +12 hours in "UBER DUPER HD", 128gb ssd, 65ah car battery
<agath_at_work> I read that 3.12 version should support the A20 natively. Is it possible to use it, or is there still something missing?
<ZetaNeta> agath_at_work, Change to gentoo
<agath_at_work> ZetaNeta: it would be an headache because I have already 50+ boards depolyed, however if it's the last chance I will think about it............. but .. why not trying to update Arch Linux?
<ZetaNeta> + mp3, ps3 joystick control, and a linux in the pocket
<ZetaNeta> agath_at_work, Its just my hate of arch. Dont listen to it
<agath_at_work> :-)
<ZetaNeta> Atleast dont treat that as only solution
<n01> agath_at_work: distro is unrelated to the kernel
<ZetaNeta> What kernel are you using? Is it from arch, or from linux-sunxi?
bbrezillon has quit [Quit: Ex-Chat]
<n01> he runs a linux-sunxi kernel
<ZetaNeta> i remember vanilla (or arch) kernels have support for Allwinners by them self
<ZetaNeta> but ours are better
<agath_at_work> Actually I am running 3.3.0 (linux-sunxi), but I tried also the 3.4 version... (unsuccessfully)
<ZetaNeta> if a kernel doesnt work, it means you didnt configure it properly. Believe me, i am a stubborn Gentoo user.
<WarheadsSE> agath_at_work: that an A20? which one?
* WarheadsSE read up
<agath_at_work> it's the Cubieboard2, with the A20
<mnemoc> 3.3.0 is lichee, not linux-sunxi
* WarheadsSE shrug, we can fix that, it was an early build to get it up.
<agath_at_work> core/linux-sun7i 3.3.0-6 [installed]
<agath_at_work> The Linux Kernel and modules - sun7i
<WarheadsSE> I know the CT users have been bundling, but since we never got one
<WarheadsSE> agath_at_work: thats out name .
<WarheadsSE> thats because that is the SoC name
<ZetaNeta> wolfy,
<ZetaNeta> You said you got this camera
<ZetaNeta> It seems to be VERY CHEAP, considering the camera i been looking at yesterday was 1599 eur
<wolfy> I have the logitech, yes
<ZetaNeta> Can you do a test of this camera in some hard conditions?
<wolfy> and tested with a friend's microsoft
<wolfy> no, I cannot test at all, it has been shipped to a remote office, out of the country
<eagles0513875> hey all
<ZetaNeta> Better, if on some linux. As in M$ they may have some special "Logitech drivers"
<ZetaNeta> :P
<WarheadsSE> also, why am I not surpised a Gentoo user is say to switch to it ;)
* WarheadsSE is a pot
<ZetaNeta> also, why i am not surprised why WarheadsSE knows no grammar
<ZetaNeta> s/i/I
<agath_at_work> religion wars :_)
<agath_at_work> :-)
<WarheadsSE> haha
<ZetaNeta> agath_at_work, I know this feeling.... holding shift...
<WarheadsSE> Oh, trust us, we would go off on certain distribution evangelists in a combined manner.
<ZetaNeta> Recently i had to move one of my servers to freebsd....
<ZetaNeta> #gentoo now knows how MUCH i love them all
<WarheadsSE> Gentoo and Arch are not too dissimilar, and I have a large number of associates in that distribution
<ZetaNeta> WarheadsSE, Gentoo, Arch and Slackware (and sometimes LFS) are considered in 1 group
<ZetaNeta> while they are like debian and opensuse
<ZetaNeta> but... i dare to say i dont see much difference between slack and LFS
* ZetaNeta got hit by a random patric
<WarheadsSE> Heh, yeah, I agree there.
ganbold_ has joined #linux-sunxi
<agath_at_work> I used slackware at the time with kernel 1.2.8 :-)
<WarheadsSE> Also know many of the core Slackware team
<WarheadsSE> good fellows to go drinking with.
<agath_at_work> at that time I was compiling kernels everyday... but after I switched to opensuse I didn't compile anymore until nowadays with the ARM stuff :-)
<netlynx> ZetaNeta, what hard camera tests are you looking for?
<WarheadsSE> So, whats the actual state of all hardware support in mainline then ZetaNeta, not just the watchdog.
<ZetaNeta> netlynx, Attaching it to a human, and letting him go round in both "AHSUNBURNMYJACKET" and "Where is the ground!?!" brightness enviroments
<WarheadsSE> And what of script.bin vs dts?
<ZetaNeta> agath_at_work, I compiled X on a armv5 board
<WarheadsSE> (Because, yes, I am aware that the sun7i kernel package needs a bump, but I can't spend time on research at the moment.)
<ZetaNeta> + Half the system
<ZetaNeta> it wasnt so long like most of you think
<WarheadsSE> meaning a ARM926EJS+
<mnemoc> does the mele with a31 come with uart pins?
<libv> mnemoc: do you have a handle on where this 8192cu driver comes from? do you perchance know which realtek release it originally was?
<ZetaNeta> netlynx, I need to record my way "there" under the sun of Cyprus, which will first burn you umbrella, then you. (At least in summer)
<ZetaNeta> And my way back, in complete darkness, with alot of "far away dots" lights
<mnemoc> libv: don't remember, but the only special change there is the activation/deactivation of the usbc power on load/unload
FR^2 has quit [Quit: Connection reset by peer]
pwhalen has quit [Quit: Leaving]
<libv> ah, this is what i had assumed...
<libv> in the meantime, i have gotten 8192cu to work on a7hd
<libv> this was a wpa_manager vs network manager thing
sspiff has quit [Quit: Konversation terminated!]
<netlynx> ZetaNeta, Can't test those high brightness environments for you. Only low/normal brightness (Logitech C930).
<libv> this usbc enabling code seems to also be present in 8188eu, but it apparently does not seem to have the same effect, i will dig into this deeper
<ZetaNeta> Well, dont you have a desk p
<ZetaNeta> lamp
<netlynx> ZetaNeta, would that be a close enough imitation for you?
<ZetaNeta> some bright lamp in the left top corner, not constantly visible
<libv> hah.
<ZetaNeta> But, main thing i am worried is shaking
<ZetaNeta> Sun could be "fixed" with filters, both hardware and software
<ZetaNeta> But shaking... only software, and only affecting the quality
<ZetaNeta> and not always
<libv> yet that code is still run...
<ZetaNeta> So just try the different types of shaking
<ZetaNeta> thats the "main"
<ZetaNeta> Also, would be cool if you will turn off the light. (If doing tests indoor)
<w00tc0d3> good choice?
<ZetaNeta> w00tc0d3, I am reading the "3 lines privacy policy"
<ZetaNeta> and start remembering one of my old ideas
<ZetaNeta> to write a ToS and Privacy Policy, getting me a stable source of slaves
pwhalen has joined #linux-sunxi
<libv> ok, seems i was totally off.
<libv> 8188eu works, a7hd does have usb_wifi_usbc_num
<libv> but it doesn't explicitely force the usbc2
<libv> the latter is not needed on sun4i due to the usb code being properly initialized
<libv> with that enabled on sun7i, 8188eu works just like 8192cu
<libv> which is relatively happy (just complains, and might break on subsequent ifup/downs) when networkmanager is properly disabled.
<w00tc0d3> libv: you were the Mali hacker, right?
<libv> w00tc0d3: last i checked, i still am, supposed to be, that is
<libv> w00tc0d3: why?
<w00tc0d3> libv: notrhing in particular, was testing my ind
<w00tc0d3> mind*
<wigyori> hmm, question on sunxi-mci - on 3.12, if the card(s) are removed after the driver is brought up and recognizes the card, should it rediscover if a card is inserted?
n01 has quit [Ping timeout: 264 seconds]
panda84kde has quit [Quit: Konversation terminated!]
Quarx|2 has quit []
maz_ has joined #linux-sunxi
printallthething has joined #linux-sunxi
LoCoZeNoz_ZUE has joined #linux-sunxi
ZetaNeta has quit [Read error: Connection reset by peer]
_massi_ has quit [Quit: Leaving]
maz_ has quit [Ping timeout: 252 seconds]
LoCoZeNoz_ZUE is now known as ZetaNeta
n01 has joined #linux-sunxi
<ZetaNeta> does any board got a hdmi capturing ability?
brain_ has quit [Quit: Leaving]
<bsdfox> sunxi android question- is there a way to install a better shell through adb? I've got a working A10 tablet with a broken FPC cable for the screen.. I want to use it for something but the existing root shell is pretty shitty. I haven't been able to find a uart on it (or at least not an active one with the boot console) so I don't like my chances of getting linux on it
<bsdfox> root@android:/system # echo $SHELL
<bsdfox> echo $SHELL
<bsdfox> . /system/bin/sh
<RzR> hi w00tc0d3 an other meego hacker's place :)
<RzR> so is captainigloo
<libv> RzR: there are several former nokians in here as well, ssvb and myself for instance.
<RzR> cool
<RzR> so you're all running mer ? :)
wolfy has quit [Ping timeout: 252 seconds]
<libv> nope, i am using a bogstandard ubuntu, so i can concentrate on the graphics hw
netlynx has quit [Quit: Leaving]
ssvb has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
flextron has joined #linux-sunxi
<flextron> hi!
rz2k has joined #linux-sunxi
<techn__> libv: that bug is for hackberry which is special case
<techn__> it has usb1 and usb2 ports which take power from usb0
<techn__> i'm not sure if anyone has got a20 otg port working
RzR has quit [Read error: Connection reset by peer]
RzR has joined #linux-sunxi
NightShade has joined #linux-sunxi
<libv> techn__: i have ordered some usb micro plugs so i can solder something to the id pin
<libv> techn__: because first things first, i need to know whether the gpio attached to it really is the one it says in the script.bin
<libv> but yeah, it does seem to need some work
<libv> ah, i still need to get the fix to sun7i_defconfig out
Black_Horseman has quit [Remote host closed the connection]
flextron has quit [Ping timeout: 272 seconds]
stoupaxyz has joined #linux-sunxi
<captainigloo> RzR: hey
<oliv3r> ZetaNeta: i know what you are trying to build :) you should have used that CSI camera link i sent you :) probably easiest
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
<ZetaNeta> oliv3r, Can yea send the link again?
<oliv3r> ZetaNeta: also, there's backpacks with solar panels; which should help you recharge your batteries, even if you only recharge 20% during the day, that's 20% extra
<ZetaNeta> oliv3r, battery is no longer a problem
<ZetaNeta> I am carrying a 65ah battery
<ZetaNeta> That should be enough for few days even if il forget to charge it
wingrime has quit [Ping timeout: 246 seconds]
<oliv3r> wigyori: i don't think we have an mmc driver on 3.12; so after it boots from the mmc, you can't use it
ZetaNeta has quit [Ping timeout: 260 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<n01> uhuhuhu solved the irq problem
diego71 has quit [Ping timeout: 272 seconds]
diego71 has joined #linux-sunxi
<w00tc0d3> RzR: Well, you overrate me if you call me a hacker :P I'm just a 14 y/o boy, on grammar school, who is trying to learn to code
<oliv3r> if your coding, your hacking!
<oliv3r> don't confuse hacking with cracking
<mrnuke> I think I might have tricked one of our coreboot fellows into getting a cubietruck
<oliv3r> libv: sounds like the wits evaluation board
<oliv3r> i know 2 of our community members who have one
<libv> the fact that this page is just a .fex file is what triggered me :)
<oliv3r> ohh
<oliv3r> drachensun did that when he got it initially
<oliv3r> as a quick n dirty
notmart has quit [Quit: notmart terminated!]
<WarheadsSE> oliv3r: I need to find a replacement for my old ThinkGeek Hacker Element [Hk] t-shirt
<wigyori> oliv3r: that's the sunxi-mci in linux-sunxi/sunxi-devel, that showed up in hans's tree earlier
<wigyori> i'm using that on 3.12 - owrt trunk uses that version yet
<w00tc0d3> oliv3r: I do not ;P but I'm not a very good coder
<w00tc0d3> libv: what's the name of your project?
<libv> w00tc0d3: http://limadriver.org/
<w00tc0d3> libv: thx
<w00tc0d3> libv: do you have good progress?
<libv> no, i am currently busy with sunxi stuff
ZetaNeta has joined #linux-sunxi
<w00tc0d3> oh ok
<ZetaNeta> oliv3r, I been offline, but i guess you wanted to say something
stoupaxyz has quit [Quit: User disconnected]
<libv> grmbl...
<libv> it's useless to search for fex terms on mediawiki
<libv> the underscores are turned into spaces, and it seems to ignore double quotes
ZetaNeta has quit [Ping timeout: 260 seconds]
n01 has quit [Ping timeout: 245 seconds]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
n01 has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
ZetaNeta has quit [Ping timeout: 255 seconds]
NightShade has quit [Ping timeout: 272 seconds]
FR^2 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 252 seconds]
FR^2 has quit [Quit: und weg...]
n01 has quit [Ping timeout: 260 seconds]