mnemoc changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - did you try looking at our wiki? - Don't ask to ask. Just ask and wait! - - Logs at
pwhalen has quit [Ping timeout: 240 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<libv> heh, olimex kernel didn't help either
fiola has quit [Quit: Leaving]
akaizen has joined #linux-sunxi
pwhalen has joined #linux-sunxi
akaizen_ has quit [Ping timeout: 250 seconds]
paulk-collins has quit [Quit: Ex-Chat]
popolon has quit [Quit: Quitte]
tonyctl has joined #linux-sunxi
tonyctl has left #linux-sunxi [#linux-sunxi]
rafaelMOD has quit [Remote host closed the connection]
<tm512> welp, sold my cubieboard today
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
tomcheng76 has quit [Quit: leaving]
tomcheng76 has joined #linux-sunxi
xavia has joined #linux-sunxi
rainbyte has joined #linux-sunxi
buZz__ is now known as buZz
tonyctl has joined #linux-sunxi
<wens> hmm, hwmon-iio doesn't do user defined labels :(
amitk has joined #linux-sunxi
tonyctl has quit [Ping timeout: 255 seconds]
tonyctl has joined #linux-sunxi
FR^2 has quit [Ping timeout: 272 seconds]
tonyctl has quit [Read error: Connection reset by peer]
tonyctl has joined #linux-sunxi
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
FR^2 has joined #linux-sunxi
tonyctl has quit [Ping timeout: 272 seconds]
tonyctl has joined #linux-sunxi
tonyctl has left #linux-sunxi [#linux-sunxi]
amitk has quit [Ping timeout: 244 seconds]
amitk has joined #linux-sunxi
quitte_ has joined #linux-sunxi
quitte has quit [Ping timeout: 260 seconds]
Black_Horseman has quit [Remote host closed the connection]
Skaag has joined #linux-sunxi
mmarker has quit [Remote host closed the connection]
mmarker has joined #linux-sunxi
rz2k has joined #linux-sunxi
_massi has joined #linux-sunxi
HoloIRCUser has joined #linux-sunxi
_massi has quit [Remote host closed the connection]
_massi has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has quit [Changing host]
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
mmarker2 has joined #linux-sunxi
mmarker has quit [Read error: Connection reset by peer]
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
Nyuutwo_ has quit [Ping timeout: 250 seconds]
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
sehraf has joined #linux-sunxi
techn has joined #linux-sunxi
techn_ has quit [Ping timeout: 240 seconds]
mawe242 has joined #linux-sunxi
<oliv3r_> oh. wow., sun7i spi driver is a mess with regards to dma
<oliv3r_> the spi logic is identical, but dma, and probably dma in general is just horrible between sunxi and sun7i
<oliv3r_> or is it my lack?
<oliv3r_> i see hans has worked on dma_compat.h for sunxi
<oliv3r_> i think it may be for the sound stuff
<oliv3r_> i should look up hi spatches
<mawe242> the olimex guyes seem to have a working spi driver for their A20 boards. maybe they can contribute?
<oliv3r_> Turl: does this make any sense to you?
<oliv3r_> nah
<oliv3r_> they just copy pasted something craptastic
<mawe242> oh... :-/
<oliv3r_> i want to itegrate sun7i support into the current sunxi-spi driver
<oliv3r_> e.g. 'unification' :)
<oliv3r_> no point in having sun4i-spi, sun5i-spi and sun7i-spi
<mawe242> sounds good!
<oliv3r_> when the underlaying hardware is identical, or near identical
<oliv3r_> i've nearly worked out a 'diff'
<oliv3r_> then i'll look at hansg's sound patches to see if he went down the same route, and use that approache
RaYmAn_ is now known as RaYmAN
RaYmAN is now known as RaYmAn
FRQuadrat has joined #linux-sunxi
HoloIRCUser has quit [Remote host closed the connection]
notmart has joined #linux-sunxi
Quarx has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
popolon has joined #linux-sunxi
<oliv3r_> libv: have you pushed your meminfo changes yet?
notmart has left #linux-sunxi ["notmart terminated!"]
<oliv3r_> mnemoc: why isn't there a u-boot tar.xz in your repo-dumps yet?
oliv3r_ is now known as oliv3r
akaizen has quit [Read error: Connection reset by peer]
akaizen has joined #linux-sunxi
juanfont has quit [Remote host closed the connection]
<mnemoc> oliv3r: the repo-dumps thing is manual...
<mnemoc> oliv3r: can you send me an email with things you considering pending or out of sync that I should look at? I'm out of hope on catching with the ML :<
Zboonet has quit [Remote host closed the connection]
<oliv3r> mnemoc: but if i snd you e-mail ...
<oliv3r> de repo's seem reasonably up to date however
<oliv3r> mnemoc: but i'll send you a mail to update all repos and update u-boot ;)
<mnemoc> thanks!
<mnemoc> oliv3r: can you also point me to the current location of sunxi-next ?
<oliv3r> mnemoc: what is sunxi-next?
<mnemoc> mirror of mripard_'s
<oliv3r> you mean the mainline stuff? i cannot
<mnemoc> ok
<oliv3r> i do not know where the most recent sunxi-next is right now
<oliv3r> i am however working on unifieing sunxi-spi, since that one lacked sun7i support
<oliv3r> so need to port it to hans's dma_compat
<mnemoc> oliv3r: a lists of outstanding 3.4 patches is also welcomed :p
<oliv3r> hahaha
<oliv3r> no chance :p
<mnemoc> i lost nothing asking :p
<oliv3r> i have 10.000 unread mails in my mailing list thread
<mnemoc> same here
<oliv3r> $work is keeping me very busy
<oliv3r> how is your work?
<oliv3r> you still like your job? still in DE?
<mnemoc> still in berlin, yes
<mnemoc> stressful and unmotivating
<mnemoc> but love the city ;-)
ads_ has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
<ads_> does sunxi support RTL8201E(L) ? most of a10/20 devices uses RTL8201CP via generic driver. But i cant find any information about RTL8201E(L)
<wens> no reason it doesn't
<wens> ethernet phys are pretty generic
akaizen has joined #linux-sunxi
<ads_> so... RTL8201E(L) will work on generic phy driver ?
<wens> it should
<oliv3r> mnemoc: unmotivating yeah? that sucks :(
<oliv3r> wens: why do we have non-generic USB drivers in sunxi again? was it pure because of the gpio for vbus stuff
<ads_> ok, thx
<wens> oliv3r: i think it was for poking some vendor registers, and yes, vbus
<wens> vbus is handled by the phy driver
<wens> oh, right
<wens> just the vbus thing
<wens> s/.*//
<wens> we have a sunxi 'phy' driver in mainline, which is the non-standard stuff in 3.4 i think
<wens> pokes registers for the usb phy/port, and controls vbus
Gerwin_J has quit [Quit: Gerwin_J]
<oliv3r> wens: yeah but nothing major right?
<oliv3r> wens: e.g. if the rfkill gpio thing is working properly, that can be used instead and mainline drivers can be used instead
konradoo77 has joined #linux-sunxi
<wens> huh?
<wens> usb vs rfkill?
CaptHindsight has quit [Ping timeout: 255 seconds]
<wens> oliv3r: are you trying to drive rtl8188eu or sth on mainline?
<oliv3r> wens: oh no, just curious :p for our project we'll be using atheros based USB wifi modules
<oliv3r> wens: the 3.4 usb driver works just fine
<oliv3r> just wasn't sure exactly why we have the atrocity called rtl8188eu-allwinner
<oliv3r> but that could just dissapear entirly if we have 2 vbus rfkill entries basically
<wens> it's a vendor (realtek) provided driver
<wens> with fex additions of course
<oliv3r> but is it 'better' then the mainline driver in any way?
<wens> don't know :p
<wens> the mainline driver is still in staging
<oliv3r> i assume most people use it because its in the SDK and has the fex shit in it
<oliv3r> ah ok
<wens> and it's not in 3.4 afaik
<oliv3r> right, ok so nothing major then though
<oliv3r> for me to worry about anyway
<wens> :)
<wens> this is how one would enable a usb wifi chip on mainline
<oliv3r> ok one diff thing
<wens> (the empty gpios are just an oddity on this board)
<oliv3r> in the mac drivers there's the cmbk for dma config
<oliv3r> drivers/net/ethernet/allwinner/sunxi_emac.c:181: .cmbk = 0x03030303,
<oliv3r> i'm sure youv've seen that
<wens> actually no, i haven't
<oliv3r> ah, nvm then :p
<wens> :)
<oliv3r> this is how it is defined for sun7i arch/arm/mach-sun7i/include/mach/dma.h:34:}dma_para_t;
<oliv3r> was just looking for a confirmation tha tits the same
<oliv3r> before digging really deeply into it
<wens> can't really help you, i've barely dug into 3.4
<oliv3r> :(
<oliv3r> i don't blame you :)
<oliv3r> i KNEW it was a mess
<oliv3r> but i'm just getting my face rubbed into how bad of a mess it really is
<oliv3r> i really should talk to hansg about this :)
CaptHindsight has joined #linux-sunxi
<wens> is he back from vacation?
<oliv3r> i have no clue
<oliv3r> i guess not :)
ganbold_ has joined #linux-sunxi
avsm has joined #linux-sunxi
Renard has joined #linux-sunxi
Zboonet has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
ads_ has quit [Quit: Page closed]
Andy-D has joined #linux-sunxi
skoperst has joined #linux-sunxi
skoperst has quit [Ping timeout: 246 seconds]
paulk-collins has joined #linux-sunxi
<libv> oliv3r: nope, i haven't
<libv> i will respin as Turl found 2 genuine issues, and i will do as he suggested as well
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 245 seconds]
Andy-D has quit [Remote host closed the connection]
<oliv3r> libv: oki doki
mawe242 has quit [Quit: Leaving]
<libv> oliv3r: are you waiting for these changes? ;)
<libv> oliv3r: meminfo is already in sunxi-tools though
<libv> just the rewrite is still pending
<oliv3r> i was jsut curious :) i saw that meminfo was moved though!
<oliv3r> but no, not waiting for it per-say
avsm has quit [Quit: Leaving.]
Black_Horseman has quit [Ping timeout: 246 seconds]
avsm has joined #linux-sunxi
avsm has quit [Client Quit]
<libv> ssvb: is there anything worth rescuing from:
<libv> imho it's better to have an fbturbo page
Zboonet has quit [Remote host closed the connection]
Akagi201_ has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 255 seconds]
Nyuutwo has joined #linux-sunxi
rz2k has quit []
paloma has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
konradoo87 has quit [Ping timeout: 255 seconds]
FDCX has quit [Ping timeout: 240 seconds]
wingrime has joined #linux-sunxi
FDCX has joined #linux-sunxi
Andy-D has joined #linux-sunxi
paloma has quit []
Andy-D has quit [Ping timeout: 245 seconds]
Andy-D has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
Andy-D has quit [Ping timeout: 272 seconds]
wingrime1 has quit [Read error: Connection reset by peer]
afaerber_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 240 seconds]
bengal has joined #linux-sunxi
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
louka has joined #linux-sunxi
<oliv3r> ssvb: have you ever tested whether SRAM was slower or faste rthen SDRAM/
louka has quit [Quit: Page closed]
<Turl> oliv3r: sram is on the SoC so it should have better latency at the very least
afaerber_ has quit [Quit: Verlassend]
nedko has joined #linux-sunxi
nedko has joined #linux-sunxi
nedko has quit [Quit: kernel panic]
rafaelMOD has joined #linux-sunxi
<oliv3r> Turl: i know there was a discussion about this a few months ago, don't know what ever came of it :)
<oliv3r> also, is there som ehidden SPI1 on PI8, PI9, PI10, PI11, PI12?
<oliv3r> according to the sources there is ...
<Turl> oliv3r: hidden what? where?
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
<oliv3r> i could always be missreading their define of course :)
<oliv3r> Turl: I know, they are using SPI1 on PI
<wens> ha, even chinese tablets have knockoffs
<oliv3r> check the comment in the line i pasted
konradoo87 has quit [Ping timeout: 245 seconds]
<oliv3r> the code below seemms to be matching it, or suggesting it
<Turl> oliv3r: they seem to be off by 1 to our spi0 pins
konradoo77 has joined #linux-sunxi
<oliv3r> yeah but it's SPI1 :)
<oliv3r> dunno if that code eferver gets run anyway
tomboy65 has quit [Ping timeout: 264 seconds]
tomboy65 has joined #linux-sunxi
afaerber has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 245 seconds]
konradoo77 has joined #linux-sunxi
tonyctl has joined #linux-sunxi
tonyctl has left #linux-sunxi [#linux-sunxi]
bonbons has joined #linux-sunxi
<wens> yay
<wens> wonder what kind of product jonsmirl is working on
petrosagg has joined #linux-sunxi
<petrosagg> Hi there!
<petrosagg> Congrats for the awesome wiki, it has helped me a lot but I'm kinda stuck in a problem now
<petrosagg> I'm trying to build a recent kernel for the Cubieboard2
<petrosagg> Specifically linux 3.16.x
<petrosagg> The problem I'm addressing now is NAND support
<petrosagg> And I've seen the patches and work done by bbrezillon to mainline them
<hramrach> I guess nand support is abit experimental still
<petrosagg> I know, it's still under review. But I can help getting support for cubieboard2
<petrosagg> Apparently there already is support for cubietruck
<petrosagg> But it uses a different nand chip
<bbrezillon> petrosagg: sure, any help is welcome :-)
<petrosagg> Oh, great, you're online :)
<hramrach> you can apply some patches and build kernel with them but don't be surprised if it performs poorly, trashes your nand is you use the board heavily, or if next version of the patches trashes your data because it uses different format
<wens> bbrezillon, petrosagg: the other cubies use a different variant of the same series of nand chip
nedko has joined #linux-sunxi
nedko has joined #linux-sunxi
<bbrezillon> petrosagg: do you have the NAND chip datasheet ?
<hramrach> that said testing is needed :)
<wens> Hynix H27UCG8T2BTR-BC
<wens> i have it, if you need it
<petrosagg> bbrezillon: So, I used your sunxi-nand to build a kernel, and also changed the sun7i-a20-cubieboard2.dts file to include the definition of the nand chip
<petrosagg> bbrezillon: Yes, I have the datasheet as well
<wens> though it's a preliminary one i googled
<wens> petrosagg: leaving it to you then :)
<bbrezillon> oh, 16K pages
<petrosagg> wens: alright :)
<petrosagg> bbrezillon: The issue seems to be on the initialisation of the ECC
* wens is off to bed
<petrosagg> I've tried all the possible modes of operation but some simply don't work and others crash the kernel
Zboonet has joined #linux-sunxi
<petrosagg> Do you want me to send you the datasheet?
bertrik has joined #linux-sunxi
<bbrezillon> petrosagg: do you have the backtrace of your kernel crashes
<bbrezillon> ?
<petrosagg> bbrezillon: no it's not that. At least for my cubieboard2. It uses a samsung chip
<hramrach> hmm, I guess I should check what nand chips I have
<bbrezillon> petrosagg: oh, okay, send me the datasheet then
<petrosagg> bbrezillon: Samsung K9GBG08U08
<petrosagg> bbrezillon: datasheet coming right away
<bbrezillon> petrosagg: IIRC ddc tested my patch series with this NAND chip
nedko has quit [Quit: kernel panic]
<petrosagg> bbrezillon: ddc: Do you have the dts source code? The one committed in the repo doesn't enable the nand chip
<bbrezillon> petrosagg: let me check that
<petrosagg> bbrezillon: When the kernel crashes it crashes with this error "No oob scheme defined for oobsize 1024"
<petrosagg> And looking at the source code this happens because it tries to guess the ecc layout
<bbrezillon> petrosagg:
<bbrezillon> petrosagg: could you paste your dts ?
<petrosagg> oops
<bbrezillon> petrosagg: this is mine :D
<petrosagg> bbrezillon:
<petrosagg> bbrezillon: yeah, unexpected clipboard contents :P
<petrosagg> bbrezillon: so this is my dts when I tried "none" ecc mode
nedko has joined #linux-sunxi
nedko has joined #linux-sunxi
nedko has quit [Changing host]
<petrosagg> bbrezillon: but I've tried with hw as well
<bbrezillon> petrosagg: it can't work without ECC (there's too much bitflips on MLC NANDs)
<bbrezillon> but it shouldn't crash either
<bbrezillon> I guess it crashed when you tried "soft" mode
<petrosagg> yep
<petrosagg> I see there is a diffrence between our dts files except for the ecc mode
<petrosagg> but it seems irrelevant
popolon has quit [Quit: Quitte]
<petrosagg> Yours has "reg = /bits/ 64 <0x400000 0x8b000000>;" instead of "reg = /bits/ 64 <0x400000 0x1ffc00000>"
<bbrezillon> that's expected, because the soft ECC (which uses Hamming algorithm) does not support such NAND flashes with large pages
petr has quit [Ping timeout: 260 seconds]
<bbrezillon> petrosagg: yep, the samsung chip is 4GB large while the Hynix one is 8GB large
<petrosagg> bbrezillon: right
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<petrosagg> bbrezillon: this is my error with hw ECC
<bbrezillon> petrosagg: here, you're trying to define a NAND partition that goes beyond the end of the NAND flash device
<petrosagg> bbrezillon: and tracing the function calls it seems to be returning the error code in sunxi_nand_hw_common_ecc_ctrl_init
<bbrezillon> petrosagg: try to resize your last NAND part
<petrosagg> bbrezillon: ok
<petrosagg> bbrezillon: I've also tried defining no partitions in the dts but it still failed. trying to resize the last part now
petr has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 250 seconds]
<bbrezillon> petrosagg: do you have a more precise information regarding where it fails exactly in this function .
<bbrezillon> ?
<petrosagg> yes
<petrosagg> 1 sec
<petrosagg> if (!ecc->strength || !ecc->size)
<petrosagg> here, it's in the beginning
<bbrezillon> oh yes, of course
Nyuutwo has quit [Ping timeout: 246 seconds]
paulk-collins has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
<petrosagg> ? was this an epiphany moment?
<quitte_> bbrezillon: by the way - you don't have nand-rand configured properly on boot0
<bbrezillon> petrosagg: try to apply this patch ttp://
<bbrezillon> petrosagg:
<bbrezillon> petrosagg: it should work after that
<bbrezillon> quitte_: oh
<petrosagg> bbrezillon: on it
<bbrezillon> quitte_: you mean that nand-rnd-mode = "hw"; is missing
_massi has quit [Remote host closed the connection]
<quitte_> yes
quitte_ is now known as quitte
<bbrezillon> quitte: AFAIR, it takes the chip implementation when nothing is defined
<bbrezillon> and nand-rnd-mode = "hw" is defined at the chip level
<quitte> the chip implementation? either way it didn't work for me until i added that line in the device tree
<quitte> could be u-boot once again
<bbrezillon> quitte: anyway, I agree that it should be explicitely defined
<bbrezillon> quitte: no, I did this a while ago and I might have change the driver behaviour in the meantime
mmarker2 has quit [Remote host closed the connection]
<petrosagg> bbrezillon: same issue after the patch
<bbrezillon> petrosagg: WTF!
<petrosagg> setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 ${extra}
<petrosagg> bootm 0x46000000 - 0x49000000
mmarker has joined #linux-sunxi
<petrosagg> damn, sorry :/
ddc has joined #linux-sunxi
<bbrezillon> petrosagg: could you paste the all the boot logs
<petrosagg> bbrezillon: where is the code that selects a device from nand_ids.c? I can add a log there
<petrosagg> bbrezillon: sure
<bbrezillon> petrosagg: in nand_base.c
<ddc> petrosagg: r u using cubieboard2 or 1
<bbrezillon> ddc: Hi!
<petrosagg> ddc: cubieboard2
bengal has quit [Quit: Leaving]
<petrosagg> bbrezillon: boot logs
<bbrezillon> ddc: thanks for joining the discussion => I was out of ideas :-)
<petrosagg> bbrezillon: there are some printk's of my own there but these are the only changes I've done to the kernel
<ddc> petrosagg change the nand ID in on that patch with the same on on the datasheet
<petrosagg> ddc: have you had the cubieboard nand working before?
<petrosagg> ddc: ok, onit
<ddc> For some strange reason this nand comes with two different ids
mmarker has quit [Remote host closed the connection]
mmarker has joined #linux-sunxi
leviathanch2 has joined #linux-sunxi
<petrosagg> ddc: it looks like it worked!
<petrosagg> ddc: there are logs of the kernel scanning for bad blocks, let me see if I can see partitions
<bbrezillon> ddc, petrosagg: can any of you provide me with the patches for cubieboard2 support, or put it on a public repo ?
<petrosagg> bbrezillon: I'll fork your github repo and send a PR
<bbrezillon> petrosagg: great!
<petrosagg> bbrezillon: ddc: thank you so much guys :)
<bbrezillon> petrosagg: you're welcome
<petrosagg> I have a question, why does the kernel scan for bad blocks on every boot?
<bbrezillon> because you didn't enable on flash BBT support ;-)
<ddc> bbrezillon: I'm away from my PC will email it tomorrow
<petrosagg> bbrezillon: is this an easy thing to do?
<bbrezillon> petrosagg: I recently tested it and it works, but you'll have to rebase on my branch
ddc has quit [Quit: ddc]
mmarker has quit [Remote host closed the connection]
<bbrezillon> and then add a property to you nand chip node =>
<petrosagg> bbrezillon: when did you create the v5 branch? :P
<petrosagg> bbrezillon: it was v4 until yesterday I think
<bbrezillon> this afternoon (at least it was the afternoon for me :))
<petrosagg> bbrezillon: great, I'll make sure I rebase. Would you like the PR to target this branch?
mmarker has joined #linux-sunxi
<bbrezillon> petrosagg: sure, it would be perfect
<petrosagg> bbrezillon: alright, I'll send it in the next hours! Thanks again for your help :))
Nyuutwo has quit [Read error: No route to host]
Nyuutwo has joined #linux-sunxi
<rafaelMOD> petrosagg: sorry for the newbie question, but how do you trace the function calls of drivers in kernel?
<rafaelMOD> with ftrace?
<bbrezillon> petrosagg: ddc had some issues with BB detection, could you tell me if it works for you ?
nedko has quit [Quit: BSOD]
<petrosagg> rafaelMOD: sorry for the newbie answer, I just add printk's wherever the kernel might return something containing the function name and a unique number
<petrosagg> bbrezillon: sure
FRQuadrat has quit [Quit: Connection reset by peer]
<rafaelMOD> petrosagg: old classic way! thanks
Quarx|2 has joined #linux-sunxi
Quarx|2 has quit [Client Quit]
Quarx has quit [Ping timeout: 250 seconds]
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 260 seconds]
mmarker has quit [Remote host closed the connection]
konradoo87 has quit [Ping timeout: 260 seconds]
konradoo77 has joined #linux-sunxi
mmarker has joined #linux-sunxi
Playdo has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
dack has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 272 seconds]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<dack> I was trying to get a box like but ended up getting something with the same specs but the board has a completely different layout... if I add it to the wiki should it be a new board or a variant?
nedko has joined #linux-sunxi
nedko has quit [Changing host]
nedko has joined #linux-sunxi
<oliv3r> dack: if the software that runs on it is exactly the same, it's just a 'variant' so only needs a page with pictures
<libv> oliv3r: nope
<libv> dack: go through NDH completely
<libv> dack: if the u-boot code is exactly the same, then that's handled at the dram.c file level
<libv> oliv3r: go do some ndhing yourself :p
deasy has joined #linux-sunxi
<dack> now, now... :)
<libv> well, some people have so far refused to do ndh, and some of them even claimed that there is no point as, for instance, all mk802 devices are the same anyways
<libv> like the mk802_a10s...
<libv> which has no ndh page, only semitime_g2 was ndhed
<libv> semitime_g2 ended up having a completely different memory layout
<libv> so, if the board is different, ful ndh is required
<libv> it's as simple as that
<dack> libv: yeah, I tried doing a linux build and I just get garbage on the screen... that's when I opened it and saw it's completely different
<libv> dack: yeah, that could very well be the reason
<libv> dack: we have like 7 different common formats
<libv> there's the mk802 stick, the square peg htpc, 4 different tablets (3 7" and one 10"), and now this one
<libv> sadly, only the Q8 tablet format has turned up often enough to formalize things
Playdo has quit [Quit: Page closed]
<libv> (the cheap a13/a23 one)
<libv> dack: once you've ndhed this, we can try and find a name for the format, and formalize it as well, so people have an easier time identifying their correct devices.
<dack> The pictures seem to be for the 8gb version and I have the 4gb
afaerber has quit [Quit: Verlassend]
<libv> ok, MH-A20 it is :)
<libv> what do the android strings say?
<libv> anyway, nice
<libv> get your camera out and start taking pictures :)
<libv> and then work your way through ndh :)
<libv> most of the work is in editing the pictures :)
<dack> libv: MH? I found that page by searching for "TXCZ/A20" because it has printed on the board "TXCZ_A20_V1.0"
<oliv3r> libv: your right, been too long :(
<libv> dack: oh, that picture has something else printed on it
<dack> libv: ^_^ I didn't even see that! I'm hoping either J12 or J10 is for a serial UART
bertrik has quit [Read error: Connection reset by peer]
konradoo77 has quit [Ping timeout: 255 seconds]
<libv> dack: anyway, work your way meticulously through NDH
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
<dack> libv: I plan to... thanks
<libv> i will work the formats page a bit
bertrik has joined #linux-sunxi
<libv> although, i was going to send in a new spin of meminfo
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
<libv> hrm
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
<libv> dack: i am not sure whether your .fex change is really desired
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
<dack> libv: the link on the wiki change?
<libv> mnemoc, Turl, oliv3r: what do you guys think for the .fex file link... should people copy sunxi-boards, or should they just grab the single .fex file?
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
bertrik has quit [Read error: Connection reset by peer]
bertrik has joined #linux-sunxi
<libv> i am talking about the manual build info on the device pages... when people click on the .fex, should they be directed to:
<dack> libv: The link there was to the github html version of the .fex file.. I just changed it to point to the raw file
<libv> dack: yeah, i noticed
<libv> dack: i am just wondering which is preferred
<libv> so that all pages can be made to match
<dack> libv: I thought the raw one was better since I had planned on getting it with wget. The other link makes it seem like you're getting the file when you're really not
<libv> yeah, i understand
<libv> i am just not sure which we would want to prefer on our device pages
<libv> as originally, that link was only meant for information, not "download here"
<libv> the manual build howto tells you to clone the repo
physis has joined #linux-sunxi
netlynx has quit [Quit: Leaving]
<libv> dack: as for _config, yeah, but u-boot used to be different
<libv> and they changed once again
<dack> libv: yeah, I was just updating it to what it is now
<libv> again, the manual build howto works around that
<oliv3r> libv: .fex file link from the NDH?
<oliv3r> we need to rename a lost of fex files anyway
<oliv3r> so they match u-boots
<oliv3r> for the bsp anyway
<libv> ...
<libv> nobody tends to use the bsp much
<libv> oliv3r: so _now_ you are saying that the names between sunxi boards and u-boot must match 100%
<libv> device page example has existed for 9 months.
afaerber has joined #linux-sunxi
<libv> and now someone notices that for bsp, you need very specific rules for board and u-boot names?
bertrik has quit [Ping timeout: 272 seconds]
bertrik has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<libv> anyway, if the default is to be changed from github info to raw, i am first removing the sys_config directory from the path
<libv> before i go and change our 90 device pages
kuldeepdhaka has joined #linux-sunxi
<oliv3r> libv: hansg fixed our u-boot ages ago to do a lower(board_name)
<oliv3r> but a while ago it was decided that u-boot should be more like upstream
<oliv3r> or we fix the bsp
<oliv3r> :)
<oliv3r> not sure how to do it
<dack> what is "bsp"? (sorry for the noob question)
<libv> whichever it is, it's going to be a lot of work to properly fix
<oliv3r> basically, u-boot is mixed caps, sys_config is all lower, the bsp uses the fex file name to pass to u-boot
<libv> i doubt that anyone is using the bsp much
<oliv3r> i doubt anybody uses the bsp
kuldeepdhaka has quit [Max SendQ exceeded]
<oliv3r> which is sad! :(
<oliv3r> i would much more prefer to have u-boot use lower letters for the board names
<oliv3r> ijc: ^
<libv> about it being sad...
<libv> i dunno, manual build has become pretty straightforward now that it is well documented and that everyone can read all about it from the device pages straight away
kuldeepdhaka has joined #linux-sunxi
<libv> i guess people feel more in control with the manual build as well
pwhalen has quit [Remote host closed the connection]
<libv> but i think that device pages lead the way though
<oliv3r> the bsp does really nothing more then the manual build does
<oliv3r> it does!
<oliv3r> anyway, bsp does MUCH more then manual building
<libv> such as?
<oliv3r> builds u-boot, linux, cedar stuff, mali stuff and creates a very very nice 'hwpack'
<oliv3r> it can even do hwpack + rootfs to create a sd image
<libv> does that all work?
<oliv3r> the last bit, dunno, haven't used that in ages, it used to
<oliv3r> but the hwpack (default for make) sure does
<oliv3r> i use it allt he time
<libv> then how come you are only now complaining about the naming issue?
<oliv3r> because the hwpack is what is different between each board, rootfs+hwpack is all you really need
<libv> do you only use it on cubie?
<oliv3r> i have complained aout it on the ML when it happened :p
<oliv3r> yeah i only work on cubies and olimexen
<libv> when the naming issue came up?
<oliv3r> 2013 *ducks*
<libv> why didn't you continue that?
<libv> because it's only gotten much much worse ever since
<oliv3r> see, nobody uses the BSP :)
<libv> because there simply are no rules written down in the ndh
<libv> and if it's not in the ndh, the few people who do ndh do not implement it
<oliv3r> well we should reach consensus now
<libv> the others, well, they can fix their own shit
<oliv3r> all board configs in u-boot, all lower case
<oliv3r> all boards in sys_config, all lower case
<oliv3r> anybody against, say so now, or forever hold thy peace :)
<oliv3r> fixing it to all lower is super easy + fast anyway
<libv> oliv3r: but then the upstreamers will complain about u-boot upstream
<libv> like they did a while ago
<libv> oliv3r: but it is not super easy
<libv> because there are 90 device pages
<libv> and 60-70 of them have the manual build info filled in.
<libv> now, i have some other changes lined up as well, which require me to go over all of them
<libv> but still, it's going to be a lot of work
<libv> and i am not going to do that on a whim when there is a severe possibility that the upstreamers will go cry foul
<oliv3r> does the wiki use mixes cases?
<libv> oliv3r: nobody (properly) complained
<libv> it uses whatever is in u-boot and boards.
<libv> so it was not formalized anywhere.
<oliv3r> as long as the wiki search function finds it, i can go over it
konradoo77 has quit [Ping timeout: 245 seconds]
pwhalen has joined #linux-sunxi
<oliv3r> ah it's moved to configs
<oliv3r> i don't seea boards.cfg?
<libv> just like with the raw or not .fex file link
<libv> and we should get rid of the sys_config subdir as well while we are at it
<libv> no, they got rid of that just now
<libv> oliv3r: as said, i need to pass over all device pages for other things as well
pwhalen has joined #linux-sunxi
<libv> but only as one concerted effort
<libv> the _config change was 6 months ago
<libv> now kconfig
<oliv3r> i think u-boot sunxi still uses boards.cfg
<oliv3r> it'll get horrible in time
konradoo77 has joined #linux-sunxi
<libv> besides, the uboot way is broken
<libv> 1200 defconfigs
<libv> the new uboot way
npcomp has joined #linux-sunxi
<libv> what if we end up throwing a further 60 or so defconfigs in there?
<libv> no cpu arch, no soc families
<libv> no ordering whatsoever
<oliv3r> what if there's 2000 more
<libv> what's going to happen Q1 15
<oliv3r> ah ok
<dack> oliv3r: it does
<libv> now you have even less of a chance to see whether your board is listed
<libv> which anyone who is bored today could easily do
<libv> at least boards.cfg you could grep for sunxi
<oliv3r> though to be fair, boards.cfg was horrible
<libv> oliv3r: yes, but we can start by adding our share of 60 or so boards
<libv> indeed
<libv> but this is not an improvement
<oliv3r> i found it hard to read in a 80 line terminal
<oliv3r> yeah it's not
<libv> it's just different
<oliv3r> lets hope ijc backreads and comments :)
<oliv3r> about the caseing anyway
<oliv3r> but i guess sysboards probably will have to be update :S
<libv> sysboards?
<oliv3r> sys_config/boards
<oliv3r> :p
<oliv3r> i'm multitasking and sucking at it
<libv> :)
<libv> anyway, nothing is done until there is full concensus
<libv> we have 90 device pages in the balance here
<libv> that's some real tedious work right there
<oliv3r> aye
<libv> but as said, wifi/ethernet now come with links, and we might need to change to raw links for the fex
<libv> oliv3r: btw, you are now the bsp maintainer.
<libv> if anyone complains, i blame you :p
<oliv3r> amery is!
<libv> but you actually use the bsp
<oliv3r> probably the only person :)
<oliv3r> but for my $job; i have to work on the BSP anyway
<oliv3r> so might aswell :)
<oliv3r> but I may rip it appart and stuff :)
physis has quit []
Skaag has quit [Ping timeout: 244 seconds]
<quitte> what is bsp ?
Skaag has joined #linux-sunxi
Skaag has quit [Ping timeout: 255 seconds]
<quitte> oooooh. it can create livesuite images
<petrosagg> bbrezillon: ddc: are you still here?
<libv> dack: {{|}} is a template
<libv> dack: {{Remove|}} is a template to mark text in red
<dack> libv: it's a WIP
<libv> dack: so 1.6GHz should not be inside {{}}
<dack> ah.. ok
<libv> and besides, 1.6 is a lie, 960MHz is what you tend to get out of A20
<libv> for convenience, we just write 1GHz
<dack> libv: I figured the marketing was wrong, but I wasn't sure how to get the real clock speed
<dack> libv: the specs also say it has a mini HDMI and micro usb port... both wrong
bonbons has quit [Quit: Leaving]
ninolein_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 272 seconds]
<bbrezillon> petrosagg: yep
<petrosagg> bbrezillon: I'm trying to verify the parameters defined in nand_ids.c based on what I see in the dataset but something is wrong
<petrosagg> bbrezillon: Can you take a look at this datasheet ?
<bbrezillon> petrosagg: for the samsung chip ?
<petrosagg> bbrezillon: yes
<petrosagg> bbrezillon: page 43
<petrosagg> bbrezillon: it says that the 4th byte of the ID sequence is always 0x7e
<bbrezillon> petrosagg: and yours is ?
<petrosagg> bbrezillon: now, if you go to the 4th ID Data table in the next page and see the actual bits of the 0x7e byte you'll see that the OOB maps to reserved
<petrosagg> bbrezillon: mine is indeed 0x7e, but the OOB size isn't defined in the datasheet
<petrosagg> bbrezillon: and before I add this fix to my kernel the error I used to get was "No oob scheme defined for oobsize 1024"
<petrosagg> bbrezillon: 1024 being a value that the kernel somehow autodetected
<libv> dack: the chinese are not big on being exact or correct :p
* libv waits for wens to start complaining loudly
<petrosagg> bbrezillon: The chip seems to be working with 640 as the OOB value but I'm wondering whether I'm misinterpreting the datasheet or something else is going on
dack has quit [Remote host closed the connection]
konradoo87 has joined #linux-sunxi
<bbrezillon> petrosagg: indeed, it says 0xe is a reserved value
<bbrezillon> petrosagg: not sure 1024 is a valid value though
<petrosagg> bbrezillon: looks like it's not. I'm just making sure I didn't mix up anything
konradoo77 has quit [Ping timeout: 246 seconds]
Gerwin_J has quit [Ping timeout: 250 seconds]
joedj has quit [Ping timeout: 255 seconds]
<libv> hrm, dact dropped off
<libv> even though i think that this board here might be different from his:
joedj has joined #linux-sunxi
<bbrezillon> petrosagg: well, actually the datasheet says it has 1K OOB areas
<petrosagg> bbrezillon: page no?
<oliv3r> libv: what brand is your new router?
<oliv3r> i just got TP-Link devices for $work
<libv> tp-link 1043
<libv> atheros chipset
<oliv3r> the wdr4300; i open the box, a nice piece of paper with the GPL, I think it's the whole thing
<oliv3r> and som TP-Link + gpl intro
<oliv3r> ah the 1043 i orderd by accident i sent it back
<libv> that's been the case ever since the wrt54g
<oliv3r> wanted 2.4 + 5ghz
<oliv3r> i never seen the GPL in paper form on a router
<libv> 1043 does 5G afaik
<oliv3r> nope
<oliv3r> that's why i sent it back
<libv> my 2007 wrt54gl came with it too
tonyctl has joined #linux-sunxi
<bbrezillon> petrosagg: page 5
<oliv3r> ah ok, i got a ton of wrt54gS they never did i think
<petrosagg> bbrezillion: This? - Page Size : (8K + 1K) x 8bit
<oliv3r> libv: anyway, the WR1043 Wireless Router is single radio, the Wireless Dual Router is dual radio (thus 5ghz)
<libv> ah, i see
<bbrezillon> Organization of Single die
<bbrezillon> - Page Size : (8K + 1K) x 8bit
<bbrezillon> petrosagg: ^
<libv> oliv3r: unless you really need to, stick with the original firmware :)
<oliv3r> libv: and have tp-links backdoors? no thanks :)
<libv> oliv3r: good luck with your (lack of) network then
<oliv3r> for me privatly, i'm going to get a TP-link archer c7 (but only if its the v2) :)
<libv> ath9k is horribly unstable
<libv> hence me complaining
<oliv3r> i have several ath9k devices
<oliv3r> but all work fine for days
<oliv3r> weeks, months even
<oliv3r> got one of those wr703 mini routers for the moment, works pretty good
<libv> i'm really considering throwing away the installation on my wrt54gl (although i do not like to, it was so good and so stable for so long), and going back to that
<libv> but openwrt has shown some further hiccups which i find really troublesome
<oliv3r> i backread yeah
<oliv3r> but i did the rc3 bb install on a 703 mini router, and worked super easy and well
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<oliv3r> but appearantly due to the limited flash on the 54g, the latest firmwares don't run well anymore
<bbrezillon> petrosagg: yes, this line
<oliv3r> what id ont' understand, how ath9k can be so unstable, when the stock firmware should be using it too
<oliv3r> libv: the stock firmware is linxu
<libv> oliv3r: which i threw away the second i got the device
<libv> perhaps in 2011, openwrt on it could've had a stable ath9k driver
<oliv3r> what firmware exactly did you install
<libv> current stable, and the head of the stable branch now (which has a lot of ath9k "fixes", to little avail)
<oliv3r> did you try barrier breaker rc3
<petrosagg> bbrezillon: I'll try with oob set to 1024, I'm now verifying the ECC values
<libv> i don't like spending my days reinstalling my gateway to the world
<oliv3r> attitude adjustment is like 4 years old?
<libv> 2012
<petrosagg> bbrezillon: it seems incorrect as well
<oliv3r> rc3 should be the last RC< hopefully final will be released soon
<libv> the related bugs still have people complain about ath9k though
<libv> so be careful, you might be in for a lot of pain on atheros hw
<bbrezillon> petrosagg: you mean the definition I gave you earlier (the one provided by ddc)
<bbrezillon> petrosagg: actually I suspect the NAND chip are quite different
<petrosagg> bbrezillon: Yes, yhe datasheet and the device id refers to 40bit ECC, but in the definition there was this NAND_ECC_INFO(24, SZ_1K)
<bbrezillon> petrosagg: yep, should be 40, SZ_IK
<petrosagg> bbrezillon: cool, I'll fix that too
<bbrezillon> petrosagg: though I don't get the 40bits / (1K + 128)bytes
<bbrezillon> petrosagg: hm, wait
<petrosagg> bbrezillon: I think it needs 128 bytes of ECC data to be able to correct 40bits of errors
<bbrezillon> petrosagg: ddc's definition was correct, but you're obviously using a different chip (different ID)
<bbrezillon> petrosagg: when you say you'll fix that, you're talking about this specifc chip, not the entry added by ddc, right ?
<petrosagg> bbrezillon: yes, i had to change the .id, remember?
<petrosagg> bbrezillon: yes, I won't add what ddc sent me as I can't test that chip
<bbrezillon> petrosagg: okay, perfect!
<petrosagg> bbrezillon: one question I have is: where is the information that there is hw ECC support and what kind of ECC algorithm is used? Is this in the SoC datasheet?
<petrosagg> bbrezillon: as the nand datasheet only states that 40bit ECC is required but it doesn't specify how
npcomp has quit [Quit: leaving]
<bbrezillon> petrosagg: yes the ECC controller is embedded in the NFC (NAND Flash Controller) block on sunxi SoCs
<bbrezillon> petrosagg: and yes the ECC block capabilities are described in the datasheet, but some informations were extracted from the source code
<petrosagg> bbrezillon: I see that in your dts file you set ecc-mode "hw" for the whole nand but "hw_syndrome" for the partitions. Is this indended?
<bbrezillon> petrosagg: yes, the bootloader partition require a different ECC scheme (actually the ROM code expect it to use the HW syndrome scheme)
tonyctl has quit [Ping timeout: 245 seconds]
<bbrezillon> but we don't want to use this scheme on the whole flash, as it will destroy BB markers
<petrosagg> I see. And may I ask again, where would someone find this information?
<petrosagg> Is this in the uboot source code?
<bbrezillon> that's a good question
<bbrezillon> :-)
<petrosagg> :)
<bbrezillon> for the HW ECC scheme that should be used on each partition, you won't find it..
<bbrezillon> I deduced it from yuq (and other) reverse enginering work
<petrosagg> hm, when you say bootloader you're refering to uboot, right?
<bbrezillon> HW syndrome is just the name chosen by Linux to idenify the ECC scheme where data and ECC bytes are interleaved instead of storing all the ECC bytes in the OOB area
kuldeepdhaka has quit [Quit: Leaving]
<bbrezillon> actually, I was only refering to the SPL part of the u-boot image
<petrosagg> Do you reckon hw_syndrome for the boot partition is needed for the cubieboard2 as well? Or if there is a test I can do to see if it is needed?
konradoo87 has quit [Ping timeout: 240 seconds]
bertrik has quit [Read error: Connection reset by peer]
<bbrezillon> if you want to be able to read/write this partition from Linux, then yes it's required
konradoo77 has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 244 seconds]
<quitte> petrosagg: is the reason. it needs that special partition format and a special binary format to load the next boot stage
<bbrezillon> petrosagg: and you'll to access this partition if you evet want to update your bootloader ;-)
<bbrezillon> quitte: thanks for pointing this out ;-)
<petrosagg> quitte: thanks for the reference
<petrosagg> ok, I'm a bit confused
<petrosagg> I understand that the bootloader needs a specific ecc mode to boot the device from nand
<petrosagg> but how is the ability to read/write to that partition from Linux related?
<petrosagg> I would expect to not be able to boot from NAND, but read/write the boot partition on the NAND chip just fine if for example I used the SD card to boot
<quitte> petrosagg: in that case "bootloader" means the bootloader in the rom of the SoC. it can not be changed
<bbrezillon> if you don't need to access this partition from Linux, you don't care if what you read from there has no sense, because you'll never read it
<bbrezillon> :-)
<quitte> so anything that is meant to be load by that botloader (eGON) needs to match everything it expects
tonyctl has joined #linux-sunxi
<petrosagg> quitte: right, got that
<petrosagg> bbrezillon: so you mean that I will be able to read and write data but they will make no sense to the bootloader
<petrosagg> bbrezillon: but if I use the SD card to boot I don't care about that
<bbrezillon> quitte, petrosagg: no I really meant the bootloader (u-boot) not the ROM code :-), but actually it's only the SPL part of the bootloader
<bbrezillon> petrosagg: sure, if you boot from an SD card you can drop boot0 and boot0-recovery and chose whatever ECC scheme you'd like
<quitte> petrosagg,bbrezillon: my I suggest you stop saying bootloaderand instead use eGON to refer to what's in the SOC's eeprom, SPL as the seconstage bottloader that is started by eGON and finally uboot ? might be less confusing
<petrosagg> bbrezillon: great, now everything makes sense again :-)
<petrosagg> quitte: sure, let's use a better vocabulary
petr has quit [Ping timeout: 255 seconds]
<petrosagg> quitte: sorry about the ambiguous statements
<quitte> don't be. took me a lot of annoying the channel to understand this
<bbrezillon> quitte, petrosagg: and I'm stil not used to this vocabulary :-)
petr has joined #linux-sunxi
petr has quit [Changing host]
petr has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 244 seconds]
<bbrezillon> each platform has its own naming convention
tonyctl has quit [Ping timeout: 244 seconds]
<quitte> sunxi has several. don't forget boot0/boot1 ;)
konradoo77 has joined #linux-sunxi
<petrosagg> um, why do I have to specify the partitions in my dts file? Can't I set them on runtime?
jinzo has joined #linux-sunxi
<quitte> to be able to have different randomizer and ecc settings for different partitions. the kernel arguments with mtdargs= don't support that
<quitte> bbrezillon: ?
<petrosagg> I was about to ask about this kernel argument
<bbrezillon> petrosagg: as quitte said, this kind of partition cannot be defined from the cmdline
rafaelMOD has quit [Quit: Saindo]
rafaelMOD has joined #linux-sunxi
<bbrezillon> quitte: I'm impressed, you're learning fast
<quitte> thanks
sehraf has quit [Read error: Connection reset by peer]
<petrosagg> quitte: is bbrezillon your sunxi mentor? :)
<quitte> I don't know how to answer that. I've been bugging him a lot.
paulk-collins has quit [Quit: Ex-Chat]
<bbrezillon> petrosagg: I wouldn't say that :-). I just spend some time helping quitte getting my sunxi driver working on his board.
<petrosagg> bbrezillon: I really like it when this kind of collaboration happens
<petrosagg> my mission on the cubieboard2 doesn't end here. I have one more issue to tackle. One CPU core fails to initialise
<petrosagg> I haven't looked into it yet, I think I read somewhere in the internet that someone made it work
<petrosagg> Someone on the internet said it so it must be true :P
FR^2 has quit [Quit: Leaving]
<bbrezillon> you should definitely ask mripard_ (or someone else), because I'm not an ARM core expert :-)
<Turl> libv: I think a direct link would be most handy
<quitte> petrosagg: I have that,too. u-boot can fix it but I have no clue what the difference between the uboots that result in an initialized core and the others is
<Turl> oliv3r: wdr3600 here too, the gpl paper on tplinks is nice :) all of their routers have it
<Turl> libv: 1043 only does 2.4, so does wrt54gl
<quitte> Turl: 3.10.44 on my 1043
<quitte> oh never mind, sorry
<Turl> 2.4GHz :)
<Turl> but yeah, pretty out of context :p
<Turl> libv: ah, you're using ancient sw :p
<libv> Turl: built 4-5d ago :p
<Turl> libv: get trunk or rc3 :p
<libv> but then again, the ath9k issues are not fixed yet on trunk either
<Turl> the imagebuilder is awesome :)
<libv> and, nbd has backported loads of things to stable
<Turl> why backport when you can get the fresh stuff :)
<Turl> I upgraded my wdr3600 to rc3 the other day
<Turl> I had a couple months old trunk build on it
<deasy> 1043 powaaa!
<Turl> 1043 is good, but not surgeproof :'(
<deasy> you know another who is ? :p
<deasy> i have a surge protection on my plug
<deasy> for all my equipment
<quitte> petrosagg: the reason it sometimes works must be in here
<Turl> deasy: no :p
<Turl> deasy: I don't think one would've saved mine
<deasy> what happened ?
<Turl> it burned my CM and router and eth port on my PC - I think it got in through the coax
<Turl> nice chain it did
<deasy> ha yes when lighting outdoor i unplug all if i'm at home
<deasy> coax includes
<Turl> oddly enough none of my sunxi who were plugged in to the router got any damage :p
<deasy> none of ? how many do you have !
<deasy> arokux, pwet
<Turl> I had a CT and a mele connected that day
physis has joined #linux-sunxi
<petrosagg> quitte: but the 3.4 kernel works fine using the same uboot
<deasy> i know someone who as a cubie2, i have a cubie1, maybe i buy his cubie2 in some month after he switch to rockchip board
<quitte> petrosagg: all I know is that the openwrt kernel will work with openwrt u-boot. with mainline u-boot the same kernel will fail to bring up the second core
<deasy> anyone has a recommendation for an ereader ? i like the pocketbook basic touch for now
rafaelMOD has quit [Quit: Saindo]
<petrosagg> deasy: I'm really happy with the kindle paperwhite
<petrosagg> quitte: it seems that there are 2 things affecting it then as I see the opposite. problem appears with different kernel but same uboot
<Turl> deasy: the eink kindles make nice ereaders, I don't have any experience with others to compare though
<deasy> kindle is not on my list because of too much closed device :)
<Turl> quitte: maybe you're using a mainline uboot branch without PSCI
<Turl> quitte: are you using the sunxi custodian tree?
<quitte> the what? I'm using plain mainline master
<Turl> deasy: yeah, it's not super open, but it can be rooted and hacked to integrate other reading software
<Turl> quitte: this;a=summary
<deasy> ok ok thank you for yours answers
<Turl> eventually that gets pulled into the master uboot repo
<quitte> Turl: isn't switching on the second core the kernel should ultimately be able to do without u-boot?
<deasy> someone has seen arokux talking here ?
<Turl> quitte: the kernel does a call to PSCI and that brings the core up
Renard has quit [Remote host closed the connection]
<quitte> sigh. that means more digging into git, i guess
jinzo has quit [Quit: Leaving]
<Turl> quitte:;a=commit;h=d5db7024aafc5ea603f3a34f83bb29a1eaa3cbe7
<quitte> I procrastinated cleaning this up better. since apparently that's not going to happen - it's not going to happen
<Turl> that commit probably hasn't landed on mainline uboot yet, but will do so shortly
paulk-collins has joined #linux-sunxi
<quitte> Turl: thanks. will give that a try as soon as I care about the second core
konradoo77 has quit [Ping timeout: 246 seconds]
tonyctl has joined #linux-sunxi
Guest26548 has quit [Remote host closed the connection]
<petrosagg> bbrezillon: BBT support on my chip is working fine :)
<petrosagg> quitte: btw, which is the preferred way of contributing? github pull requests or patches via email?
deasy_ has joined #linux-sunxi
deasy has quit [Ping timeout: 246 seconds]
Nyuutwo has quit [Ping timeout: 246 seconds]
Nyuutwo has joined #linux-sunxi
<quitte> petrosagg: taking over the lead and accepting contributions ;) I used git the first time 12 days ago - so I haven't thought about it.
<quitte> petrosagg: that typo is fixed in the "as-is" commit
<quitte> ...well for any serious definition of used, anyways
tonyctl has left #linux-sunxi [#linux-sunxi]