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(?))
<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: 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>
[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 sd-card.org 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 http://www.linux-mtd.infradead.org/nand-data/nanddata.html. 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
<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>
linux-rockchip.info 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
<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 ?
<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?
<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
<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
<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>
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?
<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..
<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.