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
leviathanch2 has quit [Ping timeout: 240 seconds]
leviathanch2 has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 260 seconds]
ganbold_ has joined #linux-sunxi
nedko has quit [Quit: general protection fault]
paulk-collins has quit [Quit: Ex-Chat]
Black_Horseman has quit [Ping timeout: 240 seconds]
deasy_ has quit [Quit: Nom d'un quark, c'est Edmonton !]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
<libv> ok...
<libv> with a probe on the right sd card pin, i got uart out
<libv> latest kernel simply doesn't do anything
<libv> but...
<wens> mnemoc: ok, give me a shell account, i'll upload the a31 sdks :)
<libv> i fear that the a10s olinuxino kernel might have killed the android
<libv> that one gets as far as changing some axp settings before it dies
<libv> which already did the nand loading
<libv> still need to get early printk going on the new kernel to see why it bails that early
<petrosagg> Turl: the u-boot commit you pointed me to works just fine :) I just booted a cubieboard2 with both processors running
<petrosagg> Turl: thanks!
xeros has quit [Ping timeout: 240 seconds]
<Turl> libv: yay :)
MSameer has quit [Excess Flood]
<Turl> petrosagg: np
<libv> another day, another hunterhu picture to delete.
MSameer has joined #linux-sunxi
<libv> oh, and i can undo his changes again
<libv> not capable of learning.
* libv is sending an email
xeros has joined #linux-sunxi
<libv> now, what was this thing about cubietruck and messing up the android image on it...
<libv> ah, wait a second... early printk means chosing a uart...
<wens> libv: what do you think about adding an (optional) section in the NDH for mainline bring-up? (that is, for SoCs already supported)
<libv> wens: write up a separate page about getting a dts up, like i stated some hours ago
<wens> fair enough :)
<libv> and then we'll figure out how to fit it into the lot
<wens> bbrezillon: hmm, i was wrong, both my cubieboards use samsung nands, but my cubietruck uses the B variant of the Hynix chip
<libv> wens: also, it is way more important to collect general hw info, pictures, and the fex file, than to have people create dts files and then run off
<libv> we need the fex file before people run off and create dts files, at least as long as allwinner devices ship with fex files
<wens> i agree
<wens> but anyway, creating the dts requires the fex file, unless you have board schematics
<libv> once the translator is good enough, we might get away with just using that for everything
<libv> ok
<libv> oh, and i believe that mripard_ still has not documented his tool in our wiki
<libv> anyway, if that tool is maintained well (it needs to have users first: WIKI!!!), there might be no need for people to submit and maintain dts files
<libv> but really, no wiki == no users == no testing == dead code == why bother writing it up in the first place?
<naobsd> about a20 lime patch, should I add copyright line into .dts? it's basically copy&paste thing from dts for a10 lime (I think "no" for this kind of work(?))
<libv> somehow i doubt that this will suffice:
TheSeven has quit [Ping timeout: 250 seconds]
<wens> naobsd: you could say based on a10 lime and keep the original copyright, and add your name
TheSeven has joined #linux-sunxi
<libv> so basically, because Allwinner has not complied with the GPL, our GPLed code destroys nand content?
<Turl> libv: so have I heard. Pretty sad state of affairs
<libv> that really is a reason for us to make a big stink.
<libv> i do not understand how we could be "accidentally" writing to the nand though
<libv> oh, ext journalling?
Black_Horseman has joined #linux-sunxi
npcomp has joined #linux-sunxi
npcomp has quit [Client Quit]
quitte_ has joined #linux-sunxi
quitte has quit [Ping timeout: 260 seconds]
npcomp has joined #linux-sunxi
xavia has quit [Read error: Connection reset by peer]
xavia has joined #linux-sunxi
<naobsd> now I learned how to "git send-email", subscribed linux-arm-kernel, let's send patch...
Andy-D has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
Black_Horseman has joined #linux-sunxi
<naobsd> is u-boot maillist moderated?
<naobsd> anyway, I sent patches for a20 lime
<naobsd> reading NDH...
Skaag has joined #linux-sunxi
hipboi has joined #linux-sunxi
skoperst has joined #linux-sunxi
<naobsd> I didn't try any official image from olimex yet
<naobsd> are these params ignored or overwritten by bootloader?
sehraf has joined #linux-sunxi
<hipboi> naobsd, it's overwritten by livesuite when flashing
skoperst has quit [Quit: Page closed]
<naobsd> hipboi: thanks, I see, but I'm feeling something strange :)
<naobsd> hmm, "Your message to U-Boot awaits moderator approval"
<wens> if you're not subscribed, your message needs approval
diego_r has joined #linux-sunxi
<naobsd> I subscribed, then I sent a patch...
<naobsd> wens: anyway, thank you for your guide! I understand procedure
<naobsd> ah, wiki is already updated :)
Andy-D has quit [Ping timeout: 240 seconds]
Andy-D has joined #linux-sunxi
Andy-D has quit [Ping timeout: 260 seconds]
<hramrach> isn't there livesuit for overwriting nand?
<hramrach> like it's the whole purpose of that tool
bertrik has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
bertrik has quit [Remote host closed the connection]
HeHoPMaJIeH has joined #linux-sunxi
<oliv3r> hipboi: hey hey, long time no see
nedko has joined #linux-sunxi
<hipboi> oliv3r, hi
<oliv3r> hipboi: how have you been?
<oliv3r> hipboi: whenn will we see a new raxda board
<hipboi> oliv3r, good thank
<hipboi> oliv3r, just busy :)
<hipboi> oliv3r, rock2 is almost done
<hipboi> oliv3r, with rk3288
skoperst has joined #linux-sunxi
<oliv3r> radxa focusing on rockchip?
<hipboi> oliv3r, not always
<hipboi> we also made allwinner's...
<oliv3r> hipboi: i was just looking at the radxa site, but don't see AW stuff
<hipboi> not advertised
<oliv3r> ahh okay :p
<hipboi> users will get confused :p
<oliv3r> hehe i'm sure :)
<oliv3r> right, $work time :)
<hipboi> oliv3r, do you still work at MS?
<oliv3r> oh no, I work at Ultimaker :)
_massi has joined #linux-sunxi
popolon has joined #linux-sunxi
FR^2 has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
Quarx has joined #linux-sunxi
pirea has joined #linux-sunxi
kuldeepdhaka has joined #linux-sunxi
<lauri> Hi guys
<lauri> couple of following during NAND image flashing is okay right?
<lauri> [Fet]:find a bad block 4095
<lauri> does anyone have clue about the block sizE?
<lauri> 512 bytes?
<lauri> or rather 2k?
<quitte_> lauri that depends on the flash chip
<lauri> this is Cubietruck
<quitte_> but the block sizes are a lot bigger. those are erase blocks, not read blocks. so in the range ´512K-2M
<lauri> with 8GB NAND
<quitte_> okay. 2M then
<lauri> these will be hidden on higher level right? (/dev/nand1 etc)
<quitte_> and yes there always are a couple of bad blocks on nand
<lauri> thanks for the tips ;)
<quitte_> no worries
<lauri> perhaps you could also suggest a way to create an .img file for Sunxi boards?
<quitte_> for phoenixsuite?
<lauri> yes
<quitte_> I shouldn't have called them read blocks above ...
konradoo77 has quit [Ping timeout: 260 seconds]
jinzo has joined #linux-sunxi
xinj has joined #linux-sunxi
<lauri> quitte_: Okay I checked out the BSP repo
<lauri> quitte_: I am looking for a way to create rootfs-less .img with customized boot parameters
<quitte_> you should talk to oliv3r
<naobsd> hmm, one of uSD card behave strangely... fatls works, next fatload failed(error reading cluster), next fals failed too :(
<naobsd> s/fals/fatls/
<naobsd> it happens both cb2 and a20 lime
<naobsd> software issue...?
konradoo77 has joined #linux-sunxi
<quitte_> sounds like a bad sd card to me. or maybe just a corrupted filesystem
mawe242 has joined #linux-sunxi
<naobsd> I can read that uSD on PC, sha1 is same...
<naobsd> it may be bad sdcard, but I have no idea for now
<quitte_> naobsd: once the sd-card is initialized there are no differences in single block read and writes between any. is that card remarkable in any way compared to the others? for example: is it huge?
ddc has joined #linux-sunxi
<ddc> quitte_: hi
<quitte_> hi
quitte_ is now known as quitte
<naobsd> that uSD is 2GB
<ddc> what the status for your u-boot so far?
<ddc> s/for/of
<quitte> ddc: have you seen what i pushed to github?
<quitte> it contains everything i have so far except for the environment
<naobsd> but capacity is not only parameter which is used by driver to configure controller
<quitte> naobsd: the only other one i can think of that could possibly matter is operating voltage.
<naobsd> but I don't have any debug message for now
<quitte> ddc: I also had an email exchange with rgwan. keep in mind there is a language and cultural barrier. but he said he was going to adopt bbrezillon's driver
<ddc> quitte: sounds good
<quitte> I can easily be motivated to add a default environment. All it takes is someone to run into trouble using it.
<ddc> quitte: is this what he is working on?
<quitte> yes
konradoo77 has quit [Ping timeout: 260 seconds]
paulk-collins has joined #linux-sunxi
tomboy65 has quit [Quit: Uhh ... gotta go.]
<ddc> quitte: I guess I should stop working on this since both of you are making a good progress
<quitte> what? no! neither of us did anything about using bbrezillon's mtd. And at the moment my goal shifted to putting all the pieces that are there into openwrt
<bbrezillon> ddc: hm, please don't
<quitte> ddc: also you know what you are doing and I definately and to my impression rgwan,too are just faking it
<bbrezillon> ddc: I mean, you can definitely spend less time on the sunxi NAND stuff if you need to, but all your feedback helped me in my development process...
<ddc> quitte: I can still help with testing.
<bbrezillon> ddc: BTW, what about the suggestion you had to support timing settings on non-ONFI chips ?
Jentec has joined #linux-sunxi
<Jentec> good morning @ all
<Jentec> i get a problem on linux-sunxi on olimex a13
<Jentec> cannot create /sys/class/gpio/export: Directory nonexistent
<Jentec> ./sys/class/gpio is missing
<Jentec> anyone a idee
<Jentec> i compile new kernel since gpio is miising
<Jentec> my kernelconfig
<Jentec> modules sunxi-gpio is loaded
<Jentec> [info] Loading kernel module gpio-sunxi. <6>sunxi_gpio driver init ver 1.3 [ 20.210263] sunxi_gpio driver init ver 1.3 <6>gpiochip_add: registered GPIOs 1 to 14 on device: A1X_GPIO [ 20.219997] gpiochip_add: registered GPIOs 1 to 14 on device: A1X_GPIO
<Jentec> so
<Jentec> hope anyone can helps
<ddc> bbrezillon: I was thinking about adding extra filed to nand_flash_dev namely T_REA and T_RHOH for non onfi nands, not sure if Braian will ok that
<ddc> bbrezillon: I'm still investigating this option
<bbrezillon> ddc: I'm pretty sure he won't agree ;-)
<bbrezillon> ddc: I tried to push for full NAND timing description and all the answer I got was "use the ONFI timing mode"
<bbrezillon> ddc: I guess he'd like to avoid defining a whole bunch of timings for each new NAND chip
Elrond has joined #linux-sunxi
<Elrond> BTW: Is there any planning for TRIM support on mmc/sd (on the a10)? Last time I googled around, I got mostly confused.
<quitte> do sd cards support TRIM? the NDA-free manuals on don't mention such a command
<quitte> or I didn't see it
<Elrond> quitte - I thought, they do. It's called ERASE or something.
<Elrond> quitte - Give me a few momements, I think, I have seen this somewhere.
<wens> quitte: the controller supports ERASE, but for some reason it's not enabled in the mainline driver
<wens> few if any drivers actually claim ERASE capability
<wens> anyway, i've enabled it in my tree, and it works
<wens> i can send a patch for it
<quitte> wens: I don't understand how that is something that the controller can support. It should be something the card does or does not support
<ddc> bbrezillon: looking at Brian list you can see that small subset of these chips support onfi timing, and I not convened that the lowest onfi mode will cater for the none complaint ones
<wens> quitte: right, i'm not familiar with mmc, so i assumed the controller has to at least accept the command
<bbrezillon> ddc: you mean that mode 0 will be to high for these chips
<quitte> wens: so you are the guy to ask ;) I have a card that doesn't work in linux because the driver switches it off after not finding a matching voltage pair between card and controller. this is after the kernel loaded just fine from it
<Elrond> wens - Do you have any clue why this is not enabled in most trees? Is there anything wrong about it? (Okay, in the above link, I read, the ERASE blocks all other IO on the card, but that's something the user can decide by enabling trim on the fs and/or using fstrim.)
konradoo77 has joined #linux-sunxi
<wens> Elrond: i have no clue why :|
<quitte> wens: i wrote a driver for the stm32 and others sd/mmc controller. you can send any command to the card you want.
<wens> quitte: ok, so the card rejects any commands it doesn't support?
<quitte> it's been a while... I don't know what behaviour is defined for bad commands
<bbrezillon> ddc: oh, I didn't know about the webpage!
<Elrond> wens - But I got you right? One has to enable erase/trim in the driver for the controller?
<wens> Elrond: yes
<quitte> wens: it's more like if the card did the right thing it switched into the state you expected it to switch to. you can check that state by using a command that asks the card for its state without making it change its state
<quitte> also its response makes sense of course. however you need to know beforehand what a response is going to look like, since there a different response types of different lengths
<Elrond> So quitte could enable erase in his stm32 driver?
<wens> the drivers that do enable ERASE seem to handle it differently from other commands, like disabling a specific interrupt or sth
<bbrezillon> ddc: how would you choose the timings to specify in nand_flash_dev ?
<Elrond> Ohh, okay. So supporting erase seems a bit tricky.
<quitte> Elrond: kind of. I could add an ioctl. but elmchan fatfs doesn't support it. so it's pointless to me
yann_s has quit [Ping timeout: 250 seconds]
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
<Elrond> wens - No need to handle it differently, "like disabling a specific interrupt or sth"?
<ddc> bbrezillon; you can still use mode 0 for none-onfi but you may need extra fields to tweak the timings
<wens> Elrond: well then the above patch works :)
<wens> i've tried fstrim and mounting with discard
<Elrond> :)
<quitte> wens: all this data should be asked from the card. unless I misunderstand what the code does.
<ddc> bbrezillon: i.e nand start cycle and end cycle
<wens> quitte: not really, the driver declares support for stuff with MMC_CAP_*
physis has quit []
<Elrond> mmc/core/core.c:mmc_erase seems to look at card-data before actually doing anything.
yann_s has quit [Ping timeout: 260 seconds]
<quitte> wens: ah so that's the host side
<quitte> it's fine then
MasterChief4942 has joined #linux-sunxi
<wens> ok then, i'll send out a patch later
<Elrond> wens - Cool! :-)) Thanks! :-))
<ddc> bbrezillon: while for the onfi ones you may set T_REA and T_RHOH to 15 and 20 respectively
Zboonet has quit [Remote host closed the connection]
<wens> also want to enable SDIO_IRQ
<wens> polling wastes some cpu cycles (and keeps my cpu usage led lit)
<quitte> wens: SDIO_IRQ is not used on memory cards
<quitte> again this is only true if we are talking about the same thing
Gerwin_J has joined #linux-sunxi
<wens> quitte: it's for my cubietruck, which has an SDIO wifi chip
<quitte> in that case please go ahead
<wens> though during the sunxi-mmc iterations, hansg noted it wasn't reliable
<wens> need to ask him for details
<Elrond> Okay, and some quirks seem to be needed for some cards. See card/block.c:mmc_blk_issue_discard_rq() (search for MMC_QUIRK_INAND_CMD38)
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
deasy has joined #linux-sunxi
<wens> btw, what is CMD23?
<quitte> SET_BLOCK_CNT
ganbold_ has quit [Ping timeout: 250 seconds]
konradoo77 has quit [Ping timeout: 272 seconds]
kuldeepdhaka has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
skoperst has quit [Quit: Page closed]
<bbrezillon> ddc: why would you change tREA and tRHOH values for ONFI chips ?
Jentec has quit [Ping timeout: 246 seconds]
<quitte> bbrezillon: for ubi I need som information. on cubietruck the eraseblock size is 2M, the page size is(minimum input/output size)? what about subpages?
<bbrezillon> ddc: and for non ONFI chips, are the tweaks you're talking about here to get better performances or to handle cases where timing mode 0 is too fast for the NAND chip
<bbrezillon> ?
<quitte> or i could just run mtdinfo i guess...
<bbrezillon> quitte: MLC NAND do not support subpages
<quitte> okay. so the same as page size
<quitte> 512K?
<quitte> err no K
<bbrezillon> quitte: yep, the same as the pagesize => 8K not 512
<quitte> really
<quitte> where does the 1k of nand write.1k come from then?
<quitte> or is 1k minimum read size?
<oliv3r> bah, a10 and a20 lime's in u-boot don't even have a concistent name :S
<bbrezillon> subpage are only supported by some SLC NANDs supporting multiple write on the same page (2 or 4) without an erase block cycle
<bbrezillon> quitte: the ECC block/step size
<quitte> bbrezillon: I'll have to ask you to teach me the vocabulary on this soon.
afaerber has quit [Ping timeout: 264 seconds]
<bbrezillon> quitte: I'm not sure I'm using the good vocabulary either
<quitte> bbrezillon: well. if i attempt merging your work into uboot i'd better use your vocabulary independent of it being correct
ganbold_ has joined #linux-sunxi
<bbrezillon> quitte: anyway, the ECC algorithm works on data block of either 512 or 1024 bytes this is what we call ECC step or block (depending on the document :-)) size
<quitte> bbrezillon: is that with or without oob?
<quitte> probably without since the numbers are even
<bbrezillon> quitte: this concept is not related to NAND page layout, but to the ECC algorithm itself
<quitte> huh?
<bbrezillon> you could use ECC algorithms on other medias (actually they are used on SDRAM too :-))
<quitte> i thought ecc used extran bits for its correctin
<bbrezillon> quitte: on a NAND flash media yes, the ECC bytes are stored in the OOB area
<quitte> yes. but there is an extra byte for every 4 bytes on sdram
<quitte> okay so the ecc algorithm works on 512 bytes + oob bytes to create 512 correxted bytes?
<quitte> (1024 if that is the case)
<bbrezillon> quitte: a given ECC algorithm is able to correct N bits / X bytes
<quitte> yes.
<bbrezillon> X is the ECC block/step size
<bbrezillon> and N is the ECC strength
<quitte> okay. does the sum have a name?
<bbrezillon> the sum of what ?
<quitte> X and N
<bbrezillon> you cannot sum these 2 values
<bbrezillon> they do not have the same meaning
<quitte> oh right. so X+OOB(X) then. does that have a name?
<bbrezillon> here, it just state that you algorithm is able to correct up to N bits in an X bytes block
<bbrezillon> the ECC bytes needed to be able to achieve this is indeed directly related to the ECC strength and the block size though
<quitte> N=f(OOB(X),X) ;)
<ganbold_> hipboi: so when rk3288 and allwinner SoC based boards will become available?
<bbrezillon> quitte: almost :-)
<quitte> N=f(OOB(X),X,alg_of_ecc)
<bbrezillon> it's more N=f(ECC_BYTES, X)
<hipboi> ganbold_, samples of rk3288 board will be ready next month
<quitte> ah that's where hw_syndrome comes into play
<quitte> the data may be interleaved with the ecc data
<bbrezillon> where ECC_BYTES is the number of bytes you reserve for ECC in your OOB area
<hipboi> ganbold_, allwinner soc board is based on a20, 204pin so-dimm module
<hipboi> ganbold_, it's already ready
<bbrezillon> quitte: yes
<bbrezillon> quitte: with HW Syndrome, you have this: (M *(DATA + ECC_BYTE)) + OOB_REMAINING_BYTE
<ganbold_> hipboi: nice, please let me know when rk3288 ready
<bbrezillon> where M is the number of ECC blocks in one NAND page
<quitte> so the in band and oob data that are necssary to calculate one ecc block got to have a name. does that happen to be a sector?
<libv> hipboi: do you have a ballpark figure for how many cubieboards/cubietrucks have been sold already?
<bbrezillon> quitte: with standard ECC scheme you have: (M * DATA) + (M * ECC_BYTE) + OOB_REMAINING_BYTES
<quitte> what is REMAINING_BYTES ?
<libv> hipboi: i'd guess many 10s of thousands in the meantime, but not sure whether 100k has been reached already
afaerber has joined #linux-sunxi
<bbrezillon> quitte: you ECC algorithm often need less bytes than actually available in the OOB area
<libv> hipboi: since they are sold directly in even the (german electronics chain) conrad, it's quite the success
Gerwin_J has quit [Quit: Gerwin_J]
<bbrezillon> quitte: these available bytes can be used by NAND flash users (actually JFFS2 is using some of these bytes to store its metadata)
<bbrezillon> quitte: I'm not sure sector is the right word for this concept
<quitte> unfortunately sector is a word that pops up in yuq's uboot
<bbrezillon> quitte: a sector often refernce to the minimum io size on a block device (i.e. an HDD)
<libv> hipboi: i hope raxda is doing well though, but i somehow feel that it cannot be _as_ successful as the cubieboard was, as that really was the right product at the exact right time
<quitte> and it most definately is the wrong word as it describes physical geometry
<hipboi> libv, i think cubie1/2 and CT together around 100k for now
<libv> there's a lot more competition now, but i still hope that you're making a decent profit out of it
<libv> hipboi: that's quite an amazing figure :)
<bbrezillon> quitte: not sure you have to name the ECC block + ECC bytes association
<hipboi> libv, yes, but nothing to do with me any more
<libv> hipboi: i bet that you never thought you'd reach that when you started it 2ys ago
<MasterChief4942> Trying to make Sunxi matrix keypad work, getting error: "sw keypad fetch keypad uning configuration failed. keypad: cannot find using configuration, return without doing anything!" what I did wrong?
<libv> yeah, sadly
<hipboi> libv, i knew it would sell for a long time
<quitte> bbrezillon: there are rows and columns in nand, right? so a row consists of data followed by an oob region?
<libv> sure, but 100k from an indiegogo for... 2.5 or 3?
<hipboi> 1.5k from indiegogo
<libv> that's something to be proud of, no?
<quitte> if that was true an erase block would be 2048 rows in the case of the ct
<hipboi> libv, yes, it's something to be proud of
<hipboi> libv, of course
<bbrezillon> quitte: yep a row is a page (including the OOB area)
PulkoMandy has joined #linux-sunxi
<quitte> sigh. "page"
<ddc> bbrezillon: Ignore that. mode 0 may seems to a bit faster for K9GBG08U0A but it should works just fine
<libv> seems pretty dead :(
<bbrezillon> quitte: and no, in the ct case, a block contains 256 pages (block = 2M, page = 8K, nb pages per block = 2M/8K => 256)
<hipboi> libv, not as active as linux-sunxi
<quitte> bbrezillon: a page is the ECC block and ECC bytes and some additional OOB ?
<libv> linux-exynos is doing something, but still not much compared to us
<quitte> okay. so I'm thinking of a row structure wrongly
<bbrezillon> ddc: unfortuantely, if it's a bit faster, that's not something we can ignore :-(
<bbrezillon> quitte: no, a page contains M ECC blocks + M ECC bytes + remaining OOB bytes
<bbrezillon> M depends on the page size and the ECC block size
<bbrezillon> in ct case, M = 8K / 1K => 8
<quitte> bbrezillon: i assume everything within a page can simply be addressed in 16bit words?
<bbrezillon> quitte: it depends on your NAND bus width
<quitte> seems to be 16, looking at the ct dts
<bbrezillon> quitte: though most of them use an 8 bits bus
<bbrezillon> quitte: no it's 8 :-)
<bbrezillon> quitte: at least for the Hynix chip
<quitte> okay. I'm not going to ask
<oliv3r> mnemoc: why does the BSP keep overwritting my configuration when i run make :S
<bbrezillon> quitte: and I'm pretty the A20 does not support 16 bits bus width
bengal has joined #linux-sunxi
<quitte> so looking at a single row is it 8 data blocks and then 8 oob blocks . or 8 pairs ?
<bbrezillon> quitte: again, the layout (how things are stored on the NAND) depends on the ECC scheme
<quitte> so oob is special in no way except for what kind of data is stored at a specific address?
<bbrezillon> quitte: exactly
<bbrezillon> quitte: you could even store your data in the OOB area
<quitte> finally :) thanks a lot. I'll let that sink in while playing with ubinize
<bbrezillon> quitte: that's just some extra space NAND manufacturers reserve to handle NAND weaknesses
<oliv3r> bbrezillon: I'm so glad others are digging into NAND with you!
<bbrezillon> quitte: and a common practice is to put your ECC related data (ECC bytes) in that area
<quitte> bbrezillon: with read-retry do you simply read until there are no ecc errors, or do you somehow improve the accuracy with each retry?
<quitte> some kind of weighted sum
<bbrezillon> quitte: the current implementation retry the page read until there's a valid read (all the bitflips found on a page are sucessfully corrected)
<quitte> uhm i meant until all errors are ecc correctable, of course
<quitte> bbrezillon: if my resetting the ct until it loads the kernel is an indication that is a bad algorithm
<bbrezillon> quitte: the problem with that approach is that we may quickly hit the bitflip threshold, and thus UBI will keep moving data from one block to another ...
<bbrezillon> quitte: read retry does not just imply reading the page several times
<bbrezillon> quitte: each time you read a page you change the bit level detection of the NAND chip
<quitte> what is a bit level?
<bbrezillon> quitte: this document might help understanding how it works =>
<bbrezillon> quitte: on MLC NAND chips a single cell store 2 bits
<quitte> ah. the the hysteresis characteristics of the amplifier
FreezingCold has quit [Ping timeout: 255 seconds]
<bbrezillon> quitte: read retry is just a way to change reference levels (see Fig. 1) between each read, and find the reference level where you hit the least amount of bitflips
<bbrezillon> quitte: you might also read things about paired pages ;-)
<quitte> sram is so incredibly nice
konradoo77 has quit [Ping timeout: 260 seconds]
nedko has quit [Quit: kernel panic]
mawe242 has quit [Quit: Leaving]
FreezingCold has joined #linux-sunxi
<ddc> bbrezillon: nand_bbt: error while writing bad block table -22
<ddc> I've added nand-on-flash-bbt property to the dts and tried to format
<Elrond> wens - BTW: Let me know, when you posted the patch, so I can follow the thread. :)
<ddc> bbrezillon: this based on pre-v5
mmarker has quit [Remote host closed the connection]
mmarker has joined #linux-sunxi
<bbrezillon> ddc: does it manage to create the BBT at startup (you should see it in your boot logs)
<ddc> Bad block table written to 0x0000fff00000, version 0x01
<bbrezillon> ddc: should be written on the last 2 blocks of your NAND chip
<bbrezillon> ddc: is it what you see ?
<ddc> yes I can see that
<bbrezillon> okay
<ddc> this was on the first boot
<ddc> when I tried to format mtd5(rootfs)
ricardocrudo has joined #linux-sunxi
MasterChief4942 has quit [Quit: Leaving.]
<bbrezillon> ddc: I don't recall exactly but you've set rnd-mode and ecc-mode to "hw" in your nand chip node right ?
dack has joined #linux-sunxi
<ddc> bbrezillon: what so special about mtd4(kernel) partition that its bad blocks are stored while the others are not
<bbrezillon> ddc: the only thing you changes is the ecc-mode => you set it to hw_syndrome
<bbrezillon> ddc: but that should impact the BBT
<ddc> this even before applying BBT property
<bbrezillon> sorry should not
<ddc> if you look @ kernel@a00000 the reg is defined as reg = /bits/ 64 <0x800000 0x800000>;
<bbrezillon> yes
<dack> libv: in , "blurp" should probably be "blurb"
<ddc> I'm not matching the offset in the reg could this be an issue
<libv> dack: nice catch
<bbrezillon> ddc: no
<bbrezillon> this @xxx string is only used for information purpose
<bbrezillon> ddc: can you try to decrease the NAND chip size on nand_ids.c
fredy has quit [Ping timeout: 256 seconds]
<bbrezillon> (try with half the real size)
pirea has quit [Quit: Leaving]
<bbrezillon> ddc: can you paste the result of this command (cat /sys/kernel/debug/clk/clk_summary | grep nand) ?
fredy has joined #linux-sunxi
<ddc> nand 1 1 25000000 0
<ddc> ahb_nand 1 1 160000000 0
<bbrezillon> ddc: sounds good
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
dantob has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
dantob has quit [Quit: dantob]
dantob has joined #linux-sunxi
<bbrezillon> ddc: does decreasing the chip change anything ?
konradoo87 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 264 seconds]
<oliv3r> why is sunxi-3.4 such a big mess :(
<libv> because allwinner wrote most of it?
<libv> oliv3r: what issues are you having that make you complain about this now?
<oliv3r> heh
<oliv3r> i'm trying to add unified sun7i support to the spi driver
<oliv3r> the spi is unified to sun5i and sun4i
<oliv3r> code wise its' easy, but the dma stuff between sun7i and 'sunxi' is different, hans did write a dma_compat.h to address some issues
<oliv3r> but we now also have mach/dma.h for each arch and a plat/dma_defs.h
<oliv3r> in dma_defs.h are all the definitions, but they are repeated in mach/dma.h
<oliv3r> dma_defs.h is not included anywhere, but patches have been written against dma_defs.h
<oliv3r> someone added duplex SPI support and added it to dma_defs, but it can't work, yet it's there
<oliv3r> probably some combination of config settings exlcudes most of that code I suppose
<oliv3r> i know i've seen some complains (and possible patches) on the sunxi mailing list
<oliv3r> so I fixed that, i guess, doing a compile test of a13 now
<ddc> bbrezillon: I decreased to 1G, did make a difference
<bbrezillon> ddc: is it worst or better :-)
<ddc> bbrezillon: ?
<bbrezillon> ddc: you said it made a difference when setting it to 1G
<ddc> bbrezillon: I will try to apply erasure patch
<ddc> sorry : typo I meant did not make any difference
<bbrezillon> ddc: can you try to use an higher ONFI timing mode ?
<ddc> nop
<bbrezillon> ddc: and after that, try to force the nand clk to 20MHz in the set_timing func
<bbrezillon> ddc: nop, because you already tried, or because you're afraid of what it could do to your NAND ?
<ddc> bbrezillon: never tried it.
<bbrezillon> ddc: I doubt this will solve your problem though
afaerber_ has joined #linux-sunxi
<bbrezillon> ddc: I just don't understand what's happening here
hipboi has quit [Read error: Connection reset by peer]
<bbrezillon> ddc: and you said it was working the old version of my driver (v3)
<bbrezillon> ?
<ddc> bbrezillon: it did work to some extent
afaerber has quit [Ping timeout: 250 seconds]
<wens> Elrond: just sent the patch (to linux-arm-kernel & linux-mmc)
<ddc> bbrezillon: I was able to all the bad blocks , attach/detach UBI and create volumes
dantob has quit [Quit: dantob]
gzamboni has quit [Remote host closed the connection]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
hipboi has joined #linux-sunxi
<ddc> bbrezillon: I've tried mode1 and nothing changed and then mode 4,3,2 and that made the nand accessible.
<ddc> bbrezillon: I will try to lower the nand clock now
<bbrezillon> ddc: you mean inaccessible
<ddc> sorry: inaccessible
<ddc> yes
<bbrezillon> ddc: you can also try to set nand-ecc-mode and nand-rnd-mode to "none" in your root nand@0 node
<ddc> bbrezillon: Kernel panic when setting nand-ecc-mode and nand-rnd-mode to "none"
<libv> paulk-collins: you were complaining about the wild sunxi-3.4 defconfig differences, right?
* libv is getting rather weary of the sun7i kernel and how huge it is
<paulk-collins> libv, yep
<paulk-collins> libv, I sent a message on the mailing list on that matter
<libv> ah, right
<paulk-collins> and a patch to fix compilation with the Android toolchain
<paulk-collins> libv, is the mailing list the right place for sending patches against sunxi-3.4?
<libv> yeah
<paulk-collins> it seems to be mainline-oriented nowadays
<libv> because there's pretty much me and mnemoc left on helping people with hardware that isn't development boards
<paulk-collins> ah :/
<paulk-collins> libv, I can do the work on 3.4, I just need to make sure everyone is ok with it
konradoo87 has quit [Ping timeout: 244 seconds]
konradoo77 has joined #linux-sunxi
<libv> your drm fix is a bit of a nobrainer it seems
<libv> there is little point in doing cleanup
<libv> but the defconfigs thing looks good, as for making separate android configs
<libv> and yes, removing those stale configs also sounds good to me
<libv> let me just mail in
<paulk-collins> ok
xavia has quit [Remote host closed the connection]
konradoo77 has quit [Ping timeout: 245 seconds]
<ddc> bbrezillon:set chip->clk_rate = 20000000 no go as well
ddc has quit [Quit: Page closed]
<wens> mripard_: do you have the sun6i i2c node fix somewhere in your tree?
tgaz has quit [Ping timeout: 240 seconds]
kuldeepdhaka has joined #linux-sunxi
Skaag has quit [Ping timeout: 255 seconds]
<oliv3r> i'll try to review your mails paulk-collins ; but no promisses, I am rather busy :(
<paulk-collins> thanks
<oliv3r> but since i just ran into a defconfig issue myself, I'm tempted to review :p
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
konradoo77 has joined #linux-sunxi
xavia has joined #linux-sunxi
kuldeepdhaka_ has joined #linux-sunxi
kuldeepdhaka has quit [Ping timeout: 255 seconds]
FR^2 has quit [Quit: Connection reset by peer]
paulk-collins has quit [Remote host closed the connection]
<Elrond> wens - Thanks. :)
tgaz has joined #linux-sunxi
xinj has quit [Quit: xinj]
pwhalen has quit [Ping timeout: 255 seconds]
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<Elrond> net/built-in.o: In function `tcp_is_local6':
<Elrond> /mnt/Devel/sunxi-kernel/net/ipv4/tcp.c:3369: undefined reference to `rt6_lookup'
<Elrond> Is this expected on the 3.4.90+ tree when enabling ipv6 as module?
pwhalen has joined #linux-sunxi
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
leviathanch2 has joined #linux-sunxi
fredy has quit [Ping timeout: 244 seconds]
avsm has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 272 seconds]
konradoo77 has joined #linux-sunxi
fredy has joined #linux-sunxi
PulkoMandy has joined #linux-sunxi
avsm has quit [Quit: Leaving.]
rafaelMOD has joined #linux-sunxi
<Turl> libv: we already have separate android configs (in theory at least)
<Turl> the _crane, _nuclear and such
afaerber_ is now known as afaerber
<libv> Turl: perhaps paulk should be told about them ;)
<libv> dack: no manufacturer pics, please
<libv> make some of your own
<libv> i now have to go delete these
<dack> libv: I couldn't get the case open to take any pics of the bottom. I asked them and they were nice enough to provide that and give permission to use it
<dack> libv: do you need some sort of written permission or something?
<libv> oh, then state that you got permission
<libv> no, i believe you
<libv> but i tend to delete about a picture a day, things which i can immediately google
<dack> libv: :) okay, I just added a note
<libv> dack: can you rename these?
<libv> no need to have a note
<libv> just rename them and stick them in the normal pictures list
<libv> actually, your inside pic is pretty good
<libv> so delete the board top one, it's pretty low resolution anyway
<dack> libv: Well, I put them seperate because they seem to be slightly different then the unit I have. It looks like they have UART pins, no LED, or IR
<libv> hrm, could it be that this is a different board then?
<dack> libv: their top one has labels on the J12, mine doesn't
<dack> libv: I showed the guy my picture and he sent me that picture. I think it may be an earlier or later production. Same everything but different labels
<Turl> libv: that was my intention but he's not here
<libv> indeed, different revision, some small changes all over the place
<libv> realtek phy and everything
<libv> dack: i think this is preproduction hw, as it lacks an led and irda
<libv> but it does label the uart
<libv> it's the one parallel to the ram
<dack> libv: they said they sell a semi-knockdown version... it may be that
paulk-collins has joined #linux-sunxi
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
PulkoMandy has joined #linux-sunxi
<dack> libv: changed the filenames to English
<libv> thanks :)
Akagi201_ has quit [Remote host closed the connection]
bonbons has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
<dack> okay... I'm having some issues figuring out the UART pins.. I'm no electrical engineer. :)
<dack> I nearly "let out the magic smoke" from my USB-TTL dongle
<dack> I seem to be getting 3.3v when connecting to two of the pins (using the USB shielding as a GND)
<dack> shouldn't it only be on one connector?
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
leviathanch2 has quit [Ping timeout: 272 seconds]
mmarker has quit [Read error: Connection reset by peer]
PulkoMandy has joined #linux-sunxi
<quitte> dack: most uart are push pull. however some are open drain - meaning they have pull up resistors and the signal is changed by "shorting" to ground
<quitte> so it is possible to find 3,3V on both rx and tx
mmarker has joined #linux-sunxi
<dack> quitte: well, I find it on 2 connectors... I'm guessing one is the 3.3v connector, but is the other one TX? Does it give that voltage even if nothing is being transmitted?
<quitte> dack: you were talking about pictures. maybe I can have a look?
<quitte> usually there are 4pins VDD,RX,TX,GND
<dack> quitte: I'm working on this device:
<dack> quitte: I think either (or both) J12 or J10 are UART connectors... unfortunately no labels
amitk has quit [Quit: leaving]
<quitte> dack I'd go with J10 since it has the resistors i expected to see
<dack> J10 seems to have 3 spots with 3.3v
<dack> quitte: there's also this pic provided by the mfg: It seems to be slightly different, though. But shows something connected to J12
<quitte> the outer pair is supply. GND is obvious. and the round outer pad has a wider trace going to it. indicating power
<dack> k.. that seems to match the labelling on the mfg version
<dack> what could J12 be used for then?
<quitte> spi?
<dack> what's that?
konradoo77 has quit [Ping timeout: 240 seconds]
<quitte> a bidirectional dataport
<dack> k.. I'll try using J10
<quitte> on the other hand .... the 4th trace of J12 goes to the power management chip
<dack> quitte: success on J10!
leviathanch2 has joined #linux-sunxi
<quitte> great :)
_massi has quit [Quit: Leaving]
konradoo77 has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
kuldeepdhaka_ has quit [Ping timeout: 245 seconds]
ganbold_ has quit [Ping timeout: 250 seconds]
yann_s has quit [Quit: ZNC -]
gzamboni has joined #linux-sunxi
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
kuldeepdhaka_ has joined #linux-sunxi
diego_r has quit [Ping timeout: 240 seconds]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 260 seconds]
konradoo77 has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
<quitte> any idea why it's not mounting the rootfs?
konradoo87 has joined #linux-sunxi
<Elrond> The Bus-Pirate should work to connect to the serial uart on the a10-lime, right?
konradoo77 has quit [Ping timeout: 245 seconds]
<quitte> yes. sounds unnecessarily complicated, though
<Elrond> quitte - Why?
<quitte> since usb to serial adapters are cheap and don't need configuration beyond 115000,8n1. they already are what you want them to be without configuration
<Elrond> Well, yeah, but the Bus-Pirate is anyway on my wanna-have-list.
<quitte> since you don't already have it - get both
<Elrond> hehe. :)
<quitte> get multiple usb to serial adapters while you're at it. Then you can just leave them in place and use a new one
paulk-collins has quit [Remote host closed the connection]
<Turl> quitte: missing driver for the fs? you can check that
<dack> Is there any way to get the boot info over a serial connection without the use of a USB cable in FEL mode? The device I have has only regular sized USB ports and I don't have any OTG cable with regular sized USB on both ends
<Turl> try adding rootwait otherwise
<dack> quitte: "VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -5"
<dack> I saw that in your log
<dack> Turl: that comment directed towards quitte?
<Turl> dack: yes, that's why it starts with "quitte:"
<Turl> :)
<quitte> Turl: the mmcbl0p2 is a squashfs and i have support for that
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
<Turl> quitte: maybe add rootfstype=squashfs then?
<quitte> Turl: I got further with booting from squashfs on a ubi volume. I'll focus on that
leviathanch2 has quit [Ping timeout: 240 seconds]
<Elrond> Okay, serial console not needed, I am confused, very confused.
<Elrond> I compiled a fresh 3.4.90+ kernel with some changes in menuconfig. Most things work, except ssh-ing into the box. I am asked for the password, and then nothing. I had hdmi and a kbd connected and could login locally. Nothing in dmesg, I even tried sshd -D -d, but that doesn't give anything either.
* quitte hands elrond a blessed unicorn horn
<dack> so, is it possible to get boot0/1 info via just the serial console? Is there something in the uboot menu?
leviathanch2 has joined #linux-sunxi
<quitte> dack: boot0/boot1 do output information on the serial console
<quitte> uboot doesn't have what I'd call a menu
<quitte> Elrond: what if you enter the wrong password?
<Turl> dack: what kind of info do you need?
<Elrond> quitte - Will try next. I just restored the default-olimex-3.4.90-kernel and ssh works again.
<Elrond> quitte - Or will try tomorrow evening.
bertrik has joined #linux-sunxi
<dack> I'm trying to get the info to configure uboot
<Elrond> dack - I have no idea.
<dack> quitte: I'm talking about the uboot command line prompt
<quitte> okay. yes that is available on the serial console
<dack> quitte: how do I get that? Is it just in all the info printed out?
<quitte> dack: reboot and then press a key to stop the countdown
<dack> quitte: booting with the stock rom, right?
Akagi201 has joined #linux-sunxi
<quitte> it's worth a try. I don't know anything about stock behaviour of any of the boards, though
<dack> what's the uboot command to get the boot details for configuring uboot?
<quitte> dack: otherwise use a mmc to boot from
<quitte> dack: printenv
<dack> quitte: I think if I boot from the sdcard with the misconfigured uboot that I'll just get those misconfigured settings :)
netlynx has quit [Quit: Leaving]
Akagi201 has quit [Ping timeout: 246 seconds]
<dack> quitte: k... I'm in the uboot command line... now what?
<quitte> now you type help and press enter
konradoo87 has quit [Ping timeout: 255 seconds]
<dack> quitte: lol. okay, but which of those many many commands give me something to configure uboot-sunxi
<quitte> printenv and setenv
<quitte> and don't touch saveenv until you are sure you know you want things to stay that way
<quitte> in fact changing the environment is ultimately the only thing that changes things
<dack> quitte: okay, so probably only the stock uboot will have the correct info, right? The MMC that I created with the wrong config will just give me the wrong config info, right?
<dack> quitte: the stock uboot has a 0 second wait and I can't seem to get into the menu... Should any key before that still get me into the menu
<quitte> what are you even trying to do?
<dack> trying to get uboot working for
<quitte> dack: ah. is there a uEnv.txt file on the mmc? edit that
<dack> ... adding a new device
<dack> quitte: the onboard NAND has no uEnv.txt or kernel file
<quitte> oh that's what you mean
deasy has joined #linux-sunxi
deasy_ has joined #linux-sunxi
deasy_ has quit [Remote host closed the connection]
<quitte> you may be able to dump the environment using the uboot on the mmc - edit that - then write it back
<quitte> however i never used uboot with libnand flash support a lot. so i can't help you there
<quitte> what's wrong with booting from mmc anyways?
<dack> quitte: there's no uboot config for my device.. I need to create one. I used the wrong config because I originally mis-identified it.
<quitte> okay
<quitte> you are in uboot right now and there is a mmc inserted?
<quitte> that mmc contains a fat filesystem on the first partition?
<quitte> dack ?
<libv> dack: try using android itself
<libv> dack: get an ssh server installed
<libv> and you probably do not want to install a sunxi-3.4 kernel yet
<libv> you might hose the nand
<libv> dack: ssh server from the android app store
<libv> get it set up, find out what its ip address is
<libv> ssh in, run meminfo, mount nanda and grab script.bin
<libv> apart from the details of dealing with android, it's all in the wiki under retrieving device info
<libv> dack: another option is to ask your manufacturer for a livesuit image
<libv> as for fel mode, i am not sure whether that is possible without usb otg
<libv> but i should go and test on a device i own myself, the hc860
<libv> but since you have direct communication with the manufacturer:go for it
<libv> ask them for a livesuit image and information on how to flash it
<mripard_> wens: hmmm, I think I deleted the branch that had it :(
<mripard_> there's still my tag though.
konradoo77 has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 240 seconds]
paulk-aldrin has joined #linux-sunxi
Faisal has joined #linux-sunxi
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
rainbyte has quit [Read error: Connection reset by peer]
kuldeepdhaka_ has quit [Ping timeout: 260 seconds]
<dack> quitte: sorry.. had to step out
<dack> libv: yeah, I mounted the nanda partition and got the script.bin already. Is it possible to get the information I need to config uboot through there?
PulkoMandy has joined #linux-sunxi
<quitte> dack: have you tried accesing mmc from u-boot? fatls mmc 0
Faisal has quit [Ping timeout: 245 seconds]
<dack> quitte: I'll try that now.
Faisal has joined #linux-sunxi
<dack> quitte: "** Unrecognized filesystem type **"
leviathanch2 has joined #linux-sunxi
<quitte> dack: okay. that is good
<quitte> assuming the mmc does in fact not contain a fat filesystem on partition 1
<quitte> but it seems to me that you have everything in place to boot your own kernel
rainbyte has joined #linux-sunxi
<dack> quitte: I compiled uboot with Langcent_H6S_config, but that's not the board I have. I get a wack of errors on the serial console when booting from SD. Don't I need a proper configuration for uboot?
kuldeepdhaka has joined #linux-sunxi
<dack> quitte: here's a dump from what I get when trying to boot from the sdcard:
<quitte> uboot doesn't do a lot. basically it loads the kernel into ram and executes it. it does provide some extra functionality ...
<Elrond> On some boards it preloads some board specific config, no?
<quitte> I don't know anything about the fex business. but with flat device tree it is simply loaded into ram the same as the kernel
<quitte> dack: looks pretty good upto about line 425, doesn't it?
<dack> quitte: is there something just after that that looks wrong?
<quitte> yes. for example the lcd display stuff
<quitte> and sata
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<quitte> maybe its just very noisy. you're in a better position to see what works and what doesn't
bertrik has quit [Quit: reboot]
<Black_Horseman> hola
<quitte> dack: ah in the end it reboots. however before that there's not a lot to complain about. finds the mmc card. finds the del keyboard. outputs on the serial port. finds ethernet...
bertrik has joined #linux-sunxi
<dack> k.. maybe my issue is all kernel configuration..
konradoo77 has quit [Ping timeout: 250 seconds]
<dack> I fixed the LCD error with the following post:!topic/linux-sunxi/SDunHbWVFpU
<quitte> yup. I'd start by disabling graphical output and then continue disabling things until i get a login prompt
konradoo77 has joined #linux-sunxi
<quitte> bbrezillon: trying to move to a newer kernel in openwrt opened a huge can of worms. before I abort - do you recall any good reason why i tried to move to 3.16 or 3.17rc1 that i may have forgotten about?
<Elrond> quitte - The new netfilter? ;o)
nedko has joined #linux-sunxi
Nazcafan has joined #linux-sunxi
hypothalamus has joined #linux-sunxi
sehraf has quit [Ping timeout: 260 seconds]
ninolein_ has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
dack has quit [Remote host closed the connection]
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
Gerwin_J has joined #linux-sunxi
<libv> hrm... dack just dropped off :(
<Elrond> Okay, big kernel recompile from scratch and ssh works. Now the modules.
Gerwin_J has quit [Ping timeout: 250 seconds]
konradoo77 has quit [Ping timeout: 250 seconds]
<libv> Turl: is this the googlegroups one?
konradoo77 has joined #linux-sunxi
pwhalen has quit [Ping timeout: 240 seconds]
protoCall7 has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
pwhalen has joined #linux-sunxi
<Turl> libv: I dunno, are there many linux-rockchip?
<libv> do all the kernel folks agree with a google group as a maintainer ml?
<libv> i thought there were fanatics against it :)
* libv now wonders how we are in there...
<Turl> we don't have any sunxi specific list on the kernel
leviathanch2 has quit [Ping timeout: 272 seconds]
hypothalamus has quit [Read error: Connection reset by peer]
bertrik has quit [Remote host closed the connection]
ricardocrudo has quit [Remote host closed the connection]
jinzo has quit [Quit: Leaving]
xavia has quit [Remote host closed the connection]
bengal has quit [Quit: Leaving]
imcsk8 has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
Skaag has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
Nazcafan has quit [Quit: Quitte]
pwhalen has quit [Ping timeout: 240 seconds]
Akagi201 has quit [Ping timeout: 255 seconds]
Skaag has quit [Ping timeout: 260 seconds]
Skaag has joined #linux-sunxi
<mripard_> Turl: it's an infradead ml
pwhalen has joined #linux-sunxi
paulk-aldrin has quit [Quit: Ex-Chat]
Gerwin_J has joined #linux-sunxi
rafaelMOD has quit [Quit: Saindo]
Skaag has quit [Ping timeout: 240 seconds]
physis has joined #linux-sunxi
<libv> mripard_: somehow that felt more appropriate
leviathanch2 has joined #linux-sunxi
physis has quit []
Gerwin_J has quit [Quit: Gerwin_J]
<libv> seems like this guy is pretty much on his own there.
protoCall7 has quit [Quit: protoCall7]
protoCall7 has joined #linux-sunxi
<libv> this does not seem like a friendly kind of move
pwhalen has quit [Ping timeout: 245 seconds]
leviathanch2 has quit [Ping timeout: 250 seconds]
leviathanch2 has joined #linux-sunxi
dl9pf has quit [Ping timeout: 244 seconds]
dl9pf has joined #linux-sunxi
pwhalen has joined #linux-sunxi
vbmithr has joined #linux-sunxi
vbmithr_ has quit [Ping timeout: 244 seconds]
xavia has joined #linux-sunxi