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
naobsd has quit [Quit: Page closed]
VargaD has quit [Ping timeout: 245 seconds]
libv has quit [Read error: Connection reset by peer]
libv has joined #linux-sunxi
VargaD has joined #linux-sunxi
Andy-D has joined #linux-sunxi
Akagi201_ has quit [Ping timeout: 255 seconds]
ricardocrudo has joined #linux-sunxi
pwhalen has quit [Ping timeout: 255 seconds]
pwhalen has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
Akagi201 has joined #linux-sunxi
popolon has quit [Quit: Quitte]
egbert has joined #linux-sunxi
egbert_ has quit [Ping timeout: 245 seconds]
ganbold_ has joined #linux-sunxi
nabblet has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
ricardocrudo has quit [Ping timeout: 240 seconds]
nabblet has quit [Quit: leaving]
Andy-D has joined #linux-sunxi
<wens> libv: i haven't, as we don't have exact a23 dram code to match
<wens> i just assume it's similar to sun6i
wingrime has joined #linux-sunxi
<libv> is this due to the lacking u-boot code?
<wens> lacking boot0
<wens> allwinner's u-boot doesn't handle dram
<libv> sounds like something our engaged partner should provide us
<libv> eva wu just posted on linkedin: "I have noticed quite a lots of complaints about the A80 OptimusBoard provided by partner Merrii. I have talked to Merrii and convinced them to give their best discount. Now you can own an A80 OptimusBoard for 169USD. See more details in the attached poster. "
Andy-D has quit [Ping timeout: 245 seconds]
<wens> Huh?
Andy-D has joined #linux-sunxi
nabblet has joined #linux-sunxi
hipboi has quit [Ping timeout: 250 seconds]
<wens> yeah, price on taobao dropped from 1999 rmb to 999 rmb (roughly 165 usd with shipping)
<wens> so that's about the price of an a80 tablet
<libv> so halved.
<libv> discount my arse :p
<wens> price drop is more accurate
hipboi has joined #linux-sunxi
<wens> wonder if it helps
Andy-D has quit [Ping timeout: 245 seconds]
Andy-D has joined #linux-sunxi
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
<libv> wens: did we get boot0 code for a31 or is the dram info in the datasheet?
pwhalen has quit [Ping timeout: 240 seconds]
<wens> libv: yes we have boot0/boot1 code for a31, but no, dram info isn't in the datasheet
mmarker has quit [Remote host closed the connection]
pwhalen has joined #linux-sunxi
nabblet has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
montjoie[home] has quit [Ping timeout: 244 seconds]
montjoie[home] has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime has quit [Read error: Connection reset by peer]
dlan has quit [Ping timeout: 255 seconds]
kuldeepdhaka has joined #linux-sunxi
dlan has joined #linux-sunxi
dlan has quit [Changing host]
dlan has joined #linux-sunxi
PulkoMandy has joined #linux-sunxi
wingrime1 has quit [Read error: Connection reset by peer]
Faisal has quit [Read error: Connection reset by peer]
Faisal has joined #linux-sunxi
<akaizen_> how can I upload to I have most of A31 files downloaded
akaizen_ is now known as akaizen
<akaizen> oh looks like they are already up there
HeHoPMaJIeH has joined #linux-sunxi
dudepdx has joined #linux-sunxi
Faisal has quit [Quit: No Ping reply in 180 seconds.]
Faisal has joined #linux-sunxi
Quarx has joined #linux-sunxi
_massi has joined #linux-sunxi
<oliv3r> wow
<oliv3r> i just received an exciting e-mail from eva. we have got a technical contact officially now from allwinner, and she asked for a list of the main contributors to keep informed of Allwinner news and to also get in touch with the technical contact.
<oliv3r> So if anybody objects to receiving email from AW, let me know and i'll try to get you removed from their list.
lkcl has quit [Ping timeout: 272 seconds]
<wens> libv: ^
FreezingCold has joined #linux-sunxi
kuldeepdhaka has quit [Ping timeout: 250 seconds]
<wens> wonder what Simos Xenitellis worked on
lkcl has joined #linux-sunxi
patap has joined #linux-sunxi
mawe242 has joined #linux-sunxi
<patap> good starting point for contributors list
lkcl has quit [Ping timeout: 250 seconds]
Zboonet has joined #linux-sunxi
jemk has joined #linux-sunxi
<wens> mripard_: you can add 3.16 to your talk at elc europe :p
<mripard_> wens: and 3.17 by then :)
<mripard_> but yeah, it's the plan
<mripard_> especially since in 3.17, you were the most active dev ;)
<mawe242> does anybody have some pointers for me on how to configure the pmu_para in script.fex for a 6600 mAh LiPo battery?
<wens> mripard_: nah, it's mostly based on existing drivers, just a ton of DT patches :)
<longsleep> I just read about elc europe - you guys think its worth to go there sunxi wise ?
<wens> i'm waiting for fosdem next year
<wens> already made travel plans
notmart has joined #linux-sunxi
_massi has quit [Remote host closed the connection]
<ccaione> yay for fosdem
_massi has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 246 seconds]
Zboonet has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 4.0.4 Insomnia]
lkcl has joined #linux-sunxi
<oliv3r> patap: nice
<oliv3r> mripard_: hi!
dlan has quit [Ping timeout: 260 seconds]
<oliv3r> wens: you coming to fosdem?
<oliv3r> i'm planning on having a booth this year (for my current employer)
dlan has joined #linux-sunxi
* andoma 's going this time as well
<wens> oliv3r: if nothing else happens, yes i'm definitely going :)
<oliv3r> :D
<oliv3r> no sunxi talk i think though, unless we have something interesting to talk about
<oliv3r> maybe alightening talk? :)
<wens> maybe libv will talk about the hurdles he went through for u-boot/simplefb/kms
<mripard_> oliv3r: hi
<oliv3r> mripard_: i got A33 hardware :D
<mripard_> wens: well, still, it's good to see that others than Emilio, Hans and I are picking up the work :)
<mripard_> yeah, I saw that
<mripard_> good :)
<oliv3r> hopefully i'll start to have some time again soon to hack on things again more
<mripard_> you just have to start coding now ! :)
<oliv3r> but $work is keeping me so busy :(
<oliv3r> i do have some patches ready again, but for 3.4 atm :(
<oliv3r> you did catch wind that we are using a a20 lime in our product?
<mripard_> yeah, I guess 3.4 is a reasonnable target
<mripard_> A31/A23/A33 support is pretty much non-existent
<mripard_> while I expect the A33 support to be as smooth as the A23 in mainline
<oliv3r> yeah
<mripard_> I knew that you were using *a* lime
<oliv3r> A33 is just a quad core a23
<mripard_> but somehow, I thought it was the A10
<oliv3r> yeah we first where going for the A10, but A20 is nearly same price
<oliv3r> so going to use that instead
<mripard_> ok
<oliv3r> also, we probably will switch to a 3.15 'hybrid' kernel, as i have little faith in the 3.4
<oliv3r> but we will need things like flash
<oliv3r> but that won't happen until next year, deadlines force us to 3.4 for now
<oliv3r> and i'm in talks with eva again, so that's exciting too
<mripard_> yep, it is
<wens> hmm, that firmware upgrade path (3.4 -> 3.15) is a bit frightening
<mripard_> wens: I agree..
<mripard_> especially since most of the upgrade path would involve the bootloader.
<wens> i assume you're keeping/porting libnand
<wens> otherwise nand support in u-boot is non-existent atm
popolon has joined #linux-sunxi
nedko has joined #linux-sunxi
dudepdx has quit [Ping timeout: 250 seconds]
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 240 seconds]
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 260 seconds]
quitte_ has joined #linux-sunxi
quitte has quit [Ping timeout: 245 seconds]
Nyuutwo has quit [Remote host closed the connection]
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
hipboi has quit [Ping timeout: 272 seconds]
hipboi has joined #linux-sunxi
<oliv3r> wens: exactly, step one is port libnand to our u-boot
<oliv3r> step two, (later) swap kernels
<oliv3r> so i'll be using the current u-boot with nand support, if that can all work that is
<oliv3r> i do NOT want to use boot0
<oliv3r> i rather use sd cards :p
<oliv3r> and upgrade path, i'm planning at this time, to have u-boot be able to boot 2 images, based on uEnv setting or the like
<oliv3r> not sure how to fix that perfectly yet
<oliv3r> replace one image (rootfs +initrd)
<oliv3r> if it boots, replace the other too
<oliv3r> something like that
<oliv3r> i know i'll be stuck with libnand for a while, but mtd is just not far enough yet, it's the only missing piece
<oliv3r> and the SPI driver i'd much rather use maxime's mainline version
<quitte_> oliv3r: u-boot spl works good enough to start u-boot even without read-retry
<oliv3r> quitte_: which u-boot version do you mean?
<quitte_> mainline patched with rgwan/yuq
<oliv3r> ah ok so with the yuq patch
<oliv3r> quitte_: my problem is, i have not enough faith yet in mtd to be at production quality
<oliv3r> i have little faith in 3.4 too :p
<quitte_> you don't need mtd u-boot. you can second part load any uboot
<quitte_> but if you need production quality - don't use it. it will occassionally fail to load uboot due to ecc errors
<oliv3r> that's my issue atm
<oliv3r> so i have to use libnand for now
<longsleep> oliv3r: 3.4 is horrible - mtd looks fine in 3.17 for me for now
<longsleep> oliv3r: staring to work on booting from it now :)
<oliv3r> longsleep: 3.4 IS horrible, but would you put mtd on thousands of headless devices today?
<quitte_> longsleep: I'm not too sure. I have lots of oddness with flashing ubi images. not sure if I'm supposed to do it differently ...
<longsleep> btw - is it normal that my nand has 424 bad blocks (2MB each, 8GB nand)
<quitte_> longsleep: no. I have about 5
<longsleep> quitte_: ok - this NAND came from the factory like that ..
<quitte_> longsleep: you need to do an erase that ignores the badblocks
<longsleep> quitte_: what oddness do you mean?
<longsleep> quitte_: i tried that - but then i get i/o errors, so the blocks seem really to be bad?
<quitte_> longsleep: it only works occassionally to ubiattach afterwards. even if i both mtd erase and tzhen use ubiformat to flash the image
<quitte_> longsleep: i don't know. I sweeped mine from u-boot. so now the factory badblock information is probably gone
<longsleep> quitte_: mhm i do not have this problem, worked every single time - did it 50 times or so now
<longsleep> quitte_: what kernel do you use ? i am on latest mainline head plus NAND patches.
<quitte_> my image contains a squashfs volume and a autoresize ubi volume
<quitte_> longsleep: 3.16.1, still
<longsleep> quitte_: ok and do you have the latest nand patches from this week?
<quitte_> but the nand patches should be pretty close to current
<quitte_> it was hours after bbrezillon sent me the patches that he released V4
<longsleep> mhm ok
<longsleep> did you see he has prepared v5 with two new patches? Maybe these help in your case - i got them at least.
<quitte_> I'll look into upgrading once I got overlayfs working the earliest.
<longsleep> quitte_: thats the kernel i use
dudepdx has joined #linux-sunxi
patap has quit [Ping timeout: 246 seconds]
dudepdx has quit [Ping timeout: 246 seconds]
PlkMndy has joined #linux-sunxi
PulkoMandy has quit [Read error: Connection reset by peer]
PlkMndy is now known as PulkoMandy
lkcl has quit [Ping timeout: 260 seconds]
<libv> aha, so yes, "recently" was in the future.
<wens> i suppose "Ben" on cnxsoft is allwinner
<wens> heh, took a quick look at u-boot cfb defines, they look archaic
<libv> wens: yeah, they are, and it's pretty vga card oriented
<oliv3r> btw, does android 4.4 do audio playback during boot?
<oliv3r> or did aw do that in their u-boot, i haven't checked yet
<libv> but lcd feels quite wrong too, and i actually thought it was only there for splash
T0mW has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
dudepdx has joined #linux-sunxi
lkcl has joined #linux-sunxi
<oliv3r> WoW
<Gerwin_J> price drop of A80 optimusboard
dudepdx has quit [Ping timeout: 260 seconds]
dudepdx has joined #linux-sunxi
<T0mW> now, if only it was documented better (A80)
dudepdx has quit [Ping timeout: 255 seconds]
<Gerwin_J> libv: isee
diego_r has joined #linux-sunxi
<Gerwin_J> only i still don't get A80 SDK... only a A80 introduction brief with some GPIO pin out
<T0mW> I just ordered one the SunLinx dev kits from taobao a few days ago, still waiting for the seller to ship it.
Black_Horseman has quit [Remote host closed the connection]
dudepdx has joined #linux-sunxi
<wens> that pro a80 board looks large
dudepdx has quit [Read error: Connection reset by peer]
<libv> oliv3r: your book is on that weixin link Gerwin_J just posted
<wens> oliv3r: oh look
<oliv3r> but i have a phone conference tomorrow about the title :p
nedko has quit [Quit: kernel panic]
kuldeepdhaka has joined #linux-sunxi
<bbrezillon> quitte_: can you paste the errors you're seing when ubiattach fails .
<bbrezillon> ?
kuldeepdhaka has quit [Max SendQ exceeded]
<bbrezillon> longsleep: 424 BB => that's a lot for a fresh NAND. Can you try to apply this patch and then launch a flash_erase on you mtd partition ?
lkcl has quit [Ping timeout: 250 seconds]
<bbrezillon> longsleep: you'll have to remove the on BBT support (remove the DT property asking for on-flash-bbt), otherwise it will keep still consider these blocks as bad
<oliv3r> they should have stolen the image from packt
kuldeepdhaka has joined #linux-sunxi
<bbrezillon> longsleep: after erasing the NAND you should revert the patch and re-enable the on flash BBT
anthony_emtrion has joined #linux-sunxi
kuldeepdhaka has quit [Max SendQ exceeded]
kuldeepdhaka has joined #linux-sunxi
deasy has joined #linux-sunxi
deasy has quit [Remote host closed the connection]
dack has joined #linux-sunxi
lkcl has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
miup has quit [Quit: WeeChat 0.4.3]
lkcl has quit [Ping timeout: 255 seconds]
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 255 seconds]
dudepdx has joined #linux-sunxi
<libv> crap. my eyerolling at jsmirls DIV_ROUND has caused me to miss a semitime g1 on ebay which i had been oggling for a week
<libv> by seconds.
<libv> went for 2.01EUR
<oliv3r> ohh wow
<oliv3r> what's a semitime g1?
<libv> would've given me an A10s quickly (since this aliexpress tosser still hasn't shipped the mele a210 i ordered, which will then take another 2 weeks), and would've finally documented this a10s based mk805
<libv> oliv3r: you can ask iirc, hansg
<libv> which means that you cannot ask the wiki.
<oliv3r> i bought a jesrun hdmi 'stick' which is a10s
<oliv3r> from dx
<libv> oliv3r: NDH!
<oliv3r> i know!
<oliv3r> i allready took pictures :)
<oliv3r> mripard_: do you have a video to go with your mainlining out of tree socs slides?
afaerber has joined #linux-sunxi
hansg has joined #linux-sunxi
* libv is such a tosser.
dudepdx has quit [Ping timeout: 255 seconds]
<longsleep> bbrezillon: Ok - i try this - with DT you mean the device tree and i need to modify this and then recompile my kernel right?
astr has quit [Ping timeout: 250 seconds]
<bbrezillon> longsleep: yes I mean device tree, and yes you'll need to recompile your kernel and your dtb (which is automatically done if you run make without any specific target)
<longsleep> bbrezillon: ok just wanted to make sure - i am still new to the names of the stuff involved
<bbrezillon> longsleep: np
<longsleep> bbrezillon: so i am using arch/arm/boot/dts/sun7i-a20-cubietruck.dts - which which settings define the on flash bbt? nand-ecc-mode = "hw" ?
ddc has joined #linux-sunxi
<bbrezillon> longsleep: oh, you didn't enable the on flash BBT, perfect
<bbrezillon> then you just have to recompile you kernel with my patch applied
<longsleep> bbrezillon: ok :D
<longsleep> bbrezillon: I need to learn about bbt settings in dt now though :)
dudepdx has joined #linux-sunxi
<bbrezillon> longsleep: sorry, I don't remember who did what: everybody is testing the NAND driver at the same time (which is great BTW)
ddc has quit [Remote host closed the connection]
<bbrezillon> longsleep: on flash BBT (Bad Block Table) table will (as it names implies ;-)) store the list of detected Bad in a NAND erase block
astr has joined #linux-sunxi
<bbrezillon> longsleep: this is used to avoid scanning the whole flash chip for NAND detection at each boot, and thus speed up boot
<bbrezillon> longsleep: for NAND Bad Block detection
<anthony_emtrion> bbrezillon: and for info, when is it triggered/updated this BBT ?
dudepdx has quit [Ping timeout: 255 seconds]
<longsleep> bbrezillon: I saw some a kernel flag for something like this
<bbrezillon> longsleep: yep, this DT property just tell the NAND driver to set this flag ;-)
<oliv3r> hmm, my framebuffer doesn't seem to be working. i did compile sunxi_disp into the kernel rather then making it a module
<bbrezillon> anthony_emtrion: hey, you're on the sunxi chan too
<anthony_emtrion> bbrezillon: I'm everywhere interresting ;)
<bbrezillon> anthony_emtrion: every time a BB is detected
<anthony_emtrion> bbrezillon: I follow Free Electron stuff since a long time (learnt a lot with the slides...)
<anthony_emtrion> bbrezillon: and sunxi is something Free Electron work on and give info
<anthony_emtrion> bbrezillon: albeit I'm not that keen on Chinese SoC
<anthony_emtrion> bbrezillon: I might test one day with a Olimex board. the futur A31 for example.
<anthony_emtrion> bbrezillon: thanks for the reply. a BB is detested when the driver does not succeed on write a Block ?
<bbrezillon> anthony_emtrion: it's always written as bad when it does not succed at erasing a block
<bbrezillon> anthony_emtrion: I'm not sure about writing a single page in a block
<Turl> oliv3r: wow, cool news. Count me in :)
Quarx has joined #linux-sunxi
<bbrezillon> anthony_emtrion: and when there's too many bitflips (i.e. above the bitflips_threshold) some wear leveling layers (like UBI) "torture" the block to test its reliability
<anthony_emtrion> bbrezillon: ok so when it can't erase a block, it writes as bad in the BBT.
<bbrezillon> anthony_emtrion: though I'm not sure what triggers the torture test (you should ask that on the #mtd chan ;-))
<anthony_emtrion> bbrezillon: it seems there is a chan for every question :D
<anthony_emtrion> bbrezillon: funny because I'm implementing something for High Reliability block driver called DataLight Reliance Nitro
<oliv3r> Turl: any pointers to how to get the framebuffer to work
<oliv3r> my custom compiled kernel doesn't work, fedora kernel does :)
<Turl> oliv3r: eh, 3.4?
ddc has joined #linux-sunxi
<Turl> make sure disp/lcd/hdmi are all =y
<oliv3r> well this would be the boot console
<oliv3r> oh er yeah
<oliv3r> i did, any way to check that from a running kernel, to be sure?
dudepdx has joined #linux-sunxi
<oliv3r> the kernel seems to like it all; Xorg is running and i can run guvcview
<oliv3r> the monitor simply remains blank
<ddc> bbrezilon : mtd channel In which server. There are a few but they. seems to be dead
<oliv3r> nvm, wrong cable :p
<oliv3r> well the hdmi->, displayport cable appearanlt ydidn't work
<bbrezillon> ddc: on oftc
quitte has joined #linux-sunxi
lkcl has joined #linux-sunxi
<bbrezillon> ddc:
<Turl> oliv3r: heh :)
<oliv3r> but 'before' it worked
dudepdx has quit [Ping timeout: 246 seconds]
<oliv3r> i think .. now i doubt myself
<oliv3r> yay, console
quitte_ has quit [Ping timeout: 250 seconds]
ddc has quit [Ping timeout: 272 seconds]
ddc has joined #linux-sunxi
dudepdx has joined #linux-sunxi
mawe242 has quit [Quit: Leaving]
ddc has quit [Ping timeout: 272 seconds]
hansg has quit [Remote host closed the connection]
dudepdx has quit [Ping timeout: 255 seconds]
<anthony_emtrion> Sooo..... I hope A33 is soon well supported in mainline ;)
<longsleep> bbrezillon: compiling the kernel with your erase patch now
<Turl> sigh :p "and has a Mali-400MP2 GPU, which is capable of rendering high-definition video."
<Turl> (also yay, mali)
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 240 seconds]
<wens> anthony_emtrion: mainline won't have display that soon
makepi has joined #linux-sunxi
<anthony_emtrion> wens: Sure I understand why.
dudepdx has joined #linux-sunxi
thedude has joined #linux-sunxi
<mripard_> oliv3r: not yet
<mripard_> anthony_emtrion: we don't have any hardware at the moment, so feel free to contribute :)
dudepdx has quit [Ping timeout: 255 seconds]
<anthony_emtrion> mripard_: As soon as a cheap board is out why not ! :)
<longsleep> bbrezillon: With your patch enabled flash_eraseall -N /dev/mtd2 ran without errors.
<longsleep> bbrezillon: But blocks are still marked as bad.
<anthony_emtrion> mripard_: I'll be there : Tuesday, October 14 • 15:30 - 16:20
<anthony_emtrion> mripard_: ;) I'll need it !
<bbrezillon> longsleep: you have to reboot
<mripard_> you'll need it for what?
<longsleep> bbrezillon: oh of course sorry - let me try
<bbrezillon> longsleep: unless you already did :-)
<anthony_emtrion> to bring up the A33 !
<longsleep> bbrezillon: well it did not complain about a ton of bad blocks on boot now - looks promising
thedude has quit [Ping timeout: 240 seconds]
<longsleep> bbrezillon: yeah now i can erase without -N and no error
<bbrezillon> longsleep: now revert my patch
<bbrezillon> recompile and reboot
<longsleep> bbrezillon: ok doing so now
<bbrezillon> longsleep: it should work fine now
<bbrezillon> longsleep: and you can add on flash BBT support if you want to speed up your boot ;-)
<longsleep> bbrezillon: so how do we avoid this issue without two different kernels?
<bbrezillon> longsleep: you mean one with libnand and one with my driver ?
<longsleep> bbrezillon: No i mean only with your driver. But a pre ininialized NAND coming from factory.
<bbrezillon> longsleep: that should work fine with an fresh NAND
<oliv3r> mripard_: nice slides though :)
<bbrezillon> longsleep: I guess your device was already pre installed with an android version on it
<bbrezillon> longsleep: right ?
<longsleep> bbrezillon: yes exactly - and i flashed a lubuntu to it for testing too
<bbrezillon> longsleep: that's the reason
<longsleep> bbrezillon: but isnt that the case with all boxes one can normally buy as consumer?
<bbrezillon> longsleep: both the kernel used for ubuntu and android are using libnand
<oliv3r> mripard_: nand wasn't really REd, libnand was given to us in the past. just not updated versions :( (slide 22/32) the only RE work being done is VPU and some memory stuff I suppose sort of.
<bbrezillon> longsleep: and libnand doesn't care about BB markers stored in the OOB area
<longsleep> longsleep: Yeah - but what i meant is that one might always have this problem when updating to mainline with your drivers from pre installed libnand installation right?
<bbrezillon> longsleep: yep
<mripard_> oliv3r: ack. i'll change it for next time :)
<bbrezillon> longsleep: I don't know it would work (and don't know much about libnand), but here might be a possible solution:
<longsleep> bbrezillon: So that is essentially bad yes. I would consider this as a workaround but there should be an automatic solution or something easier in user space.
ddc has joined #linux-sunxi
<bbrezillon> longsleep: boot on an MMC card with a libnand kernel, then ask for a full erasure of the NAND device
<oliv3r> mripard_: you even put my name on the list :D
<oliv3r> mripard_: i'll put all those names onto the list for eva, not sure about stefan, he kinda seems to have dissapeared
<oliv3r> and i'll look at our ML for a few common contributors
<mripard_> you can add ijc I guess
<bbrezillon> (hopefully it will erase the NAND without writing new stuff on it, and with keep track of Bad Block)
<oliv3r> mripard_: absolutly
<longsleep> bbrezillon: Right that might work - but i would prefer something which can be done from a mainline booted kernel though :)
<bbrezillon> longsleep: s/and with/and will/
<bbrezillon> longsleep: that's almost impossible, unless there some BBT stored somewhere on the flash
<anthony_emtrion> I don't want to spam but this A31 seems to be good too :
<longsleep> bbrezillon: With patch removed, still no bad blocks. So i consider this a valid fix for the problem with a ton of bad blocks when moving from libnand to mtd kernel.
<bbrezillon> longsleep: I would not say a valid solution, just a working one :-)
<bbrezillon> longsleep: erasing Bad Blocks is always a bad idea
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
<longsleep> longsleep: True - but shouldnt they get marked bad again quickly if they are really bad?
<ddc> bbrezillon: I'm wondering if this should work echo 1 > /debug/nanderasebb. without applying erasure patch
<bbrezillon> longsleep: yes they should, but ddc case prooved it was not so easy ;-)
<bbrezillon> ddc: wooh, is that a new one ?
<longsleep> bbrezillon: I learned yesterday that nothing about the NAND is easy :)
<ddc> setting the nanderasebb attribute of debugfs
<quitte> bbrezillon: only found the kernel attaching it in the scrollbuffer - but it shouldn't make a difference:
lkcl has quit [Ping timeout: 246 seconds]
<bbrezillon> ddc: where did you find it ?
<bbrezillon> ddc: I don't think it's a mainline feature :--
<bbrezillon> :-(
<bbrezillon> ddc: this feature has been discussed many times, but AFAICT, has never been accepted
xavia has joined #linux-sunxi
<bbrezillon> quitte: can you show me your dts (sorry if I'm always asking the same things :-)) ?
<longsleep> ddc: do you hae a link to lkml of that feature - looks useful to me
<bbrezillon> longsleep: this is one of the threads
<quitte> bbrezillon:
ddc has quit [Ping timeout: 272 seconds]
<longsleep> bbrezillon: sorry which thread do you mean?
<bbrezillon> quitte: you should somehow change the bitflips_threshold before attaching the ubi device
<bbrezillon> longsleep: sorry, forgot to paste it
Quarx has quit [Quit: KVIrc 4.2.0 Equilibrium]
<quitte> to something way lower. okay. I read that but didn't see a connection to my problem
dudepdx has joined #linux-sunxi
<bbrezillon> quitte: no higer
<quitte> hmm. ok it was the erase times then
<bbrezillon> quitte: IIRC, the default threshold is 40
<bbrezillon> quitte: (which is the ecc strength)
<quitte> bbrezillon: how can you tell that is the problem?
<longsleep> bbrezillon: 2005 wtf - thats old
<bbrezillon> quitte: on MLC NANDs you often reach this limit beacuse of bit levels changing avor the time
<bbrezillon> quitte: I'm not sure this is the problem, I say, we should try by changing that
<bbrezillon> quitte: and this is the log that makes me think this might be the cause: [ 27.044142] UBI warning: init_volumes: static volume 0 misses -1 LEBs - corrupted
<quitte> I read that as meaning the volume was corrupted... if it means tzhe LEB is corrupted I'd have to agree
<bbrezillon> longsleep: another one => ttp://
dudepdx has quit [Ping timeout: 255 seconds]
<bbrezillon> quitte: AFAIU the messages it says it miss 1 LEB, and this might be caused by wear leveling trying to copy a block with too many bitflips to another block
<longsleep> bbrezillon: ok i see - so they say that its bad to delete the bad blocks table. Mhm i will need to think about this.
<quitte> what happened to ddc ehen he erased the bbt? I did, too.
<longsleep> bbrezillon: I have now added this to our workaround FAQ. If you get lots of bad blocks, compile kernel with patch, erase flash with ignoring bad blocks. Reboot with patch removed, bad blocks are gone.
<longsleep> bbrezillon: Now i need to figure out regarding the chip support stuff.
<bbrezillon> quitte: can you try to apply this patch ?
dudepdx has joined #linux-sunxi
<bbrezillon> quitte: and then re-format your ubi volumes
<bbrezillon> longsleep: what do you mean by chip support ?
<longsleep> longsleep: flash bbt support which you suggested earlier
konradoo77 has joined #linux-sunxi
<longsleep> bbrezillon: btw - can you tell me the kernel config flag for this?
<quitte> bbrezillon: is that to increase the bitflip threshold?
<bbrezillon> quitte: yes
<bbrezillon> quitte: just for testing purpose
<quitte> I'll drop it in, but won't try it out right away. I'll have to rebuild the image soon enough. also I haven't eaten yet
<longsleep> bbrezillon: great thanks !
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
PulkoMandy has joined #linux-sunxi
dudepdx has quit [Ping timeout: 240 seconds]
notmart has quit [Quit: notmart terminated!]
dudepdx has joined #linux-sunxi
<bbrezillon> quitte: BTW, can you paste the full boot log ?
<quitte> is one with working ubi okay,too?
dudepdx has quit [Ping timeout: 255 seconds]
<bbrezillon> quitte: no :-)
<bbrezillon> quitte: I'm interested in the failing ones ;-)
anthony_emtrion has quit [Quit: Page closed]
<quitte> wait a second. scrolling to find it
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
PulkoMandy has joined #linux-sunxi
<longsleep> bbrezillon: Do i need to set the nand-on-flash-bbt for each partition in DT?
<bbrezillon> longsleep: no, it's nand flash related
<longsleep> bbrezillon: ok so i just set it on the top level thanks - should i see this somewhere if it is enabled?
<bbrezillon> longsleep: you'll see it during the boot => it says something like "on flash BBT table found at 0xYYYYY"
<bbrezillon> longsleep: I don't recall exactly the log message
<longsleep> bbrezillon: i will find it - let me check
<bbrezillon> quitte: how often do you see this error (at every boot, after several boots) ?
<longsleep> bbrezillon: how about Bad block table not found for chip 0
<longsleep> bbrezillon: Bad block table written to 0x0001ffe00000, version 0x01
<longsleep> bbrezillon: looks good doesn't it?
<bbrezillon> longsleep: yes, but if you reboot your board, it should find it directly
<longsleep> longsleep: doing so at the moment
<longsleep> bbrezillon: mhm - no it didnt find it :/
konradoo77 has quit [Ping timeout: 245 seconds]
<bbrezillon> longsleep: show me that
<longsleep> bbrezillon: thats my dt:
<bbrezillon> longsleep: I see you've applied the 2 patches I pushed on my branch yesterday, which should fix the BB table bug
<longsleep> bbrezillon: right - cherry picked them today yes
<longsleep> bbrezillon: and thats the boot log output
<bbrezillon> longsleep: I was asking for your logs :-)
<bbrezillon> longsleep: okay thx
<longsleep> i can paste the complete log if that helps
<longsleep> bbrezillon: so its like in the docs, its written twice and should be placed at the end of the chip
<bbrezillon> longsleep: not this time :-)
<bbrezillon> longsleep: yes
<bbrezillon> longsleep: and it seems to be written at right place
lkcl has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
<longsleep> bbrezillon: mhm - maybe it needs to be erased or something?
ddc has joined #linux-sunxi
<bbrezillon> longsleep: nand core is already taking care of it
<ddc> longsleep: can u do another erase ubiformat and reboot
<longsleep> ddc: sure
<longsleep> bbrezillon, ddc : Btw - these are the steps i am currently running for ubifs:
Gerwin_J has quit [Quit: Gerwin_J]
zeRez has joined #linux-sunxi
<bbrezillon> longsleep: if you're running all those steps on the target you can drop the 2nd one and replace it by a new one (at the end):
<bbrezillon> longsleep: oops, sorry
<longsleep> bbrezillon: Yes i know - i have the other instructions too which do not require the cfg file - do you mean that?
<bbrezillon> longsleep: yes, I hadn't seen the -r /tmp/fs, is is already filled with what you want to put in your rootfs ?
<longsleep> bbrezillon: oh yeah sorry - thats just a tree i created earlier with a rootfs
<longsleep> bbrezillon: the only parameter i am not sure was the --max-leb-cnt on mkfs.ubifs
<longsleep> bbrezillon: just picked some value i read somewhere
<bbrezillon> longsleep: if you're running all these steps on the platform you should use informations exposed by sysfs
<longsleep> bbrezillon: you mean not the information returned by mtdinfo?
<bbrezillon> or mtd-info
<longsleep> bbrezillon: yeah i read the values from mdtinfo for the current board
<bbrezillon> but here you're just assuming every body will have a NAND flash with 8K pages
<bbrezillon> 2M blocks
<bbrezillon> etc
<longsleep> bbrezillon: right - thats why i list mtdinfo step first
<longsleep> bbrezillon: but you are right, i didnt tell to adapt the values according the particular output
<longsleep> bbrezillon: but these values are correct for the cubietruck i currently use
<bbrezillon> longsleep: you could easily make a script to automate that ;-)
<longsleep> bbrezillon: true yes - but first make it run :)
<longsleep> bbrezillon: and i still have no clue how to write boot0 and get u-boot on the NAND
<bbrezillon> --min-io-size => /sys/class/mtd/mtdX/writesize
<longsleep> bbrezillon: ok so now i got a new ubi device
<longsleep> bbrezillon: UBI device number 0, total 4090 LEBs (8510341120 bytes, 7.9 GiB), available 0 LEBs (0 bytes), LEB size 2080768 bytes (2.0 MiB)
<longsleep> bbrezillon: now reboot ?
<longsleep> bbrezillon: mount worked too btw
<longsleep> bbrezillon, ddc : this is the UBI output if you are interested:
<longsleep> bbrezillon, ddc: Nope - still didnt find the BBT and wrote a new one on boot.
zeRez has quit [Ping timeout: 250 seconds]
<longsleep> bbrezillon: but at least i am still able to attach and mount after boot - so this never failed for me yet
dudepdx has joined #linux-sunxi
<longsleep> bbrezillon: btw did you see - it marked the really bad blocks again good PEBs: 4090, bad PEBs: 4
<bbrezillon> longsleep: but still, it should find it :-)
<longsleep> bbrezillon: so the question is did i do something wrong or is it a kernel problem
<bbrezillon> longsleep: I think it's a kernel problem :-)
<bbrezillon> (or a sunxi-driver problem)
<bbrezillon> longsleep: I have to go
<mripard_> I'm pretty sure it's bbrezillon's fault
<dack> okay... I'm trying to run the meminfo program, but now I can't seem to get the stock Android to boot!! I didn't even make any changes to it!
<dack> I can get to the uboot prompt... Is there anything I can do from there to get things to start up?
<longsleep> bbrezillon: well - next week then - thanks for your help :)
dudepdx has quit [Ping timeout: 246 seconds]
<longsleep> dack: well you do not seem to have the correct data on the nand
ddc has quit [Quit: ddc]
<dack> longsleep: I mounted it, but never changed anything on there...
<longsleep> dack: Mhm i suggest you flash nand again with Phoenixsuite - or boot with an sdcard and try to fix it.
zeRez has joined #linux-sunxi
<dack> I don't have an image for Phoenixsuite and my linux image on sdcard can't access the nand
<libv> pfff, that microsd adapter board is pretty shitty. why is this not the standard pin size, and why does this require yet another adapter?
<dack> There's a "recovery" button on the device... I tried booting with that but no joy. I get a weird display on the monitor now, but serial still reports not being able to boot
<longsleep> dack: so what is on your nand then? Isnt that available as image for Phoenixsuite?
<dack> longsleep: I'm sure somewhere on the 'nets... but I have no idea where. I've contacted a few people and they haven't been able to give me anything.
<longsleep> dack: Well i just started with sunxi - so i am not an expert but i would say if you have some device with software from some vendor they are the ones who have to provide the image.
<longsleep> dack: Not sure if this can be recovered some other way.
<longsleep> dack: You could try to build an sdcard with cubian (which has nand support) and see what you can do from there.
lkcl has quit [Ping timeout: 240 seconds]
zeRez has quit [Remote host closed the connection]
zeRez has joined #linux-sunxi
<libv> ah, ok, it does somewhat fit
<libv> dack: not this again
<libv> dack: boot it into android
<dack> libv: dude!!! :) that's what I'm trying to do!
<libv> get a terminal app or an ssh server from the play store
<dack> libv: I didn't do anything to what's on the NAND, but suddenly it won't boot into stock Android
<libv> oh, it fails to boot now?
<dack> libv: yes
<libv> great, we ran into the libnand issue again
<dack> libv: well, it fails to boot Android.. my sdcard with linux works fine. :P
<libv> if you had followed the howto, you would have retrieved the data already
<libv> the fact that you used that sdcard killed your android.
<dack> libv: I didn't do anything to what's on the NAND so I have no idea why this would have happened nor would have following any wiki prevented it
<dack> libv: how's that?
<libv> dack: this is a known issue with our libnand code
<libv> everyone has been sticking their heads in the sand on it
<dack> libv: so, what's the issue exactly? It's modifying something on the NAND?
<libv> yup
<libv> now if i wasn't the only one working the wiki regularly and doing all sorts of random things, i would feel guilty now about not having fixed this already
<dack> libv: I'm a little confused by terminology... is libnand the sunxi_nand driver for the kernel or the nand support in u-boot?
<libv> our sunxi nand driver is older
<libv> allwinner is not providing code for newer versions it ships (which is breaching the GPL)
<libv> and this code is known to kill installations on at least cubietruck
Akagi201 has quit [Remote host closed the connection]
<dack> libv: so, this is some other kernel module, not the sunxi_nand one? Where is that in the source tree?
<libv> dack: if you had, after not finding a way to do fel, reverted to dealing with android, instead of trying to run a linux, you would've been fine
<libv> dack: what does that matter?
<libv> dack: your android is dead, and unless someone finally goes and figures out what messes this up, and fixes it, and perhaps provides you with a way of fixing this, it's going to remain dead
<dack> libv: I want to see if this is something I was actually even using. I had started linux off the sdcard before and then ran Android after with no issue.
<libv> dack: feel free to try
<libv> but my a10s stick is no longer booting android anymore either after having successfully loaded libnand
<libv> from a sunxi kernel
<libv> luckily, i have a cubietruck that i can throw stuff at
<libv> but...
<libv> this delays my uboot code even further
<dack> libv: okay, but which kernel module is this specifically? I'm using the 3.4 kernel and only tried the sunxi_nand one. Where is this other libnand thing?
<libv> now if only people would work the wiki and do some menial tasks from time to time
<libv> dack: i am talking about the 3.4 kernel
<libv> dack: do know that further tinkering with your hw might further reduce the chance of us reviving the installation there
<libv> i now have little other option but to go hunt down the issue on cubietruck
<dack> libv: can I first confirm that I was actually using this libnand thing by checking the kernel config?
lkcl has joined #linux-sunxi
<libv> dack: did you use defconfig?
<dack> libv: yes, but minus a bunch of stuff and with my patch to rename the sunxi_nand to sunxi_nand.ko instead of nand.ko
<libv> oh, that was you too?
<libv> was that the same hw?
imcsk8 has quit [Quit: Reconnecting]
<ijc> oliv3r, mripard_: What list am I being added to? ;-)
<dack> I made that change to try to get NAND working on MK808C, but no luck. I tried it on this TXCZ_A20, but also no luck.
imcsk8 has joined #linux-sunxi
<libv> does the mk808c still boot android?
<dack> libv: yes. It's had no issues.
<libv> oh, because it couldn't read the nand?
<libv> or couldn't identify the flash module
<dack> libv: neither device could read the nand. It said the "magic" was wrong and did nothing. I checked and the nand id's are listed in the source code as being supported, though.
<dack> libv: but wait... I thought libnand != sunxi_nand ?
<libv> aha, ok, so the partition magic difference was noticed
<libv> anyway, i will now have to spend a lot of time doing that on the cubietruck.
<libv> since noone else bothered to do so.
thedude has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 240 seconds]
<dack> libv: after living with roommates I've learned to not get too hung up on what others should or shouldn't be doing. You only get frustrated and annoyed because you can only control what you can do.
<dack> libv: I'm running a wiki too that I've had a lot of trouble getting other people involved... I feel the pain too. ;)
<dack> libv: any way, is libnand sunxi_nand or not? All of my attempts at accessing the nand has been with sunxi_nand
<dack> libv: Are all these issues surrounded around: ? Or something else
dudepdx has joined #linux-sunxi
_massi has quit [Remote host closed the connection]
thedude has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
astr has quit [Ping timeout: 272 seconds]
dudepdx has quit [Ping timeout: 255 seconds]
<dack> oliv3r: wens: longsleep: Is libnand a uboot thing or a kernel module? And if a kernel module, is it the moniker for sunxi-3.4/drivers/block/sunxi_nand ?
<Turl> dack: it's the same thing
quitte has quit [Read error: Connection reset by peer]
<dack> Turl: Just to be completely sure, which things are the same?
<Turl> we say libnand because there's a 'libnand' blob at times and some basic code shim
<Turl> libnand, sunxi_nand, allwinner's ugly nand driver
quitte has joined #linux-sunxi
lkcl has quit [Ping timeout: 245 seconds]
thedude has joined #linux-sunxi
<Turl> the problem is that allwinner changed something on it and released a newer version in the newer sdks
astr has joined #linux-sunxi
<Turl> so it uses a new on-flash format or something
<Turl> and the old code seems to choke on it and mess up somewhere
<dack> Turl: ah.. okay, thanks for clearing that up!!! ^_^
thedude has quit [Ping timeout: 240 seconds]
<Turl> np :)
<dack> Turl: I still don't see how this could cause issues like I'm seeing, though. The libnand is failing to mount the nand but now I can't boot the stock Android.
<Turl> dack: it may have tried to be smart and 'fix' it or something
<dack> Turl: I guess it doesn't matter because it seems I need to reflash regardless. There's a button on my device to boot from the recovery partition, but that doesn't work either.
<Turl> do you get zero output on uart?
<dack> Turl: maybe.. but I've tried using it many times on another device and it's never done anything to the Android.
<dack> Turl: no, I get the uboot prompt
<Turl> "mbr not exist"
<Turl> they may have changed the mbr format yet again
<bbrezillon> longsleep: I'm back :-)
<bbrezillon> longsleep: I found the bug BTW
<dack> Turl: I haven't done anything to the stock Android, though... I looked at some past serial logs with successful boots and they seem to diverge at "NB1 : nand_info_init fail"
<bbrezillon> longsleep: a missing flag, and everything fall apart
pwhalen has quit [Ping timeout: 246 seconds]
dudepdx has joined #linux-sunxi
diego_r has quit [Quit: Konversation terminated!]
<bbrezillon> longsleep: and as mripard_ (which is a really supportive co-worker BTW :D) suggested, this was all my fault => I tend to squash my fixes into existing commits, which definitely does not help when other developers want to base their work on my branches :-)
dudepdx has quit [Ping timeout: 272 seconds]
<bbrezillon> longsleep: you should rebase your branch on mine, and in exchange I'll try to do incremental patches from now on :-)
pwhalen has joined #linux-sunxi
lkcl has joined #linux-sunxi
<libv> dack: since you now ran into this issue big time, and i really would like to see this board supported as well, i will flash a new android to my cubietruck and then figure out why it is messing up and how we can fix it
<libv> if it is at all fixable
<dack> libv: that'd be awesome! I've tried contacting several suppliers too to see if I can get an image to simply reflash the device
dudepdx has joined #linux-sunxi
dudepdx has quit [Ping timeout: 246 seconds]
afaerber has quit [Quit: Verlassend]
konradoo77 has quit [Ping timeout: 255 seconds]
konradoo77 has joined #linux-sunxi
dudepdx has joined #linux-sunxi
<dack> If I can get this unit working, I'm now able to get them for about $31 USD for an order as small as 5. (for some reason the guy just stopped selling them individually after I got mine)
<dack> As for using it as a media center... it seemed pretty terrible. ^_^
dudepdx has quit [Ping timeout: 255 seconds]
afaerber has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
alexvf has quit [Ping timeout: 246 seconds]
Akagi201 has quit [Ping timeout: 260 seconds]
dudepdx has joined #linux-sunxi
guest385 has joined #linux-sunxi
dudepdx has quit [Ping timeout: 255 seconds]
<guest385> is there some technical limitation to build kitkat for A10? or noone has tried it yet?
<mripard_> ijc: ml with allwinner engineers
konradoo77 has quit [Ping timeout: 246 seconds]
konradoo77 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
deasy has joined #linux-sunxi
physis has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 255 seconds]
bonbons has joined #linux-sunxi
libv has quit [Ping timeout: 250 seconds]
amitk has quit [Quit: leaving]
libv has joined #linux-sunxi
wingrime has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
guest385 has quit [Quit: Page closed]
<libv> now really.
physis has quit [Remote host closed the connection]
physis has joined #linux-sunxi
marcin_ has quit [Quit: Konversation terminated!]
lkcl has joined #linux-sunxi
konradoo77 has quit [Ping timeout: 255 seconds]
zeRez has quit [Ping timeout: 240 seconds]
konradoo77 has joined #linux-sunxi
__builtin_trap has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
physis has quit [Remote host closed the connection]
FreezingCold has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<__builtin_trap> does anyone know whether the allwinner SoCs execute bootloader code in secure state or in non-secure state? because this AM335x SoC seems to execute all non-boot-ROM code in nonsecure state and i want to have access to the secure state and i'm considering getting a board with an allwinner SoC
<libv> mnemoc: is there room to unpack the A31 and other SDKs?
Gerwin_J has quit [Ping timeout: 250 seconds]
<Turl> __builtin_trap: ijc can probably answer that
<mripard_> __builtin_trap: iirc, the bootloader is started in secure
<Turl> libv: I can check if you tell me where
<libv> Turl: i am filling in the urls on the a23 SDK gpl violations
<libv> i think i/someone else for a change should go do the same for a31, a33 and a80, in as far as SDKs are available
<Turl> libv: there's around 100G free on that partition
<Turl> the A23 SDK is 13G
<__builtin_trap> can someone try __asm__ __volatile__("MRC p15, 0, %0, c1, c1, 0\n" : "=r" (scr) : : ); on an allwinner SoC and tell me what is value of scr?
<Turl> you can probably unpack a handful, but not every single one. Is there any value in unpacking them?
yann_s has quit [Quit: ZNC -]
<__builtin_trap> because if you can read SCR i'm *pretty sure* that the SoC is letting you boot in secure state
<libv> Turl: hrm. ok, seems like i should go throw each and every uboot and each and every kernel into a git repo and toss it over to github
<libv> that's going to be loads of fun.
<Turl> libv: we have some already I think, lichee branches
<libv> but if i don't do it, no-one else will, and people like jsmirl will foolishly continue trying to downplay real issues.
<Turl> libv: do you want me to do it?
<Turl> I can do it on ssh so it won't take a month and a half to upload :)
<libv> do what? we don't seem to have space for full SDK unpacks
Akagi201 has joined #linux-sunxi
<Turl> what you just said, make a repo with every uboot and push to github
<libv> Turl: the real hassle there is finding a relatively close kernel and u-boot relase
<libv> i have a pretty good one for a23
<libv> for kernel
<libv> but really, this effort should be split
<libv> on sdk per sdk basis
<Turl> libv: sometimes they do come with history
<libv> yeah, these things need to be figured out on sdk per sdk basis
<libv> i have dled and unpacked the a31_V4.5_MerriiLinux_Humming already
Akagi201 has quit [Ping timeout: 246 seconds]
<Turl> __builtin_trap: you get illegal instruction with that (from userspace)
<libv> and a23 is here as well
<Turl> libv: assign one to me and I'll check it
<__builtin_trap> Turl: that is expected, you cannot read it unless you're in Secure *and* in PL1 (so you can't be in secure state / user mode)
<libv> they are massive though
<Turl> __builtin_trap: doesn't the kernel print the mode on boot as well?
<__builtin_trap> Turl: i don't know.
konradoo77 has quit [Ping timeout: 255 seconds]
Gerwin_J has joined #linux-sunxi
konradoo77 has joined #linux-sunxi
<__builtin_trap> oh, other question -- are there boards with allwinner SoC that support JTAG?
<Turl> __builtin_trap: I think all of them do, even the tablets
<Turl> I don't know if anyone ever used it though, maybe hno
gaby has quit [Ping timeout: 245 seconds]
<Elrond> The a10-lime has *many* pins routed to the outside, so it might have the jtags.
<Turl> libv: I shouldn't have used v in tar... >.<
Gerwin_J has quit [Ping timeout: 250 seconds]
<Turl> the jtag pins are shared with the mmc ones, so they're easy to access
gaby has joined #linux-sunxi
<Turl> they're also available on some other pins
ninolein has quit [Ping timeout: 255 seconds]
lkcl has quit [Ping timeout: 240 seconds]
<__builtin_trap> hmmm. which allwinner board should i get if i want JTAG?
ninolein has joined #linux-sunxi
<Turl> libv: no git history on the first one
<libv> yeah :(
<libv> so the top of the toplevel Makefile gives a good approximation
<libv> the version at the top of...
<libv> argh!
<libv> eurasia!
<Turl> libv: lichee/{boot,linux-3.3,u-boot,tools/pack}
<Turl> how well does that approximate the useful parts?
<libv> yup, looks good
<libv> Turl: so you're just unpacking for now?
<libv> how large are those bits?
<Turl> I just unpacked the first one only
<Turl> I'll repack those bits to keep people sane
<Turl> libv: less than 1G uncompressed
<Turl> I'll let you know when tar is done
<libv> cool, i can then add direct links
<libv> nand, nand_v2 and libisp in the first sdk kernel
<libv> for gpl violations
<libv> and a nice set of nands for u-boot
ah has quit [Ping timeout: 255 seconds]
ah has joined #linux-sunxi
<Turl> libv: ~140M for the stripped version
konradoo77 has quit [Ping timeout: 260 seconds]
<libv> Turl: nice
<libv> dling
<Turl> libv: lmk if you need anything else from the sdk, otherwise I'll rm the unpack in a bit
<libv> can you provide those stripped ones unpacked?
<libv> that would solve the most pressing issues
<Turl> I guess we can keep those unpacked, yeah
<Turl> we need a robots.txt first though
<libv> ok
<Turl> google seems to love crawling the other unpacked sdk :P
<libv> true
<Turl> I should have a coffee cup while tar finishes
FreezingCold has quit [Ping timeout: 246 seconds]
PulkoMandy has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
deasy has joined #linux-sunxi
lkcl has joined #linux-sunxi
<libv> ooh, libavcodec is lgpl
<libv> but they are not linking to the whole of libavcodec, so they must have edited the code
jemk has quit [Quit: leaving]
Akagi201 has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 245 seconds]
hramrach has quit [Ping timeout: 264 seconds]
dack has quit [Remote host closed the connection]
<libv> Turl: thanks
<Turl> libv: np
<libv> Turl: do you have these unpacked somewhere?
<Turl> the stripped ones? not yet
<Turl> but I can do that now
lkcl has quit [Ping timeout: 264 seconds]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 250 seconds]
protoCall7 has joined #linux-sunxi
xavia has quit [Remote host closed the connection]
Nyuutwo has joined #linux-sunxi
paulk-aldrin has quit [Quit: Ex-Chat]
hramrach has joined #linux-sunxi
<libv> Turl: can you do the same for the first one?
bonbons has quit [Quit: Leaving]
* libv works the wiki some more
<Turl> libv: which one is the first one?
<libv> mostly a load of ffmpeg symbols in cedarx
<libv> the smallest one
<libv> a31_V4.5_MerriiLinux_Humming.tar.gz
<Turl> sure, give me a couple minutes
<libv> thanks heaps, this speeds things up enormously
<libv> loads of ffmpeg libavcodec symbols
<libv> enough to give an approximate revision range i'd say
paulk-aldrin has joined #linux-sunxi
paulk-aldrin has quit [Remote host closed the connection]
ricardocrudo has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
<libv> a31_v4.5_hummingbird_kfb_ok has AW5306 code!
<Turl> 53? o.O
<Turl> maybe that's the wx product family
<libv> touchscreen
<libv> but this is usually a binary as well
<libv> "where's touch, where's future"
<libv> pfff
<libv> they lost touch, and hope!
hramrach has quit [Ping timeout: 264 seconds]
<Turl> for some reason it's twice the size of the other stripped ones
<libv> strange
<libv> but great, thanks, i'll be throwing all that in the wiki
lkcl has joined #linux-sunxi
<libv> then i'm off to match 1100 cedarx symbols to ffmpeg :(
hramrach has joined #linux-sunxi
<Turl> ah, there's like 600M worth of .img on there
<Turl> sun6i_dragonboard_A31_Hummingbird.img and without the _Hummingbird
Akagi201 has joined #linux-sunxi
<libv> ah, toss that ;)
<Turl> do you want me to repack them? it's barely 150M when compressed
<Turl> xz takes quite a bit to run :p
<libv> well, for me personally it doesn't matter anymore, but it might help others to get that size down
Akagi201 has quit [Ping timeout: 250 seconds]
<Turl> going from multi-GB to a couple hundred M is quite better already
<Turl> but I'll try to clean it up further later
<Turl> libv: any other SDK you'd like to see getting the treatment?
<libv> A23 was unpacked already
<libv> do we have a33 or a80 sdks yet?
<libv> or did we only just get these a31 ones
* libv doesn't remember what was flying around this week
<libv> Turl: can you make the unpacked one from the last version available as well?
<libv> then i can complete the links.
<libv> ah, nm
<libv> i refreshed :p
<Turl> :)
<Turl> I think wens got some A80 ones from one of the chinese filehosters
<Turl> but he hasn't uploaded them yet as far as I can see
<libv> wens: !
<libv> that's looking pretty meaty
<libv> Turl: thanks :)
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 250 seconds]
<Turl> libv: looking good :)
<libv> it's becoming pretty tough ignoring the violations now :)
kuldeepdhaka has quit [Quit: good night or precisely say good morning]
Akagi201 has joined #linux-sunxi
Akagi201 has quit [Ping timeout: 245 seconds]
ricardocrudo has quit [Remote host closed the connection]
protoCall7 has quit [Quit: protoCall7]
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 250 seconds]