Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
pekka301 has joined #linux-sunxi
pekka30 has quit [Ping timeout: 245 seconds]
flyhorse_vjiqG has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
Akagi201 has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
physis has quit [Remote host closed the connection]
physis has joined #linux-sunxi
physis has quit [Ping timeout: 276 seconds]
ninolein has joined #linux-sunxi
ninolein_ has quit [Ping timeout: 272 seconds]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
naobsd has joined #linux-sunxi
hero100 has joined #linux-sunxi
physis has joined #linux-sunxi
kaspter has joined #linux-sunxi
physis has quit [Ping timeout: 240 seconds]
lerc has quit [Ping timeout: 244 seconds]
naobsd has quit [Quit: naobsd]
hero100 has quit [Ping timeout: 256 seconds]
flyhorse has joined #linux-sunxi
flyhorse_vjiqG has quit [Read error: Connection reset by peer]
hero100 has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 272 seconds]
p1u3sch1 has joined #linux-sunxi
flyhorse_kpcTe has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
flyhorse has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
flyhorse has joined #linux-sunxi
flyhorse_kpcTe has quit [Ping timeout: 272 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #linux-sunxi
hero100 has quit [Ping timeout: 245 seconds]
hero100 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 256 seconds]
flyhorse_ePnOk has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
prz has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
gzamboni has joined #linux-sunxi
<wens> mripard: i assume you're leaving the simple gate stuff to 4.3?
hero100 has quit [Ping timeout: 244 seconds]
hero100 has joined #linux-sunxi
<mripard> wens: yes
<mripard> it's a bit too late for 4.2 anyway :)
prz has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
prz has joined #linux-sunxi
<wens> i understand, just wondering if there were any pending issues
domidumont has joined #linux-sunxi
domidumont has quit [Client Quit]
domidumont has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
domidumont has quit [Client Quit]
flyhorse_ePnOk has quit [Ping timeout: 250 seconds]
domidumont has joined #linux-sunxi
flyhorse has joined #linux-sunxi
<rellla> monday morning, and this is sth, that i talked about last week http://www.cubieforums.com/index.php/topic,3758.msg23658.html#msg23658
<rellla> \o/ wtf ...
physis has joined #linux-sunxi
hero100 has quit [Ping timeout: 244 seconds]
physis has quit [Ping timeout: 272 seconds]
hero100 has joined #linux-sunxi
flyhorse_zvBiL has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
avph has joined #linux-sunxi
Wizzup_ is now known as Wizzup
Wizzup is now known as Guest56733
ricardocrudo has joined #linux-sunxi
Guest56733 is now known as Wizzup_
Wizzup_ is now known as Wizzup
<bbrezillon> RSpliet: Hi! Around ?
<RSpliet> bbrezillon: yep
<mripard> wens: no, just that I haven't submitted it yet
<wens> mripard: :)
<mripard> (and I need to test it on an A80)
enrico_ has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
sehraf has joined #linux-sunxi
<bbrezillon> RSpliet: is the bootrom really trying to load an SPL from the boot0-rescue part ?
<RSpliet> bbrezillon: yep
<bbrezillon> or is this partition just used by the SPL to find a valid u-boot ?
<RSpliet> no, brom actually loads from boot0-rescue when boot0 is damaged
<RSpliet> or what it actually tries, is various offsets
<RSpliet> boot0-rescue I think is the last offset it tries
<bbrezillon> RSpliet: so this patch is wrong, isn't it ? => https://patchwork.ozlabs.org/patch/466152/
<RSpliet> I think the correct patch is simpler: make it try different offsets too
<RSpliet> which is required anyway, because 0 simply isn't always the right one
<bbrezillon> it assumes u-boot (not the SPL) is directly stored at the beginning of the second block
<bbrezillon> RSpliet: do you have these offset values documented somewhere ?
<RSpliet> I don't... nor can I as I don't have edit rights on the linux-sunxi wiki
<RSpliet> (truth be told, I found that an uninteresting detail for the first bit of implementation, so I took it for granted
<RSpliet> has a tiny bit of info
<RSpliet> interestingly this mechanism, if it works in the way described there, will only work if the page size is 8KiB
<RSpliet> maybe 4KiB... but with a page size of 1KiB the boot partition would have to be smaller than u-boot-sunxi-with-spl
<bbrezillon> RSpliet: I guess they are assuming the NAND to have at least 64 pages per blocks
<bbrezillon> the page size shouldn't be a problem
<bbrezillon> RSpliet: the other thing I'm wondering is whether we should put the SPL and u-boot binaries in the same block
<RSpliet> bbrezillon: I don't see why not
<bbrezillon> because this implies using a pretty poor random seed table
<bbrezillon> which means you might be more prone to bitflips
<RSpliet> well sure, but is that a problem for a blob that is generally used read-only
<RSpliet> ?
<RSpliet> I read your part on how bit reads could trigger bit flips in adjacent cells
<bbrezillon> actually the problem is not when you read it, but you might flash a u-boot image which might contain too many bitflips from the beginning
<RSpliet> but... let's put it differently, I don't see how randomisation would change that. ECC might, but the ECC settings required by BROM are pretty strong
kaspter has quit [Remote host closed the connection]
cajg has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<bbrezillon> for the SPL, you're only writing a limited number of pages, and thus potentially limit the 'repeatable pattern issue', but the u-boot image is a lot bigger, which means it may potentially be less robust to this issue
<bbrezillon> RSpliet: but let's put this problem aside for now
<mripard> next issue, where do we store the environment ? :)
<bbrezillon> mripard: they should definitely be in a different partition
<bbrezillon> otherwise you won't be able to update the environment without risking to corrupt the u-boot/SPL image
naobsd has joined #linux-sunxi
kaspter has joined #linux-sunxi
<RSpliet> bbrezillon: I agree btw that using page mode would be a great next step... but I think we implement that better in a follow-up patch
<RSpliet> it's simple and understood, SPL does it too... but it might require some shoving and shifting of driver logic
<bbrezillon> RSpliet: BTW, have you tried replacing all the memcpy_toio/fromio ?
<RSpliet> with memcpy?
<bbrezillon> yep
awe00 has joined #linux-sunxi
ddc has joined #linux-sunxi
<RSpliet> I was looking into it
<bbrezillon> RSpliet: well, for the page mode, we'll still have to check a few things before using it, like is it really working for all the NAND chips (actually for all the page sizes), and if it's not we'll have to fallback to the standard mode
<RSpliet> bbrezillon: I think the Page mode is actually the ECC block mode
<RSpliet> and it should work for ECC step sizes of 512B and 1KB
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
hero100 has quit [Ping timeout: 255 seconds]
<libv> rellla: i am not sure whether this stephan guy knows what a "freelancer" costs
ddc has quit [Quit: Page closed]
<bbrezillon> RSpliet: yes, but I was more talking about the page size, the thing you configure in the NFC_PAGE_SIZE field
<mripard> libv: but he'll give you $100 !
<mripard> :)
<bbrezillon> apparently the controller supports pages which goes from 1KB to 16KB, so we shouldn't bother about that right now
<bbrezillon> (I don't know any NAND chip with 32KB pages)
GPenguin has quit [Ping timeout: 256 seconds]
<RSpliet> not sure if they exist... page size tends to grow proportionally with the NAND size, and at some point you're better off deciding to just stick more chips on there and distribute your data over them
hero100 has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
GPenguin has joined #linux-sunxi
<bbrezillon> RSpliet: this still leaves the old NAND chips with page < 512 bytes, but I'm not sure it makes sense to support them anyway
<wens> mripard: where do you think i should put the rsb stuff? drivers/rsb or drivers/soc/sunxi/rsb?
<RSpliet> bbrezillon: I don't think anybody found a use-case for combining legacy NAND with Allwinner
<RSpliet> cheap tablet builders can get better value for money, hard real-time systems folks are afraid of Allwinner
<mripard> wens: I guess it depends on what your code look like
<wens> i guess it can be generic enough to put under drivers/, but i doubt we'll see it in other vendors
<wens> i don't know what's the criteria for putting stuff under drivers/soc/ though
<mripard> yeah, but I mean, if it's a simple regmap, then you don't need anything else
hero100 has quit [Ping timeout: 250 seconds]
<wens> i guess moving them around is easy enough. i'll start with drivers/ then
flyhorse has joined #linux-sunxi
flyhorse_zvBiL has quit [Read error: Connection reset by peer]
hero100 has joined #linux-sunxi
flyhorse_VgYBe has joined #linux-sunxi
flyhorse has quit [Read error: Connection reset by peer]
paulk-aldrin has joined #linux-sunxi
<libv> mripard: :)
alexvf has joined #linux-sunxi
hansg has joined #linux-sunxi
cajg has quit [Quit: WeeChat 1.2]
cajg has joined #linux-sunxi
joost_dtn has joined #linux-sunxi
<RSpliet> bbrezillon: changing memcpy_fromio to memcpy doesn't make any difference in boot-time
<RSpliet> so for me the morale of the story is as I assumed.
<RSpliet> device IO is relatively expensive, and it pays off having a minion to do it for you :-)
gianMOD has joined #linux-sunxi
Akagi201 has quit [Remote host closed the connection]
flyhorse has joined #linux-sunxi
flyhorse_VgYBe has quit [Read error: Connection reset by peer]
<RSpliet> bbrezillon: right, okay... I'm going to get back on that conclusion
<RSpliet> yes, PIO is faster if we use memcpy instead of memcpy_fromio
<RSpliet> and even faster than DMA
<RSpliet> by another 4-5s
<RSpliet> (measured in boot-time only... it's hardly a benchmark, but it's what I care about most atm
<RSpliet> )
<wens> quick grep only shows some #defines for memcpy_fromio, which is just memcpy with a cast
<wens> am i missing something?
dlan has quit [Ping timeout: 265 seconds]
dlan has joined #linux-sunxi
awe00 has quit [Ping timeout: 240 seconds]
<RSpliet> wens:
<RSpliet> #define readb(c) ({ u8 __v = readb_relaxed(c); __iormb(); __v; })
premoboss has quit [Ping timeout: 246 seconds]
ganbold_ has quit [Ping timeout: 255 seconds]
ganbold_ has joined #linux-sunxi
prz has quit [Ping timeout: 264 seconds]
BroderTuck has joined #linux-sunxi
hero100 has quit [Quit: Leaving]
dlan has quit [Ping timeout: 250 seconds]
dlan has joined #linux-sunxi
prz has joined #linux-sunxi
paulk-aldrin has quit [Remote host closed the connection]
<bbrezillon> RSpliet: hehe, what did you do wrong in your first attempt ?
<RSpliet> wrong DTS files, resuling in wrong clock freqs used
<bbrezillon> ok, these results seems more sensible than the previous ones
<bbrezillon> do you mind sending a patch replacing all memcpy_toio/fromio by regular memcpys ?
<bbrezillon> RSpliet: ^
<RSpliet> I don't mind, but I can't judge whether it's actually correct
<RSpliet> it just... works
<RSpliet> and in practice I also know platform-independence doesn't matter, but... I can't verify this :-)
ptitnuage has joined #linux-sunxi
<ptitnuage> hello everybody
<ptitnuage> i would like to ask if someone know about sunxi support on A23 tablets: I saw some month ago a post of someone who post a link to a working uboot with DRAM init and SPL in hos git repo, but i don't know if this permit to boot a kernel...
<bbrezillon> yep, but that's for arm64
<bbrezillon> though this should be easily ported to ARM
<bbrezillon> anyway, modifying this kind of thing might introduce other bugs in other ARM platforms :-/
<RSpliet> that's why you need a good reviewer for these sorts of patches :-P
<bbrezillon> RSpliet: moving from memcpy_toio/fromio in the sunxi NAND driver is safe
<bbrezillon> sorry, should be safe
<bbrezillon> if if you really want to be sure, you can add a call to rmb() after the memcpy reading data from the SRAM and a call to wmb() after writing data to the SRAM
<ptitnuage> i would like to ask if someone know about sunxi support on A23 tablets: I saw some month ago a post of someone who post a link to a working uboot with DRAM init and SPL in hos git repo, but i don't know if this permit to boot a kernel...
<NiteHawk> ptitnuage: "u-boot-sunxi has basic support for A23, which includes UART console (including R_UART) and MMC. Disclaimer: no one has actually booted a kernel with this yet."
<NiteHawk> ptitnuage: http://linux-sunxi.org/A23#Software more or less sums it all up
iamfrankenstein has joined #linux-sunxi
flyhorse_XesYt has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
flyhorse has quit [Ping timeout: 264 seconds]
nove has joined #linux-sunxi
GPenguin has quit [Quit: Leaving]
Akagi201 has joined #linux-sunxi
<nove> rellla: ping?
Akagi201_ has joined #linux-sunxi
ptitnuage has quit [Read error: Connection reset by peer]
<libv> freelancers are worth a full 5usd per hour!
<libv> i hope they don't tell my customer
Akagi201 has quit [Ping timeout: 272 seconds]
<RSpliet> heh, it's called *free*lancer right? as in beer...
premoboss has joined #linux-sunxi
<libv> that's 880eur a month, for a full time job
<libv> i am not sure that this guy in the cubieboard forums has added things up yet, or has ever worked in his life
premoboss has quit [Ping timeout: 244 seconds]
<rellla> libv: that why i love this $RANDOM_DEVICE_forum so much. but it has to be an indian freelancer. *lol*
<rellla> *that's
<libv> rellla: yes, we really should count ourselves lucky that these $shit_pi_producing_companies work like that
<plaes> link?
flyhorse has joined #linux-sunxi
flyhorse_XesYt has quit [Read error: Connection reset by peer]
ptitnuage has joined #linux-sunxi
naobsd has joined #linux-sunxi
<libv> plaes: yup :)
<BroderTuck> What's holding up a v3 of the H3 patchset?
premoboss has joined #linux-sunxi
flyhorse_kpblY has joined #linux-sunxi
jinzo has joined #linux-sunxi
<WarheadsSE> libv / plaes : but but, exploit the developers who ....
flyhorse has quit [Read error: Connection reset by peer]
avph has quit [Read error: Connection reset by peer]
marcin_ has quit [Ping timeout: 264 seconds]
<ptitnuage> niteHawk: thanks, i already read the A23 page, but as someone released a working uboot for A23, i wondered if anything changed...
<ptitnuage> niteHawk: the A23 page seem outdated, since someone got dram working and the page still saying it's not working...
prz has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<nove> rellla: i finally looked at what you had asked me two times already, but it appears that the maf hardware block doesn't exist in sun5i, i am only getting zeros from the supposed registers
<RSpliet> nove: it's clock is not gated in the CCU registers?
<rellla> have you any sun4i/sun7i re-setup?
<wens> crap... seems my email forwarder can't get mail from allwinner folks :(
<rellla> but i don't know what is triggered by that.
<nove> RSpliet: the other near registers are very alive, expect in the 0x030 - 0x04c range (maf registers)
p1u3sch1 has quit [Ping timeout: 250 seconds]
<nove> rellla: i am tried by writing ~0 to the register to see if some bits get set, but only zeros
p1u3sch1 has joined #linux-sunxi
<nove> rellla: if you can test, i can give you some thing for you to run, just a few minutes (to clean)
<rellla> nove: i have no sunxi environment here, but if you give me sth, i can do this the next days...
<nove> rellla: ok, but it isn't anything especial, only a test to see if those registers get bits set
<nove> rellla: also the display code has different behavior in sun5i case https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/video/sunxi/disp/disp_video.c#L220
BroderTuck has left #linux-sunxi [#linux-sunxi]
ptitnuage has left #linux-sunxi [#linux-sunxi]
marcin_ has joined #linux-sunxi
<rellla> nove: i suspect, that the way the DIT mode is choosen, isn't right anyway.
<nove> rellla: also this maf hardware block, appear to be independent of the decoding processes
<nove> rellla: if that is the case, it means another dma transferrer to read the frames
<nove> rellla: good for sd video, but for fullhd maybe is too much
<rellla> nove: that's too technical for me :p who is responsible for 40-48?
marcin_ has quit [Read error: Connection reset by peer]
marcin_ has joined #linux-sunxi
<nove> rellla: 38-48 are register to hold memory address
<nove> rellla: one for luma, one for chroma, and needs two frames, the current and the previous
<rellla> and they are set from within VE?
<nove> rellla: and the one more one register for the output (the maf data)
<nove> rellla: yes, i and only speaking about the VE
<rellla> ok. so 0x0040 is the one, that is put into maf_flag_address in display engine.
<nove> rellla: but this is me guessing
<rellla> i saw your guessings ;)
<rellla> i want to activate that DIT_MODE_MAF and need some address to feed in. most likely the address which is in 0x0040 ?!
enrico__ has joined #linux-sunxi
enrico_ has quit [Ping timeout: 265 seconds]
<nove> rellla: yes very likely
<RSpliet> bbrrezillon: ahahah, wow
<bbrezillon> no need to change those memcpy_to/fromio calls
avph has joined #linux-sunxi
<bbrezillon> RSpliet: not sure this will make it to mainline though (there was another attempt back in 2012)
<RSpliet> Russel King has a backdoor to mainline, right ?
<bbrezillon> hm, it's definitely easier for him to get things in, but if it breaks someones code, I'm not sure he can ignore it ;-)
<RSpliet> heh, well, he, Will and Powel know what they're doing
<RSpliet> I'm guessing it's lined up for kernel 4.2
orly_owl has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
kaspter has joined #linux-sunxi
<rellla> nove: DIT_MODE_MAF (0x2) from our 3.4 is called DIT_MODE_RESERVED in allwinner's code on github and DIT_MODE_MAF_BOB get's named DIT_MODE_MAF now. this is all messed up ... :(
kaspter has quit [Remote host closed the connection]
<nove> rellla: maybe my guess of being independent of decoding is wrong, (it need to get the frame size from somewhere, but why then it needs to be given the address of the just decoded frame)
<bbrezillon> RSpliet: what do you think of Yassin's suggestion regarding the u-boot NAND driver (use sunxi specific commands until we all the randomizer and per-partition stuff are merged in Linux)
<topi`> wow, Allwinner has joined Linux Foundation
<bbrezillon> ?
kaspter has joined #linux-sunxi
<RSpliet> bbrezillon: well, as I explained I don't see a big neccessity for per-partition settings for U-Boot
<RSpliet> it's a good feature, but it can wait
<RSpliet> because really most people are only interested in the one partition that contains UBI (or whatever boot part they have)
<topi`> I wish AW would also participate in Linaro... then we would get decent mainline linux support
<RSpliet> I understand from your e-mail that regardless of the per-partition stuff, randomisation is not going to happen upstream either?
<bbrezillon> yes, but still, the randomizer, empty page table (and probably other minor changes) are not mainlined yet, and I doubt they'll be accepted in their current state
<RSpliet> I'm not too happy about a custom command because it will create a legacy
<rellla> nove: this is, what is needed in the new deinterlacer kernel driver: https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/char/sunxi-di/di.c#L121
<rellla> flag_stride is hardcoded to 0x200
<libv> topi`: allwinner joined linaro ages ago
<bbrezillon> what about having a u-boot driver that is as close as possible to the mainline one, and add a few functions to tweak the behavior
<libv> i warned that this might have meant that allwinner ticked the "open source" marketing box.
<libv> and guess what...
<bbrezillon> RSpliet: oh, maybe we can hardcode instead of letting the user decide the value for these parameters
<mripard> RSpliet: everything you're going to do is going to create a legacy
<libv> topi`: read the comments to my latest blog entry for what good linaro is
<bbrezillon> my point is: we should avoid modifying the MTD layer until the Linux MTD guys have agreed on the approach
<RSpliet> bbrezillon: I agree :-)
<bbrezillon> RSpliet: ok great! could you rework you series taking this into account
<MY123> Lemon Pi :P
<RSpliet> I'll see what I can do; I have my "focus meeting" tomorrow, leaving the company in two weeks
<RSpliet> U-Boot interests might conflict with company interest (of making sure Oliv3r can pick up where I leave) ;-)
<bbrezillon> RSpliet: yes I know, that's why I'm asking that now ;-)
<RSpliet> so I'll let you know tomorrow whether I can free up some time or not
<bbrezillon> RSpliet: ok, that's what I was gonna ask
<bbrezillon> I'll take over if you can't finish it
physis has joined #linux-sunxi
<topi`> libv: I think the point of contention is not really Linaro or anything else, but just ARM and their weird jealousy of the Mali architecture
<topi`> however, look at NVIDIA if you want to understand what "jealousy" means
<topi`> I think it's pretty standard on the 3D-chip-vendor-world to wrap their architectures in a veil of secrecy and lawsuits (and binary drivers)
physis has quit [Ping timeout: 256 seconds]
<libv> topi`: heh
<libv> what i meant to show was that linaro is not something holy or an unconditional force of good
<libv> do not expect them to take any stance.
<MY123> libv, Linaro is destroying linux-sunxi
<MY123> (much less interesting for AllwinnerT)
<topi`> libv: did you work on the Nokia N9? (the goddamn old SGX GPU)
<libv> yes.
<topi`> libv: this is funny, then we must know a lot of the same ppl
<libv> i am using it right now to get network.
<topi`> libv: I was the maintainer of Xorg on the N900
<topi`> after Daniel Stone quit
<topi`> the main pain point, unmistakenly, being the SGX
<libv> topi`: when he left for collabora, you mean
<topi`> yeah
<libv> he properly "quit" in Q3 2010
<topi`> wrong wording :)
<libv> when he didn't show up for anything anymore, and he couldn't get properly fired from the team as no-one could reach him
<topi`> that's quite typical of him :)
<libv> the hacking of the radeonhd repo was a response to him thinking i politiced him out.
<libv> politicked even
<topi`> I never realized how politicized the OSS world had become, especially in the corporate<->OSS interface
<libv> even though he claimed he had absolutely no role in that, apart from getting drunk with adam jackson and supossedly handing adam his fd.o root access
<libv> it happened about a month after he got tossed from the team
<libv> if he had been honest, he would've been dumped from collabora
<libv> tbh, most people who are not as politically affiliated would've gotten dumped on the first count already
<topi`> it's easier to live as a consultant nowadays
<topi`> I was never a Xorg (or any other graphics-related) contributor anyways
<topi`> the only reason my boss put me there was because I had hacked some XF 4.0 support in a S3 864 chip of yore
<topi`> but i'm just a hacker
avph has quit [Ping timeout: 244 seconds]
avph has joined #linux-sunxi
<libv> topi`: then you must've worked with harald koenig
<libv> on s3
reinforce has joined #linux-sunxi
<libv> topi`: if you remember that, and you happen to be on an open source conference in europe, and see a neptunus like character: talk to him, he gladly reminisces about his s3 hacking days
<libv> topi`: did you learn that oliver mcfadden died, he ported q3a for n900 and later on joined nokia
<plaes> o_O
<plaes> So that's why he disappeared :(
philippe_fouquet has quit [Remote host closed the connection]
robogoat has quit [Ping timeout: 276 seconds]
robogoat has joined #linux-sunxi
awe00 has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
hansg has quit [Remote host closed the connection]
iamfrankenstein has quit [Quit: iamfrankenstein]
kaspter has quit [Ping timeout: 276 seconds]
jinzo has quit [Quit: Leaving]
Andy-D has quit [Ping timeout: 264 seconds]
khuey|away is now known as khuey
avph has quit [Ping timeout: 246 seconds]
awe00 has quit [Ping timeout: 244 seconds]
Andy-D has joined #linux-sunxi
jinzo has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
indy has quit [Ping timeout: 246 seconds]
indy has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
physis has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 265 seconds]
physis has quit [Ping timeout: 272 seconds]
avph has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
gianMOD has quit [Ping timeout: 276 seconds]
flyhorse has joined #linux-sunxi
flyhorse_kpblY has quit [Read error: Connection reset by peer]
dack has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
iamfrankenstein has quit [Client Quit]
awe00 has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
physis has joined #linux-sunxi
physis has quit [Ping timeout: 244 seconds]
physis has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
domidumont has joined #linux-sunxi
ncrmnt has joined #linux-sunxi
<ncrmnt> Hi all! Anyone had success starting u-boot off SD card on A23? For in my case boot0 always reports wrong CRC no matter what
buZz has quit [Ping timeout: 276 seconds]
domidumont has quit [Ping timeout: 246 seconds]
<nove> new things, same things, more laundry
dev1990 has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
buZz has joined #linux-sunxi
buZz is now known as Guest24715
Guest24715 is now known as buZz
bonbons has joined #linux-sunxi
flyhorse_HJIsj has joined #linux-sunxi
flyhorse has quit [Ping timeout: 264 seconds]
physis has quit [Remote host closed the connection]
physis has joined #linux-sunxi
physis has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 276 seconds]
FDCX_ has joined #linux-sunxi
Andy-D has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
nove has quit [Quit: nove]
physis has joined #linux-sunxi
dack has quit [Remote host closed the connection]
physis has quit [Remote host closed the connection]
bonbons has quit [Quit: Leaving]
ninolein has quit [Remote host closed the connection]
ninolein has joined #linux-sunxi
kz1 has quit [Ping timeout: 252 seconds]
paulk-collins has quit [Quit: Quitte]
kz1 has joined #linux-sunxi
ncrmnt has quit [Ping timeout: 272 seconds]
flyhorse has joined #linux-sunxi
FDCX_ has quit [Ping timeout: 265 seconds]
flyhorse_HJIsj has quit [Read error: Connection reset by peer]
avph has quit [Ping timeout: 240 seconds]
jinzo has quit [Quit: Leaving]
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
sehraf has quit [Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/]
awe00 has quit [Ping timeout: 265 seconds]
physis has joined #linux-sunxi
physis has quit [Ping timeout: 276 seconds]
Night-Shade has quit [Quit: Client exiting]
vishnup has joined #linux-sunxi
vishnup has quit [Client Quit]
naobsd has quit [Quit: naobsd]
Night-Shade has joined #linux-sunxi
physis has joined #linux-sunxi
physis has quit [Ping timeout: 245 seconds]
arossdotme has quit [Ping timeout: 252 seconds]
dev1990 has quit [Quit: Konversation terminated!]
arossdotme has joined #linux-sunxi
khuey is now known as khuey|away
Akagi201_ has quit [Remote host closed the connection]
ricardocrudo has quit [Ping timeout: 276 seconds]
lemonzest has quit [Quit: Leaving]