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
<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?
<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 http://linux-sunxi.org/Langcent_h6s 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
<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: 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
<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
<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: http://linux-sunxi.org/EGON 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
<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
<quitte>
https://github.com/quitte/u-boot 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 :)