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
quitte has joined #linux-sunxi
techn has quit [Read error: Connection reset by peer]
<quitte> turns out that the rgwan/yuq u-boot can actually flash boot0 ( such that it works
<quitte> unfortunately mksunxiboot doesn't output a matching sunxi-spl,yet
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 250 seconds]
libv_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
libv has quit [Ping timeout: 250 seconds]
libv_ has quit [Read error: Connection reset by peer]
libv has joined #linux-sunxi
<Turl> libv: isp going bad?
popolon has quit [Quit: Quitte]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 250 seconds]
akaizen has joined #linux-sunxi
libv has joined #linux-sunxi
egbert has joined #linux-sunxi
libv_ has quit [Ping timeout: 250 seconds]
egbert_ has quit [Ping timeout: 260 seconds]
imcsk8_ has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
xavia has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
bbrezillon has quit [Quit: WeeChat 0.4.2]
TheSeven has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
Skaag_ has joined #linux-sunxi
awafaa_ has joined #linux-sunxi
ijc_ has joined #linux-sunxi
FreezingAlt has quit [Ping timeout: 272 seconds]
diego_ has joined #linux-sunxi
diego_r has quit [Disconnected by services]
diego_ is now known as diego_r
imcsk8_ has joined #linux-sunxi
joost_dt1 has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
imcsk8 has quit [Ping timeout: 250 seconds]
Skaag has quit [Ping timeout: 250 seconds]
awafaa has quit [Ping timeout: 250 seconds]
joost_dtn has quit [Ping timeout: 250 seconds]
Zboonet has quit [Ping timeout: 250 seconds]
ijc has quit [Ping timeout: 250 seconds]
[7] has joined #linux-sunxi
Zboonet has joined #linux-sunxi
awafaa_ is now known as awafaa
FreezingAlt has joined #linux-sunxi
furan- has joined #linux-sunxi
<furan-> is there a way to buy one of the aw-som/merii a31s modules without putting my credit card on that aw-som website?
<wens> mnemoc: are you using a cronjob to push the mirrors to linux-sunxi?
<maksimlin> furan-: do you mean the merrii a31 hummingbird?
<maksimlin> oh sorry I see now - theres a diff module
tonyctl has left #linux-sunxi [#linux-sunxi]
xavia has quit [Remote host closed the connection]
<furan-> yeah it's a simple core board
<furan-> not the hummingbird
quitte_ has joined #linux-sunxi
quitte has quit [Ping timeout: 264 seconds]
amitk has joined #linux-sunxi
_whitelogger_ has joined #linux-sunxi
bluse has joined #linux-sunxi
bluse_ has quit [Quit: No Ping reply in 180 seconds.]
_whitelogger has quit [Write error: Broken pipe]
heffer has quit [Quit: No Ping reply in 180 seconds.]
heffer has joined #linux-sunxi
heffer has quit [Changing host]
heffer has joined #linux-sunxi
MackBoy_ has joined #linux-sunxi
MackBoy has quit [Ping timeout: 240 seconds]
hypophthalmus has joined #linux-sunxi
hypophthalmus has quit [Quit: Leaving.]
hypophthalmus1 has joined #linux-sunxi
hypophthalmus has joined #linux-sunxi
hypophthalmus1 has quit [Read error: Connection reset by peer]
hypophthalmus has left #linux-sunxi [#linux-sunxi]
<wens> can't get sunxi-3.4 rtl8188eu to probe on my a23 tablet :(
Quarx has joined #linux-sunxi
<wens> fixed
Faisal has quit [Read error: Connection reset by peer]
rm has quit [Quit: ZNC -]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
rm has joined #linux-sunxi
rm has quit [Changing host]
rm has joined #linux-sunxi
deasy has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
tomboy65 has quit [Remote host closed the connection]
libcg has joined #linux-sunxi
tomboy65 has joined #linux-sunxi
<wens> libv: yay, hsg h702 page finished
rm has left #linux-sunxi ["Leaving"]
<mnemoc> wens: yes, mirrors and "nightly" run by cron
<mnemoc> wens: something out of sync?
bbrezillon has joined #linux-sunxi
ddc has joined #linux-sunxi
<wens> mnemoc: nah, was hoping for sth more magical, like github doing the mirrors for you
akaizen has joined #linux-sunxi
_massi has joined #linux-sunxi
<ddc> bbrezillon: Hi has this issue being resolved in sunxi-nand-pre-v4-fixed
<bbrezillon> ddc: yes, it should be
sehraf has joined #linux-sunxi
<ddc> bbrezillon:I'm having similar issue but with ubiattach after a reboot, I did detached cleanly before rebooting
nicxz has quit [Quit: Leaving]
<bbrezillon> ddc: these are not exactly the same
<bbrezillon> are you sure your NAND does not need read retry ?
<bbrezillon> ddc: you're still testing with a K9GB08U0A, right ?
<ddc> bbrezillon: yes K9GBG08U0A
<ddc> from what you mentined only Hunix nands need read retry
paulk-aldrin has joined #linux-sunxi
<ddc> mentioned
<bbrezillon> ddc: you're right -> this NAND does not require read_retry
<bbrezillon> ddc: but other NANDs from other manufacturers requires it (see the ReadRetry field in
<bbrezillon> ddc: have you tried to detach/attach the mtd part before rebooting ?
<ddc> yep
<bbrezillon> and it shows the same errors .
<bbrezillon> ?
<ddc> bbrezillon: yes
<ddc> Sorry: this only happen after rebooting
Skaag_ is now known as Skaag
<bbrezillon> ddc: is anyone else touching mtd2 before booting the linux kernel ?
boycottg00gle has joined #linux-sunxi
<ddc> detach/reboot/attach
<bbrezillon> ddc: I think you're writing on bad blocks (0, 1, 12, ...) are the one mentioned as bad by mtd tools
<bbrezillon> can you revert the patch forcing BB erasure
<bbrezillon> then re format your partition
<bbrezillon> ddc: BTW, regarding the read retry question you asked me yesterday -> the Micron read retry handling has already been merged, but it's only applicable to Micron NANDs
<bbrezillon> ddc: and, as usual, HW manufacturers like to do their own (proprietary) stuff to implement common features :-), this is why we'll have to implement read retry for each an every manufacturer (if not for every NAND chips requiring read retry) :-(
FR^2 has joined #linux-sunxi
Renard has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
focus has quit [Remote host closed the connection]
montjoie has quit [Quit: Leaving]
popolon has joined #linux-sunxi
avsm has joined #linux-sunxi
<libv> wens: smashing stuff :)
F1skr has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 255 seconds]
<libv> Q88 will also be ndhed now, as i just received one
<libv> ah, no, the motherboard is slightly different, and will have to be called q88db
petr has quit [Ping timeout: 246 seconds]
<libv> aha, forfun q88db
montjoie has joined #linux-sunxi
focus has joined #linux-sunxi
notmart has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
<libv> heh, this one actually has HH-Q8 in relief on the back panel
FunkyPenguin has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 250 seconds]
Gerwin_J has joined #linux-sunxi
quitte has joined #linux-sunxi
quitte_ has quit [Read error: Connection reset by peer]
<quitte> ddc: it seems you have various sunxi devices? could you set BLOCKSIZE to 1024 in u-boots tools/mksunxiboot.c to check that it doesn't break the spl on any of those over time?
<libv> aha, seems i still need to upload the Q8 info as well
<quitte> bbrezillon: I guess it makes more sense to ask you: the read blocks on NAND chips are usually 512bytes but the hynix' is 1024?
<ddc> quitte: I'm not currently working on u-boot. I'm just testing the kernel driver
MasterChief4942 has joined #linux-sunxi
<MasterChief4942> Hello, please help mounting *.img as file system, searched lots via Google but nothing works. here is output of fdisk -l /media/gaga/e75534d5-38df-4e36-bbae-bdd2d5124473/Cubian-base-r8-a10.r3p2-01rel2.qt530.img
<quitte> that is not a filesystem image but meant to be flashed with a proprietary tool
<MasterChief4942> quitte: I've copied it to 8gb usb flash drive and it creates single partition containing rootfs
<MasterChief4942> quitte: there is no way mounting it?
<quitte> can you mount it if it is on the usb flash drive?
<quitte> asking because I'm not sure if you can, but want to know how to loopback mount it from the file
<MasterChief4942> quitte: yes, I can open that single file system volume when it's written on USB drive with dd
<quitte> oh. then I guess I was wrong about it being a livesuite image.
<quitte> MasterChief4942: you need to specify an offset to the partition in you mount options
<MasterChief4942> quitte: sudo mount -o loop,offset=1048576 -text3 /media/gaga/e75534d5-38df-4e36-bbae-bdd2d5124473/Cubian-base-r8-a10.r3p2-01rel2.qt530.img /opt/qt5.cubie2/ct-rootfs
<quitte> is the first thing I found with google
<MasterChief4942> not works
<quitte> how about fdisk -l image.img ?
<libv> MasterChief4942: why are you messing with this?
<MasterChief4942> libv: why not?
<libv> MasterChief4942: i want to know what you would like to achieve.
<mnemoc> to mount partitions of an image use kpartx
<MasterChief4942> quitte: here is output
<MasterChief4942> mnemoc: good idea, will try now
maksimlin has quit [Quit: ChatZilla [Firefox 31.0/20140715215003]]
<ddc> bbrezillon: no much diffrence after reverting the patch.
<ddc> bbrezillon: But if I detached it and the attached it works just fine
<bbrezillon> quitte: are you talking about block dev emulation on top of mtd layer (mtdblock) ?
<bbrezillon> ddc: ubiformat shouldn't write things on a bad block, and it seems it considers the bad blocks as valid when you attach mtd2
<ddc> bbrezillon: I've noticed that the during bootup the nand scan hangs for about 8s and it doesn't show all the BB
<bbrezillon> ddc: can you check /sys/class/mtd/mtd2/bad_blocks value ?
<ddc> that is a valid point
<bbrezillon> ddc: [ 0.791066] Bad eraseblock 2 at 0x0000002fe000
<bbrezillon> [ 0.797818] Bad eraseblock 3 at 0x0000003fe000
petr has joined #linux-sunxi
<ddc> bbrezillon: 6 BBs
<bbrezillon> ddc: given your previous logs I was expecting 7
<ddc> bbrezillon: ubiformat: 6 bad eraseblocks found, numbers: 0, 1, 12, 13, 1726, 1727
<ddc> bbrezillon: UBI: good PEBs: 2218, bad PEBs: 6, corrupted PEBs: 0
<bbrezillon> ddc: can you reboot your system and check that it detects 6 BB at boot ?
<[7]> oh, nice to hear people talking about mtd ;)
<[7]> is that somewhat close to usable yet?
<ddc> bbrezillon : [ 0.790890] Bad eraseblock 2 at 0x0000002fe000 [ 0.797658] Bad eraseblock 3 at 0x0000003fe000
<ddc> bbrezillon: that is all
<bbrezillon> [7]: it depends on what you by usable :P
<bbrezillon> ddc: and [ 0.791066] Bad eraseblock 2 at 0x0000002fe000
<ddc> yep
<bbrezillon> ddc: and what about /sys/class/mtd/mtd2/bad_blocks ?
<ddc> before or after attaching ?
<bbrezillon> before
<ddc> 0
bengal has joined #linux-sunxi
<bbrezillon> ddc: I think the problem is here ;-)
<bbrezillon> ddc: the other isue I see, is that it doesn't detect BB 12, 13, 1726 and 1727
<bbrezillon> ddc: can you also check /sys/class/mtd/mtd[0-1]/bad_blocks ?
<ddc> bbrezillon: all zeros
<quitte> bbrezillon: I was talking about the reasoning behind the nand1k write. eGON does checks on blocks. That seem to be of at least 512 bytes size. I was hoping you could shed some light on why yuq used 1k blocks instead.
<quitte> bbrezillon: got eGON to boot u-boot spl.
<bbrezillon> quitte: this has to do with how the ROM code is reading the boot0 partition. As far as I can for A10 SoC it only uses 1k of data on each page, no matter what the NAND page size is
<bbrezillon> quitte: I remember seeing different behaviour on A20 (but I'm not sure)
<bbrezillon> quitte: great, how did you program it ?
<quitte> bbrezillon: nothing to program. I just needed to realize that I have to change the 512byte alignment of mksunxiboot to 1024 byte alignment
<quitte> oh you mean program as in flash? that was with nand write.1k
<quitte> i also added a line making the padding 0xff instead of uninitialized. I don't know if that matters
<quitte> everything yuq did years ago
<bbrezillon> quitte: you're working on a cubietruck, right ?
<quitte> yes
<bbrezillon> quitte: could you try to dump boot0 from Linux (using nanddump /dev/mtd0 -f /tmp/boot0)
<quitte> i already did. doesn't work. strings /tmp/boot0 doesn't show eGON
<quitte> oh that's not true
<quitte> I get flipped bits and ecc errors or something
<quitte> and then strings doesn't show egon
<quitte> at one point i could dump successfully but then I noticed that spl was gone. I probably erased that
<bbrezillon> quitte: and you kept the nand parititions as defined in my patch series ?
<quitte> I renamed boot0 to spl but kept it. changed the others, though
<ddc> quitte : as bbrezillon said the BROM code access the first 128 pages in 1k with random enabled.
<quitte> so now there are 4 hw-syndrome partitions
<bbrezillon> quitte: should not be a problem, as long as you keep randomizer enabled (set to hw), and do not change the rnd seeds for boot0 and boot0-recovery
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
<quitte> why boot0-recovery?
<bbrezillon> quitte: don't remember exactly, but I noticed there were two identical erase blocks when programming with AW tool
<quitte> so probably for livesuite compatibility. either way i renamed it to uboot, but the size is still 2M
<quitte> bbrezillon: you said you dumped and flashed successfully. did you look for eGON or any other strings?
<bbrezillon> quitte: yep
<bbrezillon> it was there
<bbrezillon> can you dump the first mtd0 page without ECC correction (nanddump /dev/mtd0 -f /tmp/boot0 -n -l 8192)
<quitte> after i flashed that i knew nand write.1k works. didn't work in linux by writing to mtd0
<bbrezillon> quitte: just try to dump it before trying to write anything on mtd0
<quitte> sure. it'll take some time. don't know in which state i left things when i blacked out
<ddc> quitte: since u r using yuq driver in u-boot why don't just read/write spl using nand read/write.1k" command.
MasterChief4942 has quit [Quit: Leaving.]
<bbrezillon> ddc: yep, that's a solution, but I'd like to check that my driver is still able to read/write boot0 ;-)
<quitte> so do i
<quitte> bbrezillon: no eGON in the strings. in fact nothing human readable
<bbrezillon> quitte: you're still basing your work on my v3, right ?
<quitte> yes
HeHoPMaJIeH has joined #linux-sunxi
<bbrezillon> quitte: can you paste your dts somewhere ?
<ddc> quitte: livesuit flashes boot0 twice I guess that why we need boot0-recovery
quitte has quit [Read error: Connection reset by peer]
quitte has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 250 seconds]
bengal has quit [Remote host closed the connection]
<quitte> in case it got lost in the reconnect
bengal has joined #linux-sunxi
<bbrezillon> quitte: you miss this property nand-rnd-mode = "hw"; in your sp part
<bbrezillon> quitte: s/sp/spl/
<quitte> weird. I think I copy&pasted that. recompiling....
<ddc> bbrezillon: Do u have any idea why the nand scan takes that long during bootup
<bbrezillon> ddc: because it's the 2 last pages of each block (to check BB markers)
<bbrezillon> ddc: I haven't tried on-flash BBT, but I think we can try it as soon as everything works
<bbrezillon> ddc: just need to add nand-on-flash-bbt property to your NAND node in your DT ;-)
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
nedko has quit [Quit: kernel panic]
nedko has joined #linux-sunxi
<quitte> bbrezillon: still no eGON in the strings. can i doublecheck that i enabled nand-rnd-mode = "hw" in proc? catting the file didn't yield any information
<bbrezillon> quitte: yes in /proc/device-tree/...
<quitte> cat /proc/device-tree/soc@01c00000/nand@01c03000/nand@0/spl@0/anything returns nothing
<bbrezillon> quitte: does /proc/device-tree/soc@01c00000/nand@01c03000/nand@0/spl@0/nand-rnd-mode exist ?
<quitte> yes
<bbrezillon> and when you cat, it resturns hw, right ?
<quitte> no. it returns nothing. just like label, name ...
<quitte> cat /proc/device-tree/soc@01c00000/nand@01c03000/nand@0/spl@0/*
<quitte> splsplhw_syndromeJ.hw
<quitte> so it's in there somewhere ;)
<bbrezillon> quitte: yes it's there
<bbrezillon> (the last hw)
<bbrezillon> and when you dump spl part you still get nothing
<quitte> okay. something wrong with the terminal emulation i guess. i now got hwsyndrome and hw out of their respective files
<quitte> bbrezillon: I get something. but applying strings to that returns nothing human readable
<quitte> just some gibberish
<bbrezillon> so you've dumped it into a file, right ?
<bbrezillon> /tmp/boot0 or something else...
<bbrezillon> just launch hexdump -C on this file
<quitte> yes
<bbrezillon> and paste the result
ddc has quit [Quit: Page closed]
<bbrezillon> quitte: indeed, it doesn't look like a valid boot partition
<quitte> it does still boot, however
<bbrezillon> quitte: can you remove the nand-randomize-seeds property from spl@0 ?
<hramrach> does android support exfat?
<hramrach> AW supplied android SDK for A13
<hramrach> I don't expect the vendors would add support
bengal has quit [Remote host closed the connection]
<quitte> no change ...
F1skr has quit [Ping timeout: 255 seconds]
dack has joined #linux-sunxi
<quitte> but nand-randomizer-seed doesn't exist in the spl branch of the device tree
<bbrezillon> quitte: that's because it's set to 0x4a80 by default
<quitte> okay. that's what i get for the seed of uboot
<bbrezillon> quitte: I don't see any random config in yuq driver...
<quitte> i could change the seed of the rootfs and see if it fails to boot if that's any help
<hramrach> iirc yuq driver does not have randomizatioon at all
<quitte> bbrezillon: the 0x4a80 is there ...
<bbrezillon> quitte: can you try to disable the randomizer by setting nand-rnd-mode = "none";
<quitte> will do
<bbrezillon> quitte: okay, my bad, I was looking at sunxi_nand_spl.c
<quitte> that stuff is not enabled. rgwan didn't cherry pick enough of the spl stuff. that's what i actually wanted to do right now ;)
<quitte> bbrezillon: the dump is the same
<quitte> root@OpenWrt:/tmp# cat /proc/device-tree/soc@01c00000/nand@01c03000/nand@0/spl@0
<quitte> /nand-rnd-mode
<quitte> none
<bbrezillon> quitte: hm, rnd-mode = "none" and the dump is the same, something is seriously wrong here
<quitte> how about i mess up the rootfs settings and see if it continues to boot?
<bbrezillon> quitte: why would you do that ?
<quitte> to see if there is any randomization going on at all
<bbrezillon> quitte: I still don't get the link between randomization and the rootfs settings ?
<quitte> rootfs is on nand, too
<bbrezillon> okay, you want to change rootfs partition settings
<quitte> yes
<bbrezillon> yes, that's a good idea (I thought you were talking about bootargs parameters)
ddc has joined #linux-sunxi
<quitte> still boots
<bbrezillon> ddc: hey, you're back
<bbrezillon> ddc: can you try this patch: ?
<quitte> changed hw randomization to none and added 0x1111 to the first double-octet
<bbrezillon> ddc: it should fix the BB counting issue
<bbrezillon> quitte: are you based on my sunxi-nand branch or have you manually applied the patches ?
<quitte> I did only minor changes to the patch files if any at all. iirc the cleanly applied after i applied the ecc patches first
<quitte> but it was the patch series, not the branch
<bbrezillon> quitte: how many patches did you apply ?
<quitte> 11 in total. 2 ecc and your 9 part series
* quitte checks
<quitte> yes
<bbrezillon> quitte: okay, that patch series is definitely not the good one
<bbrezillon> quitte: it does not include all the stuff needed for randomization, per-partition ECC, ...
ddc has quit [Ping timeout: 272 seconds]
<quitte> i even asked beforehand ;)
<bbrezillon> quitte: it was intended to get the first part of sunxi NAND driver mainlined
ddc has joined #linux-sunxi
<Turl> hramrach: unlikely
<bbrezillon> quitte: this is why randomization is not working on your system
<quitte> bbrezillon: is there any point in approaching this today for you? otherwise I'd start cherrypicking nand-spl
hramrach has quit [Quit: WeeChat 0.4.3]
ricardocrudo has joined #linux-sunxi
ddc has quit [Ping timeout: 272 seconds]
<bbrezillon> quitte: I sent you an email with an archive containing all the patches extracted from my sunxi-nand branch
<bbrezillon> quitte: but please try to use git, this would be much easier for both of us
<quitte> lovely. thanks. I'll look into applying those in the next days. I'd better finsish u-boot and clean it up before I forget how i did things
avsm has quit [Quit: Leaving.]
<quitte> bbrezillon: the problem is that I want patches for openwrt's kernel. I don't know how to get that kernel under git control in a sane way. it's in a directory that is created by openwrts build system
<bbrezillon> quitte: if you need the patches, you could clone my repo and use git format-patch (that's exactly what I did to send you the patches) ;-)
<quitte> how did you filter out your mtd related work?
<oliv3r> quitte: did you port bbrezillon's patches to u-boot?
<quitte> oliv3r: no
<quitte> I guess I'll start merging bbrezillon with yuq u-boot once I got it to fully boot. (and if i'm still not sick of it)
<bbrezillon> quitte: that, you couldn't guess, but I often leave my work on top of a branch, in this case you had to take the last 24 patches
<quitte> ...fully nand boot ...
<bbrezillon> quitte: but I would have told you that ;-)
rafaelMOD has joined #linux-sunxi
<quitte> bbrezillon: the next time i'm at the university i'll pull the 4Gb
F1skr has joined #linux-sunxi
<quitte> bbrezillon: how do you get those to stay on top? rebasing?
F1skr has quit [Read error: Connection reset by peer]
<bbrezillon> quitte: yep
F1skr has joined #linux-sunxi
<bbrezillon> quitte: git rebase --onto <the-branch-you-want-to-rebase-on>
jemk has joined #linux-sunxi
F1skr has quit [Read error: Connection reset by peer]
F1skr has joined #linux-sunxi
sehraf has quit [Read error: Connection reset by peer]
<quitte> i sure could use some handholding with git
<quitte> i want drivers/mtd/nand/nand_spl_mtd.c git checkout -p has way too much unnecessary stuff
blsd has quit [Remote host closed the connection]
<quitte> and i'm not sure how to solve all the conflicts I get when i try to cherry pick that commit
F1skr has quit [Read error: Connection reset by peer]
F1skr has joined #linux-sunxi
F1skr has quit [Read error: Connection reset by peer]
<bbrezillon> quitte: which branch are you currently based on, do you have any commit on top of this branch, and most importantly what do you want to do (rebase you work on yuq's branch or select part of yuq's works to apply it on your branch) ?
F1skr has joined #linux-sunxi
<quitte> bbrezillon: I'm on rgwan sunxi-current. I have a bunch of commits on top of that. I want to select parts of yuq's work
<quitte> right now i have a bunch of modifieds in git status i don't know how to handle
<quitte> how do i choose wether to use mine or theirs?
<quitte> also there is a change to .gitignore that I do not want to commmit even if it applies fine
<bbrezillon> quitte: first of all you'll have to commit or stash your changes
<quitte> yes. I did that. git status didn't havge anything to say before I started cherry picking
F1skr has quit [Read error: Connection reset by peer]
<bbrezillon> and then you got conflicts ?
<quitte> then i added the yuq remote
<quitte> no
<quitte> i have to check the bash history. but i ended up cherry picking that specific commit
<quitte> and now i have conflicts
<traeak> well i'll try to the boot cycling with the soc hot and see if it'll boot into android after it starts consistently crashing with 3.4.90 or whatever
F1skr has joined #linux-sunxi
F1skr has quit [Read error: Connection reset by peer]
<quitte> ok git log yuq/mtd. then git cherry-pick 5fe3e8
<bbrezillon> you ended with conflicts when cherry picking or when applying back the previously stashed changes
<quitte> when cherry picking
<quitte> add remote;check log;cherry pick
F1skr has joined #linux-sunxi
<quitte> that's what (as far as i know) i did effectively to get at the current point
<bbrezillon> okay, can you fix these conflicts ?
<quitte> no. how do i choose "mine" for a specific conflict?
<bbrezillon> I use git gui
<bbrezillon> to visually identify the conflicts
<quitte> my mouse is broken on the linux machine :/
<oliv3r> are there lime a20 with 1gbit ram?
<bbrezillon> and then manually fixed those conflitc
<oliv3r> gbyte
<bbrezillon> quitte: but you can do this with a simple editor too
notmart has quit [Quit: notmart terminated!]
<bbrezillon> quitte: just edit your conflicting files and fix the part where you see
<bbrezillon> >>>>>>>>>>>>>>>>
<bbrezillon> =============
<bbrezillon> <<<<<<<<<<<<<<<<<<<<<
<bbrezillon> or something like that :-)
<quitte> oh. never crossed my mind that the actual files right now might have changed already
F1skr has quit [Read error: Connection reset by peer]
<quitte> still - how do i simply say: keep my version of this file?
<bbrezillon> are you sure you want to keep your version
<bbrezillon> ?
<quitte> yes.
F1skr has joined #linux-sunxi
<quitte> it's .gitignore
<bbrezillon> then just git checkout <path-to-your-file>
<quitte> of course!
<bbrezillon> quitte: oh wait
<quitte> yes. doesn't work
<andoma> checkout --ours
<andoma> or
<andoma> checkout --theirs
<andoma> IIRC
<quitte> no
dll has joined #linux-sunxi
<dll> hi, i have a problem with a13 3.0.80 kernel. i get "BUG: scheduling while atomic: " while using i2c in an interrupt driven tty/serial driver. can anyone help me on this. ?
<bbrezillon> quitte: can you paste git diff result
<bbrezillon> ?
_massi has quit [Remote host closed the connection]
<quitte> pastebinit gives me a traceback if i try
<quitte> never mind.
<bbrezillon> quitte: what's your git version (git --version) ?
zeRez has joined #linux-sunxi
montjoie[home] has quit [Quit: leaving]
montjoie[home] has joined #linux-sunxi
<quitte> git checkout HEAD include/.gitignore seems to work
<quitte> 1.9.0
montjoie[home] has quit [Client Quit]
<bbrezillon> okay
montjoie[home] has joined #linux-sunxi
montjoie[home] has quit [Client Quit]
montjoie[home] has joined #linux-sunxi
<quitte> git is fun
montjoie[home] has quit [Client Quit]
montjoie[home] has joined #linux-sunxi
<quitte> I don't understandd the <<<<<< >>>>>> stuff. what are the reasonable changes i can make in there now
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
zeRez has quit []
notmart has joined #linux-sunxi
notmart has quit [Client Quit]
notmart has joined #linux-sunxi
zeRez has joined #linux-sunxi
<Turl> quitte: <<<< old code ==== new code >>>>
quitte_ has joined #linux-sunxi
quitte has quit [Read error: Connection reset by peer]
avsm has joined #linux-sunxi
mawe242 has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
<paulk-aldrin> problem: allwinner tablet with a windows-mobile-ripoff-ui doesn't ship with root
<mawe242> hi! has anybody managed to use the 12-bit SAR ADC of the A20 under linux?
zeRez has quit [Read error: Connection reset by peer]
<mawe242> is there a device driver for the ADC, or some detailed instructions as to how to use it? the official A20 datasheet is rather limited wrt the adc usage...
<libv> paulk-aldrin: and fel doesn't work either?
<paulk-aldrin> libv, I want root to run serial_noise
<paulk-aldrin> fel won't help much I suppose
zeRez_ has quit [Client Quit]
zeRez has joined #linux-sunxi
<libv> paulk-aldrin: just reboot a few times :)
<libv> or is it not too obvious which is which?
<paulk-aldrin> nah it's not
<paulk-aldrin> but yeah, I'll reboot
<paulk-aldrin> or maybe I find some way to spam dmesg from userspace
<libv> you'll reboot that thing often enough in its life ;)
quitte has joined #linux-sunxi
dack_ has joined #linux-sunxi
mawe242_ has joined #linux-sunxi
rafael_MOD has joined #linux-sunxi
crudo has joined #linux-sunxi
crudo is now known as Guest9961
AleRoss has joined #linux-sunxi
<AleRoss> Hi All :)
forcev has joined #linux-sunxi
xavia has joined #linux-sunxi
<mawe242_> i see there should be support for the LRADC on A10/A13, but is the A20 also supported? I can't find a sunxi adc driver in the sunxi-3.4 kernel for my cubieboard2....
libcg has quit [Remote host closed the connection]
quitte_ has quit [Ping timeout: 245 seconds]
ricardocrudo has quit [Ping timeout: 245 seconds]
dack has quit [Ping timeout: 245 seconds]
mawe242 has quit [Ping timeout: 245 seconds]
rafaelMOD has quit [Ping timeout: 245 seconds]
FunkyPenguin has quit [Ping timeout: 245 seconds]
Zboonet has quit [Remote host closed the connection]
diego71 has quit [Ping timeout: 240 seconds]
diego71 has joined #linux-sunxi
AleRoss has quit [Quit: Page closed]
bonbons has joined #linux-sunxi
souther has quit [Ping timeout: 272 seconds]
<Turl> mawe242_: can't you use the same driver? SUN4I_KEYBOARD does not seem to be limited to sun4/5i
souther has joined #linux-sunxi
dack_ has quit [Remote host closed the connection]
Guest9961 has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
akaizen has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
rafael_MOD has quit [Quit: Saindo]
rafaelMOD has joined #linux-sunxi
techn has joined #linux-sunxi
boycottg00gle has quit [Remote host closed the connection]
linkmauve1 has joined #linux-sunxi
hramrach has joined #linux-sunxi
<hramrach> hmm, so the thing seems to support exfat *and* SDXC
<hramrach> the thing being the manufacturer pre-installed android on inet86vs
FreezingAlt is now known as FreezingCold
bertrik has joined #linux-sunxi
<paulk-aldrin> oh freaking great, now this thing fried my UART adapter
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
<quitte> what are the respective sram sizes?
<quitte> especially a20
traeak has left #linux-sunxi [#linux-sunxi]
<quitte> hramrach: it's rather sad than special if sdxc is not supported.
avsm has quit [Quit: Leaving.]
diego_r has quit [Quit: Konversation terminated!]
<libv> paulk-aldrin: :(
<libv> paulk-aldrin: but been there, done that
<oliv3r> damn cheap uarts!
amitk has quit [Quit: leaving]
<paulk-aldrin> well, it's not like I don't have a few other options for UART, but still, it sucks
<libv> paulk-aldrin: after i killed my first one, i ordered a pair, but i probably should've ordered 5
<paulk-aldrin> lol
<mawe242_> Turl: I probably could, you're right. But i just realized what the "LR" in LRADC means... low resolution (6 bit). not very useful for me.
<mawe242_> Turl: but the touchpad interface has a 12-bit ADC built in, and according to the datasheet it also support "auxiliary" ADC conversions, differential and single ended. sounds great, I will try to hack the touchpad driver.
Guest17052 is now known as w00tc0d3
FR^2 has quit [Quit: Connection reset by peer]
w00tc0d3 is now known as Guest20054
Guest20054 has joined #linux-sunxi
Guest20054 has quit [Changing host]
Guest20054 has quit [Changing host]
Guest20054 has joined #linux-sunxi
Guest20054 is now known as netchip
souther has quit [Ping timeout: 260 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<mnemoc> libv: thank you for the sanity checks on fexc... that was on my TODO since the begining
<libv> mnemoc: np, after the idiocy with jannf yesterday, it was just something that needed to be done
notmart has quit [Quit: notmart terminated!]
souther has joined #linux-sunxi
<rafaelMOD> I am getting confused with all this FEX and DTS differences. Does the linux-sunxi 3.4.90-rc1 works only with FEX (no dts on arch/arm/boot/dts for sunXi)? And does the linux-sunxi in the mainline works only with DTS?
<bonbons> rafaelMOD: yes, that's the way it is
souther has quit [Ping timeout: 240 seconds]
<rafaelMOD> So now there are two development fronts, with different drivers and patches?
souther has joined #linux-sunxi
<rafaelMOD> And the drivers and patches are exclusive for FEX or for DTS? The device driver implementation is totally different for DTS and for FEX?
patap has joined #linux-sunxi
<patap> rafaelMOD: I'd say more like patches for mainline kernel and time-to-time fixes for 3.4
<mnemoc> talking about that... are there (important) outstanding fixes for 3.4?
<mnemoc> i'm lost on a see of 10k+ unread mails :\
<patap> ouch
<jemk> mnemoc: not important, but:
<jemk> mnemoc: that is what I remember, maybe there are more
<mnemoc> jemk: thanks. i'll handle them now
souther has quit [Ping timeout: 260 seconds]
<mnemoc> jemk: do you know if people has tried the current stage/sunxi-3.4? can v3.4.102-r1 "graduate" from stage?
mawe242_ has quit [Ping timeout: 240 seconds]
rz2k has joined #linux-sunxi
quitte has quit [Read error: Connection reset by peer]
souther has joined #linux-sunxi
dll has quit [Quit: Page closed]
quitte has joined #linux-sunxi
<jemk> mnemoc: no, i don't know, and i didn't try .102 myself
<libv> mainliners: is there any reason for this? compatible = "allwinner,sun5i-a10s-i2c", "allwinner,sun4i-a10-i2c";
<rafaelMOD> What are the big driver coding differences for FEX and DTS? DTS doesn't uses functions like "script_parser_fetch(...)"? And can I use functions like "gpio_set_value(...)" with FEX? Any good gide on that?
<mnemoc> mainline takes EVERYTHING from the DTS. legacy takes the enable/disable and the pinmuxes from FEX only
FR^2 has joined #linux-sunxi
dack has joined #linux-sunxi
<mnemoc> FEX drivers check on init if the thing is enabled, while DTS works the other way around. the kernel knows something is present somewhere specificly and probes for drivers
<mnemoc> and FEX drivers are mostly standalone while mainline drivers use common frameworks
<rafaelMOD> I'm starting to understand the differences, thanks. But will legacy 3.4 ever evolve to 3.5 and so? Or will it be deprecated?
<mnemoc> it's stuck there
<mnemoc> there was the idea of making a sunxi-3.10 or 3.14 stable branch, backporting newer things... but lack of man power have not made it possible
<mnemoc> this stable branch was also intended to get magic glue to be able to drop in the legacy drivers not yet supported by mainline
<mnemoc> but well... it seems it's not going to happen
<rafaelMOD> All manpower is now on mainline?
<mnemoc> mostly
souther has quit [Ping timeout: 272 seconds]
<Turl> libv: eh..
<libv> Turl: it just uselessly diverges dtses
<Turl> libv: maybe the sun5i IP has some new feature?
<libv> a grep for that string brings up nothing
<Turl> indeed, nothing seems to use the compatible to this day
<Turl> but that's future-proofing
<libv> oh, the second compatible string is used
<Turl> if it weren't it wouldn't work :p
<libv> it's not as if dtses of yesterday will work with kernels of tomorrow
<libv> so that rules out that future-proofing
<Turl> libv: that's the ultimate plan
<libv> Turl: which is never going to happen
<libv> secondly...
<libv> doesn't the second compatible string rule out the first?
<Turl> libv: marvell guys seem to be executing it successfully so far
<libv> it makes the first string totally irrelevant
<mripard_> libv: none besides the i2c maintainer being picky about it
<libv> mripard_: :((((
<Turl> libv: it's compatible = most-specific, less-specific, even-less-specific, etc
<rafaelMOD> mnemoc: The functions for device driver development in FEX and DTS are that different? Like, can I call i2c_add_driver() in a module in FEX?
<libv> Turl: is that ordering codified as such today?
<mripard_> his point was that if there ever was a bug or some behaviour difference in the sun5i IP, we wouldn't have to update the DT
<Turl> libv: pretty sure it is
<libv> Turl: ok
<Turl> libv: you can even see it being used on the machine compatible
<Turl> compatible = board, soc
<mripard_> and since like Turl is saying, DT backward-compatibility is the hype du jour, well....
<libv> mripard_: people are kidding themselves
<mripard_> even if we're not close to that on sunxi.
<libv> mripard_: they should just own up to the fact that that will never happen
<libv> well, some people know, but are still marketing it differently
<libv> as otherwise people would or would've been even more against dt
<mripard_> libv: you're preaching to the choir
<libv> :)
forcev has quit [Ping timeout: 260 seconds]
<mripard_> it's something we should tend to, but it's not something that should be enforced as an ABI stability imo
<mripard_> if we ever have a good reason to change it, we should be able to...
<Turl> it should be ABIish when you actually ship it
<mripard_> anyway... we've never really been bothered by that, so I'm not really worrying too much about it for now.
<Turl> and even then, you could change it up to some extent
<libv> Turl: drivers should try to gracefully catch that though
<libv> but again, in an ideal world
<mripard_> besides whenever there's a maintainer meetup and this issue in brought to the table again...
<mripard_> Turl: as long as it's not set in a ROM, you can ship it however you want
<mripard_> just like a bootloader.
souther has joined #linux-sunxi
<libv> mripard_: btw, boo for ahb_hdmi0 and ahb_de_fe/ahb_de_be/ahb_lcd
<libv> there really was no reason for naming these things differently
<mripard_> that can definitely change
<libv> but then, i also have no real reason to check these names from u-boot apart from pointing out that something might be conceptually awry
<mripard_> if you come up with a better name that makes your life easier, do so
<libv> yeah, now that hansg catched the second changes, i will
<libv> for hdmi/hdmi0 i wasn;t bothered enough yet
<libv> s/catched/caught/
<Turl> libv: that check is completely redundant :)
<Turl> if you see it's compatible already
<libv> Turl: well, not entirely, but that's a few lines up in this irc log
quitte has quit [Read error: Connection reset by peer]
<Turl> libv: you already know the clocks exist because you turned the IP on, you're just adding code to break in case you rename the stuff in the future or anything like that
<Turl> like it happened with hans
hramrach has quit [Remote host closed the connection]
<libv> Turl: v3 was not going to return anymore
quitte has joined #linux-sunxi
<libv> i forgot to remove the returns for v2
<libv> as i had planned on removing those already
<Turl> so you'll just print a warning?
<libv> so i'd just complain
<libv> yup
<Turl> that's better but still pretty pointless imo :)
souther has quit [Ping timeout: 272 seconds]
<libv> no, i believe that <&label bit> is pretty wrong still, and that that will change in near or slightly further future. i just want to make this line in the sand
<libv> but for simplefb, i am already complaining about, but not bailing on clocks i cannot resolve in the hope that things work out anyway
<libv> in the kernel code that is
<libv> that does make my returns in uboot code seem just as assymetric as the clock handling is :)
<Turl> libv: if it changes you'll need to fix the hardcoded bits in uboot anyway
deasy has joined #linux-sunxi
hramrach has joined #linux-sunxi
FunkyPenguin has joined #linux-sunxi
Faisal has joined #linux-sunxi
patap has quit [Quit: Page closed]
<paulk-aldrin> wtf, there is 36V on the board…
<Turl> you mean 3.6?
mawe242_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 246 seconds]
<rafaelMOD> The functions for device driver development in FEX and DTS are totally different? Any recommended doc on that? I need to use and i2c inside an asoc driver in 3.4.90-r1 FEX
Nyuutwo has joined #linux-sunxi
<paulk-aldrin> no, it really measures at 36V!
ninolein has joined #linux-sunxi
<paulk-aldrin> and makes nice sparks when shorted to ground
<Turl> paulk-aldrin: o.O what board?
<paulk-aldrin> Ampe A76
<paulk-aldrin> on test points
<paulk-aldrin> no wonder why it fried my UART
<Turl> rafaelMOD: fex is more like the "old school" way, with platform devices
Skaag has quit [Ping timeout: 240 seconds]
<Turl> rafaelMOD: have a look at the touchscreen drivers with fex support to get an idea of how it works
<Turl> most of them are i2c
dack has quit [Remote host closed the connection]
<rafaelMOD> Thanks!
<rafaelMOD> BTW, I am developing a driver for Cirrus Codec CS4245 in 3.4.90-r1
<rafaelMOD> And I want it to have alsa controls so I can work with alsa mixer.
<rafaelMOD> How is the dma and i2s drivers in the mainline for sun7i? Any WIP?
<paulk-aldrin> have you ever seen board with no UART pad?
<paulk-aldrin> s/board/tablets/
<paulk-aldrin> it's starting to look that way
<Turl> rafaelMOD: DMA is being reviewed, and Jon is working on I2S, he got it more or less working the other day
<Turl> paulk-aldrin: I think wens' was that way
mawe242_ has quit [Ping timeout: 260 seconds]
yann_s has quit [Quit: ZNC -]
quitte has quit [Read error: Connection reset by peer]
quitte has joined #linux-sunxi
Nyuutwo has quit [Remote host closed the connection]
<rafaelMOD> Turl: Did Jon publish the code for I2S?
Nyuutwo has joined #linux-sunxi
<Turl> rafaelMOD: not yet, he just got it working a handful of days ago
<rafaelMOD> Ok, i'll try to reach him for the code, do you know his nickname in IRC?
<Turl> rafaelMOD: afaik he's not on irc
<Turl> but you can write him an email, he participates in the linux-sunxi list quite a bit too
paulk-aldrin has quit [Quit: Ex-Chat]
Skaag has joined #linux-sunxi
<rafaelMOD> Thanks i will try to reach him.
jemk has quit [Quit: leaving]
bertrik has quit [Remote host closed the connection]
petr has quit [Ping timeout: 272 seconds]
petr has joined #linux-sunxi
souther has joined #linux-sunxi
FR^2 has quit [Quit: Leaving]
<quitte> bbrezillon: I did it.
akaizen has quit [Ping timeout: 240 seconds]
akaizen has joined #linux-sunxi
quitte has quit [Read error: Connection reset by peer]
quitte has joined #linux-sunxi
bonbons has quit [Quit: Leaving]
F1skr has quit [Quit: WeeChat 0.4.3]
pwhalen has quit [Ping timeout: 240 seconds]
Black_Horseman has joined #linux-sunxi
pwhalen has joined #linux-sunxi
<quitte> full nand boot on cubietruck with only free software:
<rz2k> quitte: nice
<rz2k> quitte: you've adopted bbrezillon sources? I was thinking about doing that but I dont have enough experience with u-boot's mtd
<quitte> no. that's yuq's as rgwan merged it with sunxi uboot
<quitte> cherrypicked that into mainline ...
<quitte> the kernel is bbrezillon, however.
<quitte> I'm fairly sure I can clean it up well enough to put on github tomorrow
<quitte> basically all i have to do is give myself fair credit ;)
<rz2k> dont forget to write manual about how to write an spl from bbrezillon's driver
<rz2k> since it has different OOB and etc.
<quitte> you mean flashing the image? that's just a normal mtd write from within linux.
<quitte> bbrezillon took care of the special randomization of the spl partition
<rz2k> I ran sunxi-nand-pre-v4 today for couple hours with couple of QEMU VMs, stored rootfs images on UBIFS. it survived reboots and load from QEMU.
<rz2k> yep iirc flashing the image from yuq's driver was a mess back in the days
<rz2k> I've tried to do that but failed (don't remember why, honestly)
<quitte> fl_spl=nand erase.part spl && nand write.1k ${loadaddr} 0 ${filesize} && nand write.1k ${loadaddr} 0x10000 ${filesize}
<quitte> that's part of rgwan's patches. with something like that in the environment it's easy enough
<rz2k> neat, how is bootup speed now, running everything from NAND and on mainline?
<rz2k> I expect it to be nothing more than 4-5 seconds running systemd and 0 delays in u-boot
<quitte> it's limited mostly by the bootwait env variable
<quitte> and the other wait in openwrt for the rescue mode
Skaag has quit [Ping timeout: 255 seconds]
<rz2k> hope you'll post this to our mailing list, there were guys who were insterested in full nand boot