hno changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See | | Logs at
arokux has quit [Remote host closed the connection]
<ojn> Turl: Patch applied/posted. I don't know your real name/email so I couldn't give you a Reported-by line, unfortunately.
<Turl> ojn: you could've asked :) it's no big deal anyway
<ojn> turl: not too late. /msg me. :)
<ojn> (I haven't pushed yet)
hark has quit [Read error: Operation timed out]
Black_Horseman has quit [Read error: Operation timed out]
Black_Horseman has joined #linux-sunxi
<slapin_nb> gnight, all!
<hno> slapin_nb, MTD up tlo date in u-boot? Amazing! Congratulations!
hark has joined #linux-sunxi
<slapin_nb> hno: then we have to work around MTD driver for u-boot
<hno> ?
<hno> You mean work on the sunxi MTD driver?
<hno> The MTD framework update is in sunxi-current already btw.
<hno> probably been for a while. Was merged mainline on 31/5.
<hno> slapin_nb?
<Turl> ojn: so, going back to the boot issue, I narrowed it down to MXC, OMAP2+, ROCKCHIP, STI, TEGRA
<Turl> ojn: if I disable those, from what I can see all new on your commit, it works again
<Turl> ojn: it might be code size or something else though, this is a diff between a working and nonworking config
<ojn> Turl: interesting, so rockchip breaks sunxi?
<Turl> ojn: rockchip, i.MX, omap, sti and tegra :)
<Turl> but I'm leaning towards that they're not to blame, and it's just a side effect of including them
<Turl> after all, the rockchip code is just 1 .c file
<Turl> and it looks correct to me
<ojn> yeah could be
ykchavan has quit [Quit: Leaving]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<Turl> ojn: ok, so I got it booting now
<Turl> ojn: apparently uboot puts the fdt on a place the kernel likes to sit on or something :/
<Turl> env set fdt_high 0xffffffff when loading it on a far away place does the trick
<Turl> arokux1: ^
rz2k has quit []
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
hipboi has joined #linux-sunxi
lkcl_ has quit [Ping timeout: 246 seconds]
lkcl_ has joined #linux-sunxi
\\Mr_C\\ has quit []
BJfreeman has quit [Quit: had a good time]
\\Mr_C\\ has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<slapin_nb> hno: yes, sunxi mtd driver.
Rachie_32947 has joined #linux-sunxi
Rachie_32947 has quit [Client Quit]
Offshore has joined #linux-sunxi
dwilkins has quit [Ping timeout: 246 seconds]
\\Mr_C\\ has quit []
\\Mr_C\\ has joined #linux-sunxi
eebrah|away is now known as eebrah
Tsvetan has quit [Read error: Connection reset by peer]
atiti__ has quit [Ping timeout: 264 seconds]
rellla has joined #linux-sunxi
hipboi has quit [Quit: Leaving]
<rellla> utente: works fine for me.
dwilkins has joined #linux-sunxi
<hno> Turl, same problem as for initrd? Remember a discusion before where a similar variable was needed for external initrd.
<Turl> hno: yes, I suppose
<Turl> hno: but this time DT is relocated to near the kernel instead of too far off
<Turl> hno: uboot probably doesn't expect my kernel to be ~6-7M
<oliv3r> mornin'
<oliv3r> Turl!! go to bed!
<Turl> oliv3r: :P yeah I should
<Turl> night :)
<oliv3r> lol
<oliv3r> nn
<oliv3r> hno: did you look at my github if they are split properly now?
<hno> oliv3r, wasn't avare you had worked on that. Will take a look.
deasy has quit [Remote host closed the connection]
n01 has joined #linux-sunxi
<oliv3r> hno: let me paste it
<oliv3r> also, there's a u-boot issue still open, where I asked your input, it's 1 of the 3 patches there
<oliv3r> some path change
atiti__ has joined #linux-sunxi
<oliv3r> hno: hmm, the change to dram.h i should probably move 1 patch back
hipboi has joined #linux-sunxi
<oliv3r> ello sir
hipboi_ has joined #linux-sunxi
<hno> oliv3r, I saw the u-boot question. I think it is fixed in sunxi-current but not sunxi.
<hno> I plan to get rid of sunxi-current after A20 merge, moving to wip/ development branches and release tags instead.
bamvor has quit [Quit: Leaving]
hipboi has quit [Ping timeout: 268 seconds]
<utente> rellla, can you give me the recompiled
_hipboi_ has joined #linux-sunxi
<hno> oliv3r, there is still unrelated changes in the dram bits patch. dramc_clock_output_en call is moved around.
<hno> and need to split it in before a20 and after a20.
hipboi_ has quit [Ping timeout: 264 seconds]
<oliv3r> hno: ohh, before/after a20 :S hmm
<hno> so a20 support + more from sun7i drop can go in together separate from the bits cleanup.
<oliv3r> any suggestion how to best do that?
<oliv3r> git add -p I guess
<oliv3r> i'll split it into 3 patches then
<hno> 3?
<oliv3r> 1 pre a20 merge 1 post a20 merge
<oliv3r> 1 that adds new things for a20
<hno> I am happy with 4.. DRAM bits clenaup before a20 merge. a20 code, a20 bits cleanup, bits from sun7i drop.
<hno> no need to squash things together.
<hno> the last three goes in as one merge anyway.
<oliv3r> ok so 4 patches
<hno> no need to spend time on squashing things.
<oliv3r> heh, i didn't spend time squashing things, i did most work in 1 patch :p
<oliv3r> and now i have to split them
<oliv3r> :)
bamvor has joined #linux-sunxi
<hno> I think the easiest way to split the dram cleanup is to use rebase -i, and duplicate the patch.
<oliv3r> duplicate the patch?
<hno> in the rebase patch listing.
<oliv3r> you can duplicate stuff there? :)
<hno> you can do whatever you like there. It's just a cherrypick list for rebase...
<oliv3r> ah ok
<hno> with some sauce.
<oliv3r> so i'll have to go way back to where the a20 stuff got added
<oliv3r> add the first bits clarification stuff
<oliv3r> then do the a20 merge, a20 code bits cleanup
<hno> yes.
<oliv3r> and then on top the new su7i changes
<oliv3r> ok i'll go way back in history then :)
<oliv3r> i'll do that on a new branch, in case i mess up :)
<hno> hmm.. probably easier to squash a20 + bits... you will get lots of conflicts in the a20 patch after splitting dram bits.
<hno> if squashing then you can just resolve that to the current version with dram bits cleanup in the rebase.
<oliv3r> ok i'll try to make the best of it
<oliv3r> i'll do the dram.h as 1 commit with all changes in it, since technically, its unrelated to other commits, it's just adding definitions
<hno> so 3 patches. DRAM bits cleanup. A20 support (+ a20 DRAM bits cleanup), sun7i drop additions.
<oliv3r> i'll do my best
arokux has joined #linux-sunxi
<arokux> mripard, any updates on mysterious bug?
<mripard> arokux: I was asleep, so I didn't have all the details, but Turl seem to have narrowed the source of the bug to a few platforms that could cause it
<oliv3r> mripard you did not dream of it?
<oliv3r> :D
<mripard> oliv3r: my dreams aren't connected to IRC :)
<arokux> and he sleeps now? :)
<mripard> arokux: from what he was saying, disabling all the platforms but sunxi allows to boot
<mripard> arokux: yeah, it's 4 or 5AM for him
<mripard> so I guess he's asleep :)
<oliv3r> pff, you don't have the irssi notifier android mindprobe?
<arokux> yes, he said about this yesterday.
<arokux> I wonder why the code for the other platforms is executed at all...
<oliv3r> multi platform kernel
<oliv3r> but it might not get executed, it might trigger some other bug
<mripard> it might not be code executed, but maybe just the kernel being too big and triggering some bug.
<oliv3r> that
<arokux> mripard, yes, that is also what i'm thinking of
<mripard> but some platforms used to have initcalls declared, that will be always invoked.
<arokux> the comments in head-common.S say that the r2 (atags pointer) will be fill out, or zero
<oliv3r> mripard: can I start splitting stuff up as patches, pmu, p2wi, pinmux fixes and send them to sunxi ml so people can review them? and push it to my github?
<mripard> oliv3r: for the A31?
<oliv3r> yesh
<arokux> it is zero, but shouldn't be
<mripard> arokux: yeah, we all know that
<mripard> one thing that could happen as well, is (an errata selected by | assembly code specific to) one architecture that mess up the r2 register
<mripard> oliv3r: yeah, I guess you can
<mripard> I'll give it a try
<oliv3r> i'll let it go past you before pushing/sending to ML to get your ack to push it
FR^2 has joined #linux-sunxi
<mripard> do you have a branch somewhere I can test?
<oliv3r> far far from that :)
<oliv3r> still a lot of work needs to be done on the dram controller
<oliv3r> and i don't know how testable p2wi and pmu are
<oliv3r> without dram :s
<oliv3r> and haven't even looked at mmc changes :S
eebrah is now known as eebrah|away
<oliv3r> i'm slow, i know, but $work keeps getting in the way
<mripard> don't worry, I totally understand that
<mripard> I haven't been that dedicated to sunxi either lately
<mripard> well, at least not as much as I wanted to.
<oliv3r> borderlands! i remember :)
<oliv3r> heh, i wish i could do this 8/5 for $money
<oliv3r> but if wishes where horses, we'd all be eating stake right now
<mripard> monday was the *first* time I played it :)
<oliv3r> :p
<oliv3r> i tease, i tease
<oliv3r> mripard: do you know of a company like free-electrons in belgium/holland?
<oliv3r> e.g. a die hard linux shop :)
<mripard> there's mind in belgium
<mripard> yep
<rellla> utente: not atm
<oliv3r> 'we are hiring'
<mripard> that's the only one I can think of right now
<oliv3r> mnemoc: :p
<oliv3r> it depends how close/far they are from here of course
<mripard> they must be in that weird-speaking part of belgium
<mripard> so the closest one to you iirc
<oliv3r> lol
<mripard> Antwerp maybe
<oliv3r> oh that's not TOO far
<oliv3r> well 1 1/2 hours i guess :s
<oliv3r> Leuven
<oliv3r> which is near bruxelles
<oliv3r> which is 2 hour - 2 1/2 hours from here
<oliv3r> and i can't move to belgium, my gf will kill me
<oliv3r> oh, there's a different road that's only 1 1/2 hours
<oliv3r> still far to do every day for a commute :(
<mripard> TGV :)
<oliv3r> that pos :p
<oliv3r> i need to go to rotterdam first, which is 1:15
<mripard> I don't know where you live though :)
<oliv3r> then to brussels, probably 45mins, then an hour to get to leuven :)
<oliv3r> eindhoven :)
<oliv3r> Smartest region in the world!
<oliv3r> or so they advertise themselves with
<arokux> mripard, any nice companies you know in germany?
<mripard> and yet, they have a soccer club
<oliv3r> PSV!
<mripard> still not that smart, right :)
<oliv3r> hahaha
<oliv3r> brainport
<oliv3r> Philips's hometown
<oliv3r> not that philips is worth much anymore
\\Mr_C\\ has quit []
<mripard> ah, didn't knew that
<mripard> and for germany, there's pengutronix, denx and linutronix
\\Mr_C\\ has joined #linux-sunxi
<mripard> but all are quite far from you iirc
<oliv3r> Philips is originally from Eindhoven, PSV -> Philips Sport Vereniging
<oliv3r> We still have the Philips High Tech Campus here
<oliv3r> i used to live < 5 minutes from there, now it's probably 20 minutes (by bike)
<oliv3r> We have ASML here
<oliv3r> and of course my school; Technische Universiteit Eindhoven :)
notmart has joined #linux-sunxi
<arokux> what is ARM errata?
<mripard> workarounds for hardware bugs
<hramrach__> we don't know any that apply to a10/a20 yet ;-)
<mripard> no, but with the multiplatform kernel, we could be bringing in errata for other SoCs
<mripard> and there's errata for the Cortex-A7 :)
<hramrach__> and does it apply?
<hramrach__> I did not enable any
<mripard> that part we don't know :)
<oliv3r> we can use the errata to trigger certain hardware bugs though no?
<oliv3r> so if bug crashes chip; bugged chip!
<hramrach__> they are workarounds for the bugs
<hramrach__> so if it did not crash yet it's likely not bugged
<oliv3r> well we disable the errata of course
<oliv3r> well with those errata, you know what to do to try to trigger the bug
<hramrach__> I don't have any enabled
<oliv3r> and never ever had a crash?
<arokux> mripard, in menuconfig System Type I have only Allwinner 1X SoCs enabled. however the bug can be reproduced. is there a place where I can switch off even more platforms?
<hramrach__> I did have a crash. I diagnosed it as SD card getting loose in the socket
<oliv3r> lol
<hramrach__> which bug?
<arokux> hramrach__, if the initramfs is builtin, kernel won't boot
<hramrach__> I don't do initramfs so I would not know
<oliv3r> also, it's only on mainline for now
<hramrach__> when I heve more time I look into running mainline too
<hramrach__> need to patch in a new led driver and forward-porting it from 3.4 would be needlessly difficult
<hramrach__> what storage works on mainline? ethernet?
<arokux> hramrach__, there is driver for ethernet
<mripard> arokux: it's not as definitive as that I'm afraid.
<hramrach__> should do but need to set up netboot/netroot
<arokux> mripard, your config from yesterday, which worked, did it worked with mainline too?
<mripard> what do you mean by mainline?
<arokux> your master
<mripard> well, yeah, otherwise why would I've told you it worked?
<oliv3r> lol
<oliv3r> i hope slapin_nb gets totally hooked on working on mtd again
<oliv3r> and that that will be mainline ready :)
arokux has quit [Remote host closed the connection]
<hno> mm.. need to work on pushing u-boot stuff mainline.
<oliv3r> almost done with the splitting patch
<oliv3r> hno: what are your plans for that? Push most of it as it is, and cleanup later
<oliv3r> or clean it up first?
<oliv3r> beacuse (dram anyway) some parts are quite messy still
<hno> still have some things from the previous review that need to be addressed before even the basics can be resubmitted.
<hno> one trivial is to have mach-types.h updated.
<hno> more messy is to decide if pinmuxing is separate or core..
<oliv3r> hno, do you have a link for the issues from the first time? i'm curious to look at it
<oliv3r> but a major cleanup (partial rewrite) will be done after it was mainline then?
<hno> oliv3r, MMC and SPL is not in submittable shape yet I think.
<oliv3r> SPL is quite broad
<hno> Not really. It's mainly DRAM, and a bit of clock.
<oliv3r> i did send some cleanup patches a while ago for other systems
<hno> Also, there was discussion about merging the i2c driver with another very similar.
Kolyan has joined #linux-sunxi
<oliv3r> yeah, didn't you test it allready?
<arokux1> I wonder if uboot can take advantage of dt if it were built into it
<hno> arokux1, partly.
<oliv3r> SPL cannot
<arokux1> oliv3r, SPL cannot because of it's current state or in principle?
<oliv3r> in principle
<hno> no, but spl can be configured from dt with not too much effort.
<oliv3r> SPL can not be larger then 24kb in binary form
<oliv3r> arokux1: SPL right now is 22k i think, so you'd have to add something that reads and parses the DT
<Kolyan> Hi everybody. I trying to install Debian at allwinner A10 based game console. All works fine except of touchscreen - modules can't be loaded. Could someone help me with this trouble?
<hno> imho quite pointless to try making SPL DT aware.
<hno> Kolyan, are you using the right fex?
<hno> aka script.bin..
<Kolyan> Yes. I used bin-files from android firmware
<Kolyan> There is some logs
<oliv3r> Kolyan: are you using the same kernel?
<Kolyan> No. I built kernel from linux-sunxi git. Branch 3.0
<oliv3r> sun4i-ts is a resistive touch screen driver, are you sure you want to load that?
<oliv3r> you first need to find out what touchscreen you have
<oliv3r> see if that driver is available in linux-sunxi git
<oliv3r> and then try to load that
<Kolyan> This is not so important because i cant load module by unkown reason
<hno> Kolyan, is the modules from the same kernel build?
<oliv3r> randomly trying to load the sun4i-ts (for resistive touchscreen_ is pointless, as it's highly unlikly you have that
<Kolyan> Please look at logs
<Kolyan> The same kernel
<hno> logs says the modules are not from the same kernel build...
<Kolyan> But these modules are from same kernel
<Kolyan> From modinfo :
<Kolyan> vermagic: 3.0.76+ preempt mod_unload ARMv7
<oliv3r> i only see you modprobe sun4i-ts
<oliv3r> do you HAVE a resistive touch screen?
<Kolyan> No. I have capactive. The trouble is: i cant load any module for touchscreen support.
<Kolyan> sun4i-ts its just an example
<oliv3r> then don't use sun4i-ts; it's for resistive touchscreen only
<oliv3r> then it's a horrible example log to paste
<hno> sun4i-ts refuses because your fex do not have resistive touch panel enabled.
<hno> [ 1890.370000] sun4i-ts.c: sun4i_ts_init: start ...
<hno> [ 1890.370000] rtp_used == 0.
<hno> goodix fails because your fex do not have a goodix touch panel.
<oliv3r> so, boot stock android, find out what touch panel you actually have, then try that
<hno> or look in your fex. it's listed there
<oliv3r> hno: sometimes the fex lists 3 or 4 and the kernel 'tries' them all
<Kolyan> The error is about vermagic
<oliv3r> it fails if the i2c address can be found on the buss
<oliv3r> vermagic == wrong module for this kernel
<oliv3r> and that does not show in your log
<hno> Kolyan, to me the vermaigc error says that the modules is from a different kernel build without vermagic enabled in .config.
<Kolyan> I think this log is more readable
<Kolyan> oliv3r, but number module is correct for kernel.
<oliv3r> this log still tries to probe the sun4i-ts
<Kolyan> oliv3r, this is trouble
<oliv3r> stop doing that, you don't have that
<Kolyan> oliv3r, i told - sun4i-ts its just an example.
<oliv3r> it's a horrible example
<hno> sun4i-ts can not work on your device.
<Kolyan> oliv3r, i cant load any touchscreen module - the same error
<oliv3r> Kolyan: did you build the kernel AND the modules in ONE go
<oliv3r> then replaced both the kernel AND the modules (entirly)?
<oliv3r> it look slike you changed somet things inbteween
<oliv3r> e.g. preempt, mod_unload and possibly ARMv7
<Kolyan> oliv3r, i installed both kernel and modules from same build. I built kernel and modules using linux-sunxi 3.0 branch
<hno> Kolyan, you can only load the right touch screen module. The others will fail.
<oliv3r> it smells a little bit, like you've built a kernel, installed the kernel, noticed your modules from the tablet itself where not loading, then rebuild the kernel with mod_unload enabled but only added the modules
<Kolyan> hno, but not with this error. This is strange.
<oliv3r> version magic error says: You changed kernel options, i will not load
<oliv3r> so the VERSION is the same, but the COMPILE options are different
<oliv3r> un4i_ts: version magic '' should be '3.0.76+ preempt mod_unload ARMv7
<oliv3r> 'should be'
<hno> Kolyan, yes that is strange. But the modules do load and complain before that error.
<Kolyan> oliv3r, but modules and kernel from same build.
<oliv3r> i would make clean; make, make modules and install a fresh set
<oliv3r> that said, are you using the BSP?
<Kolyan> hno, this means i cant load any touchscreen module even if this module is for touchscreen of my device
<oliv3r> the bsp will make a nice hwpack with all the files in it
<hno> Kolyan, before we can help you any further you need to look up what touch panel you have.
<oliv3r> your logs are quite useless, as you only sshow a log of trying to load sun4i-ts, which might be in such a bad state, that nobody even knows about. Nobody uses sun4i-ts
<hno> and what module that maps to.
<Kolyan> oliv3r, no. I used these instructions:
<Kolyan> hno, ok. Thanks for help.
<hno> Kolyan, it's all in your fex (script.bin in decoded form)
<oliv3r> Kolyan: what tablet do you use?
<Kolyan> iDroid X360
<oliv3r> Kolyan: also, show a modinfo goodix_ts.ko; just so we can compare
<oliv3r> hno: i may have messed up my history in my git tree, hashes for existing commits most likly, so you can't pull directly, but got the patches split up now
<oliv3r> double checking my logs now
<arokux1> mripard, do you work for olimex?
<oliv3r> arokux1: he works for
<oliv3r> which is based in france; olimex is from bulgaria? hungaria?
eebrah|away is now known as eebrah
<arokux1> oliv3r, or Romania
<arokux1> doesn't matter
<mripard> oliv3r: bulgaria iirc
<oliv3r> lunchtime!
<mripard> enjoy your meal
<oliv3r> :D
<arokux1> mripard, I wonder what is the point of mainlining sunxi for freeelectrons
<mripard> none
<mripard> it's a hobby thing
<oliv3r> well that's not true
<arokux1> mripard, nice :)
<oliv3r> it's always good PR
e-ndy has quit [Ping timeout: 248 seconds]
<arokux1> mripard, how do you make your living then? :)
<mripard> oliv3r: yes, of course, but it doesn't bring any money in (directly at least) :)
<tkoskine> Olimex is from Bulgaria, says so at
<mripard> arokux1: well, I work for free-electrons on various projects during the day
<mripard> and hack on allwinner stuff when I have some spare time
<arokux1> I see
<arokux1> btw, do you guys maybe have some other hardware to try out current mainline (3.11-rcX) to see if the bug with initramfs is specific to Allwinner?
<mripard> not here, but I can try tomorrow
<Kolyan> - goodix_touch.ko
<hno> Kolyan, have you looked up what touch controller you have yet?
<Kolyan> Now i trying to look it
<Kolyan> But the main trouble is vermagic
atiti__ has quit [Ping timeout: 276 seconds]
<oliv3r> still smells like mismatch
<oliv3r> goodix_touch: version magic '' should be '3.0.76+ preempt mod_unload ARMv7 '
<oliv3r> for some reason your magic is ''
<Kolyan> Well... I need gsl1680 driver for my touchscreen. Buy i trying to understand - why touchscreen drivers could not be loaded. Version in vermagic is ok.
<hno> From my reading of the logs it's reported as '' after the module refuses to load because it's not enabled in the fex.
<oliv3r> kernel says it is not ok
<Kolyan> modinfo shows that vermagic is ok
<oliv3r> yeah, but your kernel doesn't think so :)
<Kolyan> Ok.
<hno> I think the vermagic error is a byproduct, not cause.
<Kolyan> Anyway thanks for help. I learned new information about platform.
MadSpark has joined #linux-sunxi
tzafrir has quit [Ping timeout: 256 seconds]
<oliv3r> Kolyan: :)
<oliv3r> only ts fails?
<Kolyan> oliv3r, yes
e-ndy has joined #linux-sunxi
<Kolyan> oliv3r, any modules is loadable except of touchscreen
<oliv3r> acking to fex too then
<Kolyan> oliv3r, i used bin-files from stock android firmware. And touchscreen works fine under android.
<arokux1> what do you use as IDE to work on kernel? for now I'm with vim, but I quickly forget all the tricks that are needed there to be efficient and each time after a break start from scratch...
<oliv3r> vim
<oliv3r> i have 4 or 5 vim windows open
<oliv3r> i have 'Tlist' addon for vim though
<oliv3r> yeah
<oliv3r> think so
<oliv3r> pretty sure
<oliv3r> :)
<oliv3r> though when i hack at work
<oliv3r> i'm doing it via SSH and only have console vim
<hramrach__> hello
<hramrach__> mnemoc: is there any plan merging hansg a20 patches into stage/sunxi-3.4 ?
<hramrach__> I have some patches on top of those patches
<mnemoc> hramrach: i will today
<mnemoc> i read about some regressions
<mnemoc> it wouls be awesome if you can mail me a summary of what should be merged and what not
<mnemoc> i'm still trapped doing paperwork before starting a job in .de
<oliv3r> mnemoc: Hey! (was it? read back) is hiring linux monkeys
<mnemoc> i have over 2k unread mails in thw sunxi list :(
<hramrach__> mnemoc: I am running the kernel
<hramrach__> if there are regressions I am not hit by them (much)
<mnemoc> need to hurry. went to the wrong finanzamt :(
<oliv3r> mnemoc: merge hansg's tree, one of the regressions is not related to the hansg tree, it's a more serious issue anyway
<oliv3r> the other one, ssvb has to comment
<oliv3r> mnemoc: move to belgium! :p
<mnemoc> :)
<hramrach__> but I needed some build fixes. probably because I have config that differes from F19 kernel
<mnemoc> send me a personal mail with what to pull please
<mnemoc> will do it today.
<oliv3r> hansg-for-amery
<ssvb> oliv3r, mnemoc: what about the build failures in the hansg's pull request?
<ssvb> imho patch sets should not include stuff which breaks things with the follow up patches to only fix it later
<oliv3r> ssvb: then we can't pull anything until hansg comes back and he fixes his tree
<oliv3r> ssvb: i do agree with you though
<oliv3r> then agian, our tree h asn't seen updates in how many months? 2 more weeks won't hurt either
<ssvb> this makes bisecting PITA among other things
<ssvb> it would make sense to thoroughly test the patches before hansg returns
<oliv3r> testing, we need lots of that :(
tzafrir has joined #linux-sunxi
Black_Horseman has quit [Remote host closed the connection]
pacopad has joined #linux-sunxi
<hramrach__> ssvb: feel free to test
<hramrach__> ttps://
<hramrach__> this WorksForMe(tm) but I did not look at screen output yet
<hramrach__> yes, I had build failures. that's why I have those extra patches
<ssvb> hramrach__: thanks, I'll check it, though that's still bisect unfriendly
<hramrach__> yes, ideally the build fixes would be merged with the part which breaks the build
<oliv3r> hno: ping
<oliv3r> wait, let me try to fix the broken hashes
<hramrach__> probably some of the parts that break build are in stage already
<hramrach__> well, technically they don't
<hramrach__> but i2c uses a private sun7i irq header on sun7i
<hramrach__> hmm, I wonder how that is supposed to work on sun4i
<arokux1> btw, what happened to BDD Group's SODIMM module? No news from them since March.
<oliv3r> hno: hmm, i think github fixed that automagically; so there should be 3 patches in from me; 1 pre-a20, the a20 patch, the post a20 bits and the sun7 drop
<hno> oliv3r, rebase changes hashes.
<hno> oliv3r, please rebase on sunxi-current. The DRAM controller magics cleanup do not apply.
Tsvetan has joined #linux-sunxi
<hno> and... in mctl_enable_dllx it still has phase which is from a20 patch.
<hno> oliv3r, I do not think this builds for sun7i..
<hno> hmm.. what happened with board/sunxi/dram_sanei_n90.c..
<hno> oliv3r, rebased on sunxi-current and pushed to wip/a20-oliv3r in my github rep.
<hno> but diff from wip/a20 looks strange.
<oliv3r> did I push the wrong thing?
<hno> I do not think so.. but you know your trees better.
<oliv3r> ok i'll re-rebase and double check
<oliv3r> but I thoguht you where gonna cherry-pick ;)
<oliv3r> anyway, the sanei tablet was wrong I think, there was an issue up on github for it, somebody corrected it
<oliv3r> so hence the sanei
<hno> oliv3r, easier to pick that tree, there is some conflicts from sunxi-current moving forward..
<oliv3r> ok i'll get sunxi-current, cherry-pick the pre-a20 dram changes
<oliv3r> that should give us 1 good patch for old stuff
<oliv3r> good catch on the phase, must have gone during the rebase :S
<hno> #ifdef CONFIG_SUN7I
<hno> - clrsetbits_le32(&dram->mcr, DRAM_MCR_MODE_NORM(0x3) | (0x3 << 28),
<hno> #else
<hno> + clrsetbits_le32(&dram->mcr, DRAM_MCR_MODE_NORM(0x3), (0x3 << 28),
<hno> also looks odd..
<oliv3r> yeah saw that in your paste
<oliv3r> i had merge conflics on both those area's
<oliv3r> i'll also double check my output_dir is empty when rebuilding
<hno> ok. found the n90 mismatch. my wip/a20 tree was missing that patch.
hipboi_ has joined #linux-sunxi
<hno> and rebased branch now on github. Don't know where the previous push ended up..
<oliv3r> so the pre-a20 stuff i'll base against sunxi-current
_hipboi_ has quit [Ping timeout: 240 seconds]
<hno> oliv3r, grab that branch, fix up the errors and continue..
<hno> it's rebased already.
<oliv3r> okay
<oliv3r> better plan
<oliv3r> i'll split the wrong things out and let you do squashing if needed
<hno> ok.
<hno> I am keeping my wip/a20 until you have a reasonable patchset and your and my tree don't differ in strange ways...
<oliv3r> lol very fair :)
<oliv3r> i'd spot them myself, but finding ones own mistakes is rather hard :(
<oliv3r> well for me it is
hipboi_ has quit [Quit: Leaving]
<arokux1> man, so many boards out there, I wonder how are they all used...
buZz has joined #linux-sunxi
<pacopad> I try to compile 3.4.43 sources from a repo yesterday and run it on my cb2.
iig00cz has joined #linux-sunxi
<pacopad> it boots but when it try to load mali drivers it crash
Nikolas has joined #linux-sunxi
<pacopad> is there a hop to got mali and cedars support on a20 soon ?
<hramrach__> mali drivers are not very well tested on a20
<hramrach__> which repo did you use?
<hramrach__> for me mali does not load at all
<pacopad> i used hans-sunxi-3.4 branch
<pacopad> i tried with last available mali src again this kernel too
<pacopad> i got no problems with ump part
<pacopad> the driver load ok and /dev/ump is created
<oliv3r> hno: how do you quickly compare two trees with eachother?
<hno> git diff treea treeb
<oliv3r> ah ok
<oliv3r> i
<oliv3r> i'm still going over it
<oliv3r> but it compiles
<oliv3r> i removed all my u-boot output dirs, so that shouldn't have interfered
<oliv3r> i'm using github right now to check the patches
<oliv3r> githubs coloring helps me a lot
<mnemoc> hramrach__: what hansg branch i need to merge?
<oliv3r> afaik the 'for-amery-3.4' one
<hno> oliv3r, looks relatively save.
<hno> sane.
<mnemoc> oliv3r: thanks
<oliv3r> mnemoc: but ssvb (and kinda me too) think we should wait for hansg to return
<mnemoc> ok. /me frozen
<oliv3r> mnemoc: go spend reading :p
<oliv3r> hno: see, why don't I see those whitespace issues :S
<oliv3r> hno: how do you get that whitespace line to show up? is what i look at
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<oliv3r> hno: as for that DRAM_MR_POWER_DOWN, this is what I see there
<oliv3r> and that commit should be the first one in the line
<hno> oliv3r, I am only diffing the trees. Not looking at individual commits yet..
<hno> oliv3r, which version of my wip/a20 do you have?
<hno> cfbaa5762c5d7b65a53b4bd48eef28b19db9a950 is current.
<oliv3r> you mean tip?
<oliv3r> head*
<hno> Hmm.. had forgot to push some it seems.
<oliv3r> 80fd9a5c5b87ba2f48f4a71b666839870e780be6 i have as latest
<oliv3r> sunxi: Add cubieboard2
<hno> latest of what?
<oliv3r> wip/a20 has that as head
<hno> yours yes.
<hno> mine is cfbaa5762c5d7b65a53b4bd48eef28b19db9a950
leowt has joined #linux-sunxi
<oliv3r> ah that's slightly older i see
<hno> and the diff is only that whitespace line + burst.
<oliv3r> or different, i don't know anymore :(
<hno> doesn't matter.
<oliv3r> yeah I did change that compared to earlier submits
<oliv3r> but i should have pushed those in the correct patches
<oliv3r> i know, i'm a newb :p
<oliv3r> i do not wield the sword of the git well
<hno> now the big question.. do the DRAM bits commit build and run on sun[45]i?
<hramrach__> mnemoc: how do you test commit buildability?
<oliv3r> i should be able to rebase back to that commit, and run it, right?
<oliv3r> i know it builds, i tested that :)
<oliv3r> i'll test run it
<oliv3r> if your happy with the patch
<mnemoc> hramrach__: I run a build of each sunxi defconfig
<hramrach__> is there a tool that takes a commit range and builds every revision?
<hno> oliv3r, git checkout af16bdc8babaa134b373d66fbb1a60a4f38740e9
<oliv3r> oh i didn't know i could do that :)
<hramrach__> I would like to test the hansg branch but it has like 20+ commits
<oliv3r> but that's the commit i had on my clipboard to paste :)
<mnemoc> hramrach__: but i don't do it per commit, but by merge point
<oliv3r> this will take a while hno, i have to build, upload it to dl.sunxi .org, download, boot my cubie's to write, then reboot and flash
<hno> oliv3r, anyway, I am pretty happy with current state.
<hramrach__> the point is that the thing had build issues at the end so would want to test each commit to interleav the fixes properly
<oliv3r> hno: i'll start pushing my first bits for a31 later
<hno> I did run wip/a20 on sun4i yesterday.
<oliv3r> i'll test pre a20 on sun4i, then head on sun4i and sun7i
<hno> I am pretty confident it will work. But can not test until tonight.
<oliv3r> i'll test it now, then you can confirm tonight
<oliv3r> i need more USB uarts :)
<oliv3r> 1 at home, 1 at work isn't enough
<oliv3r> and i need to swap the seperate headers for 1 4 pin one that goes on easier
<hno> leaning towards just merging it into sunxi-current and we fix up any issues as found later..
<oliv3r> if it runs, it should be good, if there's bugs, they are bugs from before our merges anyway
<oliv3r> i don't think we are pushing bugs now
<hno> oliv3r, I add usb uart chips to most important boards. That way I just plug an usb cable.
<hno> bought a bag of these:
<oliv3r> how did you do that on the cubie?
<oliv3r> oh wow
<oliv3r> i like that
<hno> soldering iron and glue gun makes wonders :)
<hno> but cubieboard haven't got one yet. Mostly using the olinuxino boards these days.
<oliv3r> yeah i saw your sd2 mod :)
<oliv3r> i don't have an olinuxino 1 yet :p
<oliv3r> and i did some mainline a10 work, so was using cubie 1 a lot
<hno> that mod works, but forgot to add a wire for jamming the NAND before glueing..
<oliv3r> oh, one of those fits nicely under the USB stack (upside down)
<oliv3r> i saw the olinino has a jumper for that
<oliv3r> 10 bux! wow, not cheap
<oliv3r> i got one of those nokia cables for 3 4 USD, does require some manual rewirting (cut off nokia specific plug)
<oliv3r> i do like it though I admit
<hno> Bought them at a nice preorder price. Don't remember exactly what I paid.
<hno> can be found in the irc logs way back...
<oliv3r> hehehe
<oliv3r> i might just order 5 or 10 of those DX uart cables and a big bag of 4 pin connectors :)
<oliv3r> <- poor bitch
<hno> oliv3r, found it. I did pay $10 including shipping.
<oliv3r> ouch
<oliv3r> they have 5 for 45 USD packs now
<oliv3r> i love the size
<hno> Yes, allows you to add USB UART to pretty much anything :)
<oliv3r> yeah
<oliv3r> the diode bug, was that a board problem or uart controller?
<oliv3r> since they all seem to suffer from it
stekern has quit [Ping timeout: 246 seconds]
<hno> oliv3r, board design.
dwilkins has quit [Quit: ZNC -]
<oliv3r> ok so add diode to all boards
<oliv3r> is that info ont he wiki?
<hno> I don't think it is.
<hno> Olimex A20 board already have diode.
<hno> could be classified as a SoC design issue if you prefer.
dwilkins has joined #linux-sunxi
<leowt> is there a way to get qt5 with gpu aceleration on a ubuntu rootfs in allwinner a10?
<hno> oliv3r, think it also happens with HDMI cable and other external connections with active data signals.
<oliv3r> hno: they added the didoe? let me check my board :)
<oliv3r> hno: could that be remotly connected to my failing PHY?
<hno> I don't think so.
<oliv3r> since on arokux's melee that was the issue
<oliv3r> he has to reset it when connecting his uart
<oliv3r> damn :(
<oliv3r> was hoping that maybe i could use it
<oliv3r> i should get a replacement chip and solder that
<oliv3r> anybody have a dead cubie they wanna part with?
<hno> oliv3r, to avoid the issue, power on the board and then connect uart.
<oliv3r> well for phy test, i could simply boot android and see what happens
<hno> issue only arise if you have uart connected with no power.
<oliv3r> or HDMI
<hno> exactly.
<oliv3r> i see a D3 on the bottom of olimexino next to the uart
rz2k has joined #linux-sunxi
stekern has joined #linux-sunxi
<oliv3r> well i usually have everything plugged in, so i'll test with everything disconnected
<oliv3r> test 1: wip/a20 with cubieboard2; boots fine
<hno> oliv3r, D3 + R105
<hno> see schematics
<oliv3r> rgr
<oliv3r> sun4i pre-a20 boots too
<oliv3r> just gotta test sun4i post-a20
<ssvb> leowt: yes
<leowt> ssvb, how so?
<oliv3r> hno: the only thing that worries me, right now, SPL for sun4i is 23552 bytes
<oliv3r> so only 1k left
bsdfox has joined #linux-sunxi
<ssvb> leowt: you can also check :)
<leowt> hmm, ssvb im going to experiment with libhybris and then with x11 like that video
<ssvb> ok, ping me if you encounter some bugs or need help
<oliv3r> hno: and sun4i with wip/a20-head 80fd9a5c5b87ba works!
<leowt> ssvb: ok tnks
deasy has joined #linux-sunxi
atiti__ has joined #linux-sunxi
fluo75 has joined #linux-sunxi
<rellla> need some quick git submodule help. anyone free?
<oliv3r> arch/arm/include/asm/arch-sunxi/gpio.h
<oliv3r> whoops
<oliv3r> rellla: just ask :)
<hno> oliv3r, 23552 should be fine.
<oliv3r> leaves little room for features :(
<hno> there is likely several KB to shave off at various places.
<hno> it's not optimized for size.
<rellla> ok. the reference to some submodules here (eg. live+markad) ist wrong. how do i fix it, to point to HEAD? in my local repo there is checked out master in submodule, but git doesn't recognize it :(
<rellla> i want to hack the right commit somewhere into config and push it then once again. seems i broke it in a way
<oliv3r> hno: there's quite some things I saw that could get cleaned up, want to look at that before or after mainline submission?
eebrah is now known as eebrah|away
<oliv3r> rellla: ok that's beyond me :p
<hno> oliv3r, when you have time.
<oliv3r> let me know when you have some, so we can look at a few things that strike me as something that could get cleaned
<oliv3r> 10 more minutes and its hometime! :D
<hno> Only plan on submitting the core parts at this time, resulting in an u-boot that can be loaded by boot1 or u-boot and tftp-boot a kernel.
<oliv3r> ohh, ok sounds sane
<oliv3r> if you need any subsystems cleaned up, let me know and if I have time i'll submit some patches
<hno> MMC needs to be adjusted to do I/O proper.
<rellla> oliv3r: thanks anyway
dwilkins has quit [Read error: Connection reset by peer]
<rellla> any other github freak?
<oliv3r> hno: anything easier :p
<hno> oliv3r, it's easy, mainly search/replace.
<hno> it's doing the right operations, just using wrong style..
<hno> rellla, what you need help with on github?
<oliv3r> ohh, ok i can do that
<oliv3r> hno: ok i'll look at to mmc sometime when i have time
<rellla> hno: yes, look above, maybe i should try in #github
<hno> rellla, I see question about git submodules above. Not really github specific.
dwilkins has joined #linux-sunxi
naobsd has joined #linux-sunxi
<rellla> hno: don't know if the error is git- or github-specific. on my local repo every in submodule HEAD is checked out, so i wanted to do a git commit -a in root to update the submodule-reference.
<rellla> but git in root is just ignoring it.
<hno> rellla, have you updated the parent project with correct references for the sub modules?
<rellla> thats the question how to do that? maybe i miss something. can i tell the parent project which exact refs to use?
<hno> rellla, you do that by adding the submodule paths I think.
<hno> rellla, yes. But make sure to not have a traling /. git add submodulepath NOT git add submodulepath/
tinti has quit [Quit: Leaving]
<rellla> hno: i do a test commit in submodule, a git add PLUGINS/src/live and nothing happens, no git status, no git commit -a . hm.
<hno> the submodule is PLUGINS/src/live ?
stekern has quit [Ping timeout: 240 seconds]
<rellla> yes, hnoi
<arokux1> oliv3r, what do you do at your work?
<hramrach__> a stab at reaodering the commits to make the a20 branch hopefully bisectable
<hramrach__> I wonder if the 'fix pm build' and 'add mach/sys_config.h' are still needed somewhere back in history or the issue they fix was completely eliminated
* lioka .oO smells like vdr
lioka has quit [Quit: leaving]
<rellla> hno: fixed. rm'ed submodules and readded them. strange behaviour.... anyway, thanks
rellla has quit [Quit: Nettalk6 -]
leowt has quit [Quit: leowt]
leowt has joined #linux-sunxi
<hno> oliv3r, merged into sunxi-current.
<hno> except for CCM & DRAM debug functions.
<hno> wip/a20 kept for reference.
rellla has joined #linux-sunxi
rellla has quit [Remote host closed the connection]
stekern has joined #linux-sunxi
\\Mr_C\\ has quit []
\\Mr_C\\ has joined #linux-sunxi
n01 has quit [Read error: Operation timed out]
pacopad has left #linux-sunxi [#linux-sunxi]
FR^2 has quit [Quit: Connection reset by peer]
Yaku-noob has joined #linux-sunxi
<Yaku-noob> hey there
<Yaku-noob> does anyone yet know what´s in those chromecast sticks ?
<buZz> i bet an android stick :P
<Yaku-noob> well, i thought you guys would not think on the level of ,,whats on it" rather then what´s making it happen
<atiti__> hehe ye
<atiti__> i wondered the same today
<Turl> mripard: ping
<atiti__> whats under the hoood
<Turl> mripard: the kernel wasn't to blame after all :)
<mripard> Turl: what was your solution?
arokux has joined #linux-sunxi
heffer has quit [Read error: Connection reset by peer]
<arokux> mripard, the bug seems to be triggered by the size of uImage: <= 5.20 MB good, >= 5.31 MB bad.
<hno> Yaku-noob, I doubt it's an allwinner SoC.
<mripard> Yaku-noob: it appears to be a Marvell Berlin G2
<mripard> aka Armada 1500
notmart has quit [Quit: notmart terminated!]
<mripard> arokux: so you don't have the same problem than Turl in the end?
<arokux> mripard, I think Turl hasn't realize it yet
<Turl> mripard: env set fdt_high ffffffff
<arokux> it worked for him because size was small
<Turl> mripard: uboot puts the dt on some place the kernel likes to step over or so
<arokux> Turl, where do you know that?
<Turl> arokux: can you try with that, while loading dt on 0x5.. and kernel on 0x4..?
<mripard> Turl: where do you load your kernel to?
<Turl> mripard: 0x4... and dt to 0x5...
<arokux> 0x4... probably isn't good.
<mripard> Turl: previously.
<arokux> at 0x40008000 kernel will be extracted
heffer_ has joined #linux-sunxi
<Turl> mripard: same places
<Turl> mripard: but multi_v7 with ramdisk is like 7M :)
<Turl> arokux: get a failing bootlog and see where uboot relocates the dt
<mripard> hno will confirm, but iirc, the fdt/initrd_high are higher addresses where u-boot can relocate the initramfs/fdt, and setting it to 0xffffffff tells it not to relocate anythnig
<arokux> Turl, Loading Device Tree to 40ffb000, end 40fffec7 ... OK
<Turl> 0x40ffb000-0x40008000 = ~16M
<arokux> Turl, distance from 0x40000000 to 0x40008000 is 32KB
<arokux> so 7M don't fit in
<Turl> mripard: indeed, -1U is "do not relocate". And by setting it arbitrarily far we can avoid issues
<Turl> s/setting/storing/
<mripard> arokux: at which address are you loading the kernel?
<arokux> fatload mmc 0 0x46000000 sun4i-a10-cubieboard.dtb
<arokux> fatload mmc 0 0x49000000 uImage
mahdichi has joined #linux-sunxi
<mripard> then why are you talking about 0x40000000 ?
<hno> mripard, I don't know exactly what these does, but yes, setting to ffffffff disables relocation making them stay where originally loaded.
<arokux> mripard, it was another message to Turl
<Turl> hno: what's the rationale behind relocation btw?
<hno> Not sure.
<hno> README talks a bit about them.. and from that I would guess tha we have CONFIG_SYS_BOOTMAPSZ wrong.
<arokux> env set fdt_high ffffffff <--- squashes the bug for me
<mripard> great, then it's probably the fdt that gets relocated inside the kernel image area
<hno> default is to move them as high as possible.
<mahdichi> hi all
xenoxaos has quit [Quit: ZNC -]
<mripard> hno: is it? 40ffb000 doesn't look very high to me
<mahdichi> i try enable 4 wire resistive touchscreen in cubieboard in linaro ubuntu
fredy has quit [Excess Flood]
<mahdichi> and successfully compile tslib with A13 patch.
<mahdichi> i can run ts_test and ts_calibrated
fredy has joined #linux-sunxi
<mahdichi> but i can't config x to use it.
<mahdichi> any idea ?
<hno> mripard, need to check what CONFIG_SYS_BOOTMAPSZ gets set to..
hramrach__ is now known as hramrach
xenoxaos has joined #linux-sunxi
Yaku-noob has quit [Quit: ChatZilla [Firefox 22.0/20130618035212]]
<arokux> hno, 16 << 20
heffer_ is now known as heffer
<Turl> 0xf0000 right?
<arokux> yep
<arokux> Turl, no
<arokux> :)
<hno> mripard, need a bit of help here... CONFIG_SYS_BOOTMAPSZ: is clearly kernel related. u-boot documentation:
<arokux> 16 << 20 == 0x1000000 == 8M
<hno> brain not awake to grok this right now. overheated and tired.
<arokux> hno, what is meant by "memory mapped by startup code of the kernel" ?
<hno> arokux, I would assume this is the earlboot page map, not sure.
<hno> earlyboot..
<hno> not spending much time in that area of the kernel.
<mripard> I don't have much time tonight to look into this, I'll look at it tomorrow if it's ok for you
<mnemoc> hansg!
mahdichi has quit [Quit: Page closed]
<hno> mripard, ofcourse.
<arokux> hno, is there some limited amount of low memory accessible by kernel on sun4i?
<hno> I don't know.
<hno> From u-boot documentation commandline + fdt goes in low memory and initrd in high memory.
<hno> unless relocation is disabled.
<arokux> hno, reading doc on fdt_high, it seems uboot doesn't know what is low and what is high
<hno> arokux, see CONFIG_SYS_BOOTMAPSZ (first one I pasted)
<hno> some more documentation:
<hno> boorm_low / bootm_mapsize / bootm_size
<hno> bootm_low.
<Turl> arokux: ah, derp, 16 is 0x10 and not 0xf :P
<arokux> hno, this seems to be related
mouchon has joined #linux-sunxi
atiti__ has quit [Remote host closed the connection]
<oliv3r> hno: good, i can start basing my new stuff on sunxi-current then :)
<arokux> correction: 16 << 20 == 0x1000000 == 16M
<arokux> hno, increasing bootm_mapsize solves the issue.
<oliv3r> hno: do you want me to resend earlier small fixes that i've sent? or you have them still in your mailbox?
<oliv3r> hno: i'll redo them as they probably have to be rebased anyway
notmart has joined #linux-sunxi
notmart has joined #linux-sunxi
<arokux> why uboot is rebuilt every time from scratch?
<hramrach> it is not
<hramrach> when you do clean more is rebuilt
tzafrir has quit [Ping timeout: 264 seconds]
<arokux> hramrach, ok
<hramrach> but some parts are always built, yes
<arokux> hno, in those doc I haven't found what happens if BOOTMAPSZ isn't set at all
<arokux> so I've deleted it from code
<arokux> it works without it and kernel boots without problems
<hramrach> heh
<hramrach> only potential problem if it decides to relocate something beyond the end of memory because there is no limit anymore
<arokux> I do not understand the purpose of those CONFIG_SYS_BOOTMAPSZ/bootm_low / bootm_mapsize / bootm_size ....
manvindar has joined #linux-sunxi
<manvindar> hi
<manvindar> i have a13 tablet....can i get JB for my tab?
manvindar has quit [Ping timeout: 240 seconds]
<oliv3r> hno: wanna do git rm drivers/net/sunxi_wemac.c or want me to submit a patch for that?
<mturquette> Turl: yes, the drivers/syscon/ stuff was discussed at very high level on some MLs in the past, but no work came out of it
<mturquette> Turl: RE: cpufreq & managing multiple clocks...
<mturquette> Turl: this is the next big problem: coordinating dvfs transitions that affect multiple clocks
<mturquette> some folks (ux500) have created these fake "virtual" clocks which aren't really a part of the tree (I think they might be orphan clocks)
<mturquette> but when you call clk_set_rate(cpu_dvfs_clock, 600000) then the virtual clocks .set_rate callback will simply call clk_set_rate and clk_set_parent on all of the appropriate clocks to do the dvfs transition
<mturquette> so basically it's a hack, but there isn't any infrastructure to do better than this today.
<Turl> mturquette: what about something like cpufreq-cpu0, but that takes a bunch of clock handles and its OP table contains several frequencies corresponding to them?
manvindar has joined #linux-sunxi
<manvindar> hi
<manvindar> i have allwinner a13 tablet
<manvindar> can i get jb for it?
<manvindar> here is lsmod output
<oliv3r> erm, hi manvindar
<manvindar> hello
<manvindar> sir
<oliv3r> there's several JB distro's out there
<oliv3r> 4.1 i think is highest, due to cedarx atm i belive
<manvindar> sir can you tell which one will be good for my tab?
<manvindar> i see that TS and G sensor have problems in many of them
<oliv3r> nope, i don' thave a13 tablet :)
<oliv3r> G sensor not so much, almost all use the BMA250
<manvindar> oh
<oliv3r> ts can be problematic, if there's no source
<manvindar> yes true
<Turl> mturquette: something like
<hno> oliv3r, you have push access to u-boot-sunxi.
<manvindar> @hno
<hno> killed sunxi-wemac.c now.
<hno> manvindar, yes?
<manvindar> can u see lsmod output and tell my hardware
<hno> lsmod do not say what hardware you have.
<oliv3r> hno: didn't wanna mess with things :)
<manvindar> then what i need to do to know my hardware sir?
<hno> manvindar, look at it?
<hno> lsmod tells part of the picture.
<manvindar> look at what?
<hno> the hardware.
<hno> manvindar, what are you looking for?
<manvindar> most of the components inside have rf sheilds
<manvindar> i am looking for JB for my tab
<oliv3r> hno: ok i'll push my pending trivial clean up patches :)
<hno> from lsmod we can see it's an a13 or a10s. That maybe you are the first one with gsm hardware (but probably not). And that you have some touch panel managed by gc0308
<manvindar> yes
<oliv3r> manvindar: have you asked this question on github/mailing list before?
<hno> we can also see that your tablet supports ASIX ethernet dongles.
<manvindar> no
<oliv3r> ah ok, someone else asked about a similar tablet; USB gsm modem it had
<manvindar> yes right
<hno> or at least I think gc0308 is a touch panel controller...
<oliv3r> i think it's csi camera module
<hno> yes, it's a camera.
jemk has joined #linux-sunxi
jemk has quit [Client Quit]
<manvindar> a13 tabs dont have GSM commonly?
<hno> manvindar, many of those modules are various USB Ethernet dongles.
<oliv3r> hno: shall i push my last 2 commits to sunxi aswell? (only layout changes)
<hno> tabs don't have GDM commonly..
<manvindar> yes it supports many usb modems
<hno> oliv3r, I plan on merging sunxi-current to sunxi when we are done with this round and closing sunxi-current.
<oliv3r> hno: then i won't :) gets you a chance to review it before pushing it over
<hno> Do I need to?
<oliv3r> not really
<oliv3r> but you know me and my reviews :p
<oliv3r> (of my own code)
<hno> As good as mine (of my own code)
<oliv3r> that's the only one you might wanna peek it over real quick
<oliv3r> the other one is comments/text changes
<oliv3r> so no needt o look at that
<hno> ou
<hno> you need to work a bit on commit messages...
<oliv3r> yeah I suppose so
<oliv3r> can I edit a commit message without changing the hash?
<manvindar> you guys are hobbyist or professionals? sry for being personal
<oliv3r> pure hobbies
<hno> oliv3r, looks fine to me, but also tells me we fail on 2 GB devices...
<manvindar> oh......
<oliv3r> it was hardcoded before :) so in that sense, no change; but yes
<oliv3r> a10 doesn't support 2GiB anyway, a20 _might_ but unconfirmed for now
<oliv3r> hno: ssvb and I where talking about somehow probing memory size
<oliv3r> do some common sizes tests
<hno> a10 does, except that no one knows how to successfully wire one for 2gb...
<oliv3r> yeah that's what i ment :)
<hno> probing memory size is about much more than this.
<oliv3r> would it be possible though, choose save parameters, then poke the memory at 256 MiB boundry, 512 MiB boundry, 1024 MiB boundry
<oliv3r> and then set up the dramc as if it would have the found amount
<hno> without better understanding of DRAMC I am not comfortable with trying to probe it's settings.
bsdfox_ has joined #linux-sunxi
<oliv3r> well if I look at the memory configurations we haev in sunxi-boards, and what the controller does with it, shouldn't be too hard
<oliv3r> can always ask allwinner what they think once we have a prototype :p
manvindar554 has joined #linux-sunxi
Kolyan has quit [*.net *.split]
Offshore has quit [*.net *.split]
awafaa has quit [*.net *.split]
wigyori has quit [*.net *.split]
oliv3r has quit [*.net *.split]
manvindar has quit [Ping timeout: 264 seconds]
oliv3r has joined #linux-sunxi
wigyori has joined #linux-sunxi
awafaa has joined #linux-sunxi
Offshore has joined #linux-sunxi
Kolyan has joined #linux-sunxi
<manvindar554> whats MID?
<hno> I know how the settings map to controller registers, but only a vague understanding of what it means to the controller.
bsdfox has quit [Ping timeout: 240 seconds]
<oliv3r> manvindar554: Multimedia Internet Device
<manvindar554> i see that my tab is MID08
<manvindar554> what that implies?
<oliv3r> where did you find that name?
manvindar554 has quit [*.net *.split]
jlj has quit [*.net *.split]
<hno> oliv3r, probing in an installer is one thing.
hramrach has quit [*.net *.split]
<oliv3r> hno: well with the new defines, we should be a little further
<hno> yes
<oliv3r> well you have to setup the entire controller with 1 memory size, check it, then go one up, set it up all over again etc etc
<oliv3r> so maybe it's not that great of an idea :p
jlj has joined #linux-sunxi
hramrach has joined #linux-sunxi
manvindar554 has joined #linux-sunxi
<hno> configuring the DRAM controller is quite time consuming and sensitive..
<oliv3r> i agree
manvindar554 has quit [Excess Flood]
naobsd has quit [*.net *.split]
mouchon has quit [*.net *.split]
manvindar has joined #linux-sunxi
mouchon has joined #linux-sunxi
naobsd has joined #linux-sunxi
<oliv3r> manvindar: Manta MiD08 is just a name
<oliv3r> manvindar: sdoesn't mean much
<manvindar> i thought it represents group of same devices
<manvindar> mine is not manta
<hno> manvindar, sometimes, sometimes not..
heffer has quit [*.net *.split]
arokux has quit [*.net *.split]
leowt has quit [*.net *.split]
deasy has quit [*.net *.split]
Brodomir has quit [*.net *.split]
buZz has quit [*.net *.split]
spenser309 has quit [*.net *.split]
slapin_nb has quit [*.net *.split]
focus_it has quit [*.net *.split]
ssvb has quit [*.net *.split]
Tartarus has quit [*.net *.split]
<manvindar> ou
<oliv3r> manvindar: i guess the best name to compare devices with, is what is printed on the PCB
<manvindar> as i said...due to shields i cannot read much
<hno> well, the PCB actually, not only what is printed on it.
<manvindar> i dont want to desolder it
<oliv3r> ssl updates is causing these splits
<oliv3r> manvindar: desolder? oh no :p
<oliv3r> most of the time its just printed on the silkscreen
<oliv3r> there's only a small group of PCB manufacturers, the rest just assemble them (add parts and put it in a housing)
<hno> manvindar, do you have a picture of your board?
<manvindar> no... wait i will take it and upload
<oliv3r> of the inside is most helpfull :)
<hno> but most of the cheap clones and "OEM" builds have very little printed.
slapin_nb has joined #linux-sunxi
<hno> manvindar, the fex for your board do tell quite a lot about the hardware (squid.bin in decoded form)
<hno> sorry, script.bin.
spenser309 has joined #linux-sunxi
buZz has joined #linux-sunxi
<mturquette> Turl: that could work for cpufreq-cpu0 but doesn't solve the general problem
<oliv3r> hno: hungry for squid much? :D
<hno> oliv3r, my other nick is squidhenrik and not without reason.
<mturquette> Turl: CPUs are not the only devices that need to perform DVFS transitions with complicated dependencies
<mnemoc> hno's tentacles are dangerous
<hno> oliv3r,
<Turl> mturquette: hm, I see
<oliv3r> i thought of squid aswell, i have it running here :)
tzafrir has joined #linux-sunxi
<mturquette> Turl: i think taht we might need a general way to coordinate groups of clock frequencies changing.
<mnemoc> oliv3r: the thing is hno is the president of the squid foundation
<mnemoc> so he dreams with cephalopods
<oliv3r> oh really?
<Turl> mturquette: kind of a system where you can register a group of clocks, and set constraints on each of them that must be maintained?
<oliv3r> i just love eating them, mmmm squid
<Turl> oliv3r: didn't you read the page? :P
<oliv3r> i grepped for henrik
<oliv3r> squidhenrik*
<Turl> oliv3r: grep just for henrik :p
arokux has joined #linux-sunxi
ssvb has joined #linux-sunxi
<oliv3r> yeah duh :p Presidetn!
<oliv3r> awe4some
Tartarus has joined #linux-sunxi
deasy has joined #linux-sunxi
heffer has joined #linux-sunxi
Brodomir has joined #linux-sunxi
focus_it has joined #linux-sunxi
leowt has joined #linux-sunxi
<oliv3r> i love squid, i have it running with addblock list
<hno> is also quite funny. And no it was not me who set that title.
<arokux> hno, how can i know which size will the extracted kernel need?
<arokux> hno, is it the file Image which is compressed? (in arch/arm/boot)
<oliv3r> the only thing that highly annoys me at work, when I enter just 1 keyword into my URL bar, squid pops up wth an error, 2 keywords and firefox goes on and does its search, no clue why :)
<hno> arokux, size vmlinux
<oliv3r> extraordinaire :D
<Turl> oliv3r: heh :P isn't it a bit overkill? I just install adblock plus on the computer
<oliv3r> well then i have to install it on more then 1 computer
<oliv3r> and it'll slow down my computer! especially my slow laptop
<Turl> it's a 1 click install :p
<oliv3r> (I ran adblock for YEARS, squid for months)
<hno> oliv3r, because with just one word firefox assumes it's a host name. With two words it knows it's not.
<Turl> excuses :p
<oliv3r> but this has the huge added benefit, that my mobile devices (that don't have adblock) automatically get blocked BEFORE transfering the data
<hno> oliv3r, you can teach firefox otherwise by using a pac script.
<oliv3r> yeah that's actually on my todo
<Turl> oliv3r: I run AdAway on them, hosts based blocking
<oliv3r> Turl: see, tons of work, always having to set it up, i have squid for when I do use a proxy (mostlywhen connecting via work to bypass work proxy :p)
<oliv3r> and have the same block list in my local DNS
<oliv3r> so dns blocks it first, and squid blocks the rest :)
<Turl> meh :p
<Turl> the only tweak I've done to dnsmasq is changing resolver for cdn domains to my isp's
<hno> Turl, what resolver do you use otherwise?
<Turl> hno: OpenDNS
<oliv3r> Turl: i actually run my own DNS server (for my own domains) so adding the block was trivial :)
<oliv3r> Turl: also, my phone is htc hero with 300 mb ram; so i don't want to run too much on it :)
* hno almost always runs his own..
<oliv3r> yes it's a shit phone
<Turl> oliv3r: ouch :) I used a MSM7201 too with 256M since a couple of months ago
<Turl> s/since/until/
<Turl> oliv3r: it's time to upgrade I'd say :p
<hno> Turl, I assume you understand why OpenDNS is free?
<Turl> hno: because they sell a premium solution for business & school
<oliv3r> Turl: i nearly bought a 2nd hand S2, but the seller went on hollidays :( it should be as good as new though, since he got the screen replaced and the housing a week ago, he hasn't even used the repaired version
<oliv3r> hno: I suppose it's not because they wanna make the world a better place?
<Turl> oliv3r: get a cheap gnex or n4 :p
<arokux> hno, thanks. another question: does u-boot knows the size of the UNcompressed kernel?
<oliv3r> Turl: yeah but i wanna see the phone before buying it, and i bet you can't get those for 170 Euro :)
<oliv3r> Turl: also, S2 is the recommended phone for replicant
<manvindar> hey i know one seller who sells cheap unlocked devices
<Turl> oliv3r: well, 200$ :)
<oliv3r> yeah see, it would cost almost 50% more and has to be shipped from the US; possible scratched all over
<hno> arokux, no.
<Turl> oliv3r: ah, you want to run replicant? well you better get their recommended phone then :)
<oliv3r> Turl: also, wasn't this powerVR
<Turl> oliv3r: yeah it is
<Turl> N4 is adreno iirc
<oliv3r> galaxy nexus isn't better then S2, s2 has better screen afaik
<arokux> hno, than I know the problem and can explain it :)
<Turl> oliv3r: gnex is 720p screen :p
<manvindar> here are the pics
* mnemoc hugs his galaxy nexus
* manvindar scratching his head
<arokux> mnemoc, 10?
<oliv3r> mnemoc: i hope you are happy with you Binary BLobs!
<oliv3r> Turl: yes, but LCD, S2 is Super Amoled PLUS
<mnemoc> oliv3r: i keep my nexus devices rooted but unmoded. "pure android experience" (tm)
<hno> oliv3r, in some sense they do, but they need data.
<oliv3r> manvindar: that pic should go on a wiki page called something like CP707-GSM-VOR3
<oliv3r> mnemoc: invested with binary blobs!
<oliv3r> manvindar: they added the gsm nicely to the pcb though
<hno> invested? infested..
<manvindar> ye
notmart has quit [Quit: notmart terminated!]
<mnemoc> oliv3r: yes, but "just works" and gets often OTA updates :p
<Turl> oliv3r: pretty sure gnex is SAMOLED
<manvindar> what is that un used ic port?
<mnemoc> oliv3r: for playing, I have sunxi devices ;-)
<arokux> hno, interested? :P
<Turl> mnemoc: installed 4.3 yet? :P
<oliv3r> mnemoc: where are your principals!
<oliv3r> Turl: you are right, itls SAMLOD, but not SAMLED+
<mnemoc> oliv3r: rule #1 don't play with $work$ tools
<mnemoc> Turl: nope
<manvindar> oliv3r........what u mean by cp707-GSM-V0R3 wiki?
<oliv3r> manvindar: create a wikipage on, name the page that :) upload pics, and other info you have :)
<manvindar> ok thx :)
<Turl> mnemoc: well it's out there :P as well as source
<hno> arokux, what?
<arokux> hno, I understood how those bootm_XXX work
<arokux> also, why the cause of the bug
<hno> how they work is easy. why they are there is the question.
<mnemoc> Turl: thanks for the tip
<arokux> hno, :)
<arokux> hno, it is very unfortunate that uboot doesn't know the size of the uncompressed kernel, i wonder why it isn't saved in the header of the image
<arokux> hno, it could prevent a lot of problems....
<hno> there is not really a header on compressed kernels.
<hno> that-s u-boot images. But inside there you most often have a compressed kernel.
<hno> you can unpack and repack that as well, but it's different..
<manvindar> anyone who is an electronic engineer?
* hno is not
Tartarus_ has joined #linux-sunxi
<hno> manvindar, why?
<arokux> hno, inside of uImage there is a _compressed_ kernel?
<hno> yes
<arokux> hno, very bad
<manvindar> just wanna ask about career path :D
<Turl> arokux: zImage is often self-extracting
<Turl> manvindar: Tsvetan is I think
<hno> there may also be a compressed uncompressed kernel inside the uImage.
<arokux> Turl, ah, uImage is zImage + 64B, good tip!
<hno> arokux, that is the most common.
<manvindar> he is afk?
<hno> but it can also be a raw compressed kernel (gzip / lzo / some other), or even uncompressed kernel.
<oliv3r> ok i wrote a whole line for hno; and only my paste showed up
<hno> oliv3r, what was the line=
<oliv3r> hno: i wrote some initial comments of the 'what should we do with this code' i wrote my comments in //////// blocks
fredy has quit [Ping timeout: 245 seconds]
<hno> oliv3r, reading them now..
<hno> what is trange with mctl_enable_dll0?
fredy has joined #linux-sunxi
<oliv3r> hno: it looks like it's doing the same thing a few times, first clrset NRSET + disable, then clr both, then DISABLSE, NRESET
<oliv3r> i guess it's just how the controller works
<hno> oliv3r, no it's not the same. Look carefully.
<hno> 01
<hno> 11
<arokux> hno, how about this: uboot should check if devtree is overwritten after uncompressing the kernel and gives a warning?
<hno> 10
<oliv3r> oh seesh that is subtle
<oliv3r> good eyes sir!
<hno> arokux, it's not u-boot that uncompresses a zimage.
<hno> when using raw compressed images I do think it notices.
manvindar has quit [Quit: irc2go]
<hno> raw compressed images are uncompressed by u-boot.
<arokux> hno, in this case uImage = vmlinux+ 64 B?
<hno> I don't know why the norm is to have a zimage within u-image instead of a raw compressed image.
<hno> vmlinux is never used, that is an elf.
<arokux> to save flash space, I've read
<hno> a raw compressed image is samller.
<hno> a raw compressed uimage is a flat binary, compressed with your favorite compression algorithm and wrapped in an uimage header.
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
<hno> with compression flag enabled.
<hno> u-boot then knows "ah, a compressed image" and uncompresses it.
<mnemoc> but aren't compressed image self-decompressed?
mouchon has quit [Quit: Page closed]
<hno> there is two... zimage, and comressed u-image.
<hno> zimage is self-expanding.
<hno> (or bzimage, same thing different compression)
<mnemoc> then why do we need u-boot to pre-decompress it ?
<arokux> :D
<mturquette> Turl: exactly. different silicon vendors have been floating "dvfs framework" solutions out-of-tree for a long time
<hno> you don't do both.
<mnemoc> ok
<mturquette> Turl: we just probably need something decent to get merged upstream
<mturquette> Turl: it can arbitrate between different consumers that want different rates (which clk_set_rate cannot do today) and also manage clock dependencies
<hno> the question is why the norm is to use zimage within uImage instead of letting u-boot handle the decompression.
<mnemoc> or if we already have the zimage, why use uImage :p
<hno> but we do..
<arokux> hno, because zImage existed before u-boot?
<hno> not really.
<arokux> so u-boot will load zImage and transfer control to it. zImage then extracts itself?
<Turl> arokux: yes
<arokux> Turl, but how then it cat extract itself starting from the same address in memory??
<arokux> it can*
<hno> u-boot loads uImage with a kernel image. Copies the kernel image to the load address and starts it.
<Turl> arokux: temp buffer? :) I dunno
<hno> arokux, it does a funny little dance to get out of the way of itself first..
<Turl> mturquette: that would be great indeed
<arokux> hno, you think so, or you know it does? :)
<hno> Looks for yourself. arch/arm/boot/compressed/
<hno> and similaryly for each arch...
<arokux> then it should be the responsibility of this decomressing code to check if it overwrites devtree
<oliv3r> arokux: Turl i think the cool thing about kernel compressed images (some compressions anyway) that it was inplace decompression
<oliv3r> i read this ages ago, so i could be very wrong
<oliv3r> but i think this was to help embedded devices with little ram
<hno> arokux, can you try if the same happens with a compressed uImage?
<hno> cd arch/arm/boot
<hno> gzip -9 < Image > Image.gz
<oliv3r> hno: not all of those comments where that trivial (some maybe :p) but there where some good ones i hope! :)
<arokux> hno, and then?
leowt has quit [Quit: leowt]
<hno> working on reconstructing the mkimage line.. not ofen doning this by hand.
<arokux> hno, I'm not following you. I thought you wanted to pack a raw kernel into uImage, not a compressed one. ah.. you mean that if it's *.gz, then u-boot will decompress it by itself, I see.
<hno> mkimage -A arm -T kernel -C gzip -a 0x40008000 -d Image.gz -n Linux uImage.gz
<hno> -rw-rw-r--. 1 henrik henrik 3818772 14 jul 21.39 uImage
<hno> -rw-rw-r--. 1 henrik henrik 3801386 25 jul 22.30 uImage.gz
<hno> ah, the compressed one is also in compressed/piggy.gz
<hno> piggy.gzip.
<hno> arokux, yes u-boot can decompress loaded images.
<hno> pack a raw compressed kernel into uImage.
<arokux> hno, hm.. it booted fine
<arokux> hno, but you've told me that the kernel itself is vmlinux...!
<hno> Image is a raw binary image of vmlinux.
<hno> vmlinux is elf formatted.
<arokux> hm...
<hno> arm-linux-gnu-objcopy -O binary vmlinux Image
<hno> if you want to do it fram scratch, ignoring arch/arm/boot entirely.
<arokux> hno, then the uncomressed thing is actually Image
<hno> which is actually vmlinux.
<hno> same data, different layout.
<arokux> hno, i'm interested in the thing that gets into memory
<arokux> hno, but then my explanation wont work! because Image is only 11MB and small enough not to overwrite devtree
<arokux> and using uImage.gz boots just fine, which actually confirms that Image is small enough
<hno> Well, with uImage.gz u-boot also knows the size of the kernel.
<arokux> but it loads devtree to the same location
<arokux> Loading Device Tree to 40ffb000, end 40fffec7 ... OK
<arokux> both times, with zImage in uImage and with Image.gz in uImage.gz
<hno> so piggy is stomping on the devtree?
<arokux> how else could it be?
<arokux> hno, you the piggy from arch/arm/boot/compressed, right?
<hno> yes..
<hno> the self-decompressor glue.
<hno> hmm.. it says it relocated dtb if needed.
<hno> guess it miscalculates when that is needed.
<oliv3r> put devtree INFRONT of the kernel :) devtree is really small; kernel is random size :)
<hno> there isn't very much space there. atags is at 0x4000100. Kernel at 0x40008000
<hno> command line somewhere around there also I think.
<arokux> oliv3r, devtree is relocated by uboot
<mripard> hno: command line is passed in the DT nowadays
<arokux> mripard, , by the way, I now understand why it's relocated
<hno> aha
<arokux> to fulfill bootm_xxx constrains
<mripard> and atags have been superseded by DT as well
<mripard> there's a compat mode, but I don't exactly know how it works.
<arokux> hno, there is enough place: 0x40008000 0x40ffb000 - 0x40fffec7 0x41000000
<arokux> 0x40008000 0x40ffb000 - 0x40fffec7 0x41000000
<mripard> The recommended placement is in the first 16KiB of RAM
<mripard> with the caveat that it may not be located at physical address 0 since
<mripard> the kernel interprets a value of 0 in r2 to mean neither a tagged list
<mripard> nor a dtb were passed.
<arokux> (see last line)
<mripard> (for the dtb)
<mripard> from Documentation/arm/Booting
<arokux> and there are almost 16MB from 0x40008000 (where the kernel starts) to 0x40ffb000( to where the uboot relocates devtree)
<hno> mripard, interesting.. u-boot seems to think it should go after the kernel as "high as possible for kernel boot code"
<mripard> yeah, presumably to avoid the decompression code to overwrite it
<mripard> but I guess putting it in the first 16KB is exactly for the same reason
<hno> the decompressin code comments says it relocates the dtb if needed.
<arokux> hno, i'll add output to it now and will see...
<hno> But.. that's only for appended DTB maybe.
<mripard> it's weird, because the documentation says in the same time "The dtb must be placed in a region of memory where the kernel decompressor will not overwrite it."
<mripard> ah, yes, probably
<hno> mripard, yes.. and zImage seems to overwrite Image size + zImage size.
<hno> approximately.
<hno> much copying to boot a zImage uImage..
<oliv3r> so besides the kernel, what else needs to be loaded on a pure dtb system?
<hno> dtb.
<hno> unless embedded or appended to the kernel.
<oliv3r> no more env no more atags
<mripard> env?
<hno> there is no env.
<oliv3r> commandline :p
<hno> there is atags + command line.
<hno> or dtb.
<arokux> oliv3r, cmdine
<arokux> cmdline*
<mripard> with dtb, the command line is contained in /chosen/bootargs
<oliv3r> how big is a really huge devicetree?
<arokux> mripard, yes, but earlyprintk must be added from uboot too...
<mripard> and usually, the bootloader patches the dtb just before starting the kernel to update this property
<arokux> mripard, really? earlyprintk has no effect in cubieboard.dtb, but if added from uboot had effect
<mripard> arokux: yes. u-boot takes the content of its bootargs env variable, and fills /chosen/bootargs with it.
<hno> arokux, do Image + zImage add up to overwrite where u-boot loaded the dtb?
<mripard> arokux: u-boot overwrites whatever existed before
utente has quit [Ping timeout: 276 seconds]
<arokux> hno, yes. there is 16MB in total, but they both would consume 20.7MB
<mripard> the bootargs already found in the dts are for legacy bootloaders, but I guess we could remove them now
dwilkins has quit [Ping timeout: 264 seconds]
<hno> 20? How large is your kernel?
<arokux> Image is 14M
<arokux> zImage is 6.7M
<hno> my Image + zImage is 11MB in total.
<hno> -rwxrwxr-x. 1 henrik henrik 7474644 14 jul 21.35 Image
<hno> -rwxrwxr-x. 1 henrik henrik 3818708 14 jul 21.39 zImage
<arokux> i have a rich rootfs apparently :) oliv3r 's
<hno> embedded initramfs?
<oliv3r> i have turls :p
<arokux> hno, yes
<hno> ah, yes that adds up a bit.
<arokux> hno, so are you sure piggy would consume more space that needed?
<hno> needed is a relative topic..
<hno> it needs more space than Image alone.
<hno> from what it looks it copies itself to after the uncompressed kernel.
<hno> and then uncompresses.
<hno> much copying..
<arokux> hno, it is an explanation then.
<hno> and many reasons why not use zImage.
<arokux> i can try to extend kernel's memory map so it's just enough for 20.7 and see..
<hno> mripard, the still unresolved qustion is why do u-boot bother to try to keep stuff in the first 16MB to keep the kernel happy.
<arokux> hno, i know the anser
<arokux> answer
<hno> and it is?
<mripard> hno: the only constraint iirc for the dtb is that it has to be in lowmem
<arokux> bootm_low = SDRAM_BASE = 0x40000000 = 1GB
<arokux> CONFIG_BOOTMAPSZ = 0x1000000 = 16MB
<mripard> but since it's configurable, I guess u-boot has to make a choice at some point
<hno> mripard, what is lowmem?
<oliv3r> ok let me ask a really stupid question
<oliv3r> but what is 'lowmem'. I thought we gave that up with msdos in 1990
<arokux> the memory exposed to the early kernel boot is from bootm_low to bootm_low + CONFIG_BOOTMAPSZ
<mripard> hno: !highmem memory
<arokux> hno, does it make sense to you?
<hno> partially.
<arokux> hno, ask
<mripard> (highmem being the mechanism to address RAM that wouldn't be addressable otherwise)
<hno> why did disabling u-boot relocating the dtb work? Didn't that place the dtb outside the first 16 MB?
<hno> mripard, so the while dance about CONFIG_BOOTMAPSZ is nonsense?
<arokux> hno, because if u-boot doen't relocate, then it increases the amount of memory exposed to early kernel?
<arokux> (so that devtree is reachable)
<oliv3r> so if it fits in the area < 0x40008000 everybody is happy? :)
<oliv3r> (devtree fits there)
<mripard> hno: it looks that way to me
ganbold has quit [Ping timeout: 240 seconds]
<arokux> oliv3r, what "it"? everything is placed *after* this address
utente has joined #linux-sunxi
<oliv3r> place dtb before it
<arokux> oliv3r, uboot relocates it
<oliv3r> tell u-boot to leave it in place <= 0x40000000001
libv_ has joined #linux-sunxi
<oliv3r> erm -<
<oliv3r> wasn't there acommand option to leave it in place?
<mripard> hno: from what the CONFIG_SYS_BOOTMAPSZ says, I guess we can try by setting it to 16KiB
<arokux> yes, env ftd_high 0xffffffff
<mripard> that way, everyone would be happy, wouldn't we?
<arokux> mripard, it is set to 16MB now
<mripard> u-boot would be doing its relocation stuff
<mripard> and linux would have it before the address its extracting to
<mripard> arokux: yeah. I know.
<oliv3r> there we go, in memory decompression :)
<oliv3r> in-place decompression*
<arokux> mripard, but uboot tries to extract the kernel and put ftd so that everything fits into
<arokux> bootm_low --- bootm_low + CONFIG_BOOTMAPSZ
<hno> arokux, try setting bootm_mapsize 0x8000
libv has quit [Ping timeout: 248 seconds]
<arokux> hno, Loading Device Tree to 40003000, end 40007ec7 ... OK
<arokux> hno, Transferring control to Linux (at address 40008000)
<arokux> and hanging
<mripard> u-boot doesn't extract the kernel.
<hno> how nice...
<mripard> the kernel extract itself
<mripard> damn, so much for my good idea :)
<arokux> but now kernel doesn't overwrite the devtree?!
<hno> mripard, u-boot extracts the kernlel (zImage) from the u-image. zimage then extracts the actual kernel from itself
<mripard> hno: ah, yes.
<mripard> well, it's not really an extraction, but yes, of course
<hno> I guess we can set it to 230MB or so.
<arokux> hno, why it doesn't work now?
<hno> arokux, what?
<arokux> hno, kernel won't boot
<arokux> although devtree is *before* it
<hno> arokux, did u-boot copy the kernel to 0x40008000 before executing it?
<arokux> hno, yes
<arokux> Transferring control to Linux (at address 40008000)
<hno> that is executing it...
<hno> before?
<arokux> hno, no log about that.
dwilkins has joined #linux-sunxi
<hno> mripard, there should be no problem having dtb and initrd anywhere in the addressable memory right?
libv_ has quit [Ping timeout: 248 seconds]
Tartarus_ has quit [Quit: Ex-Chat]
<arokux> hno, bootm_size should be big enough to contain zImage + ftd or....?
<hno> Image + zImage + fdt if my understanding is right.
<hno> wait, did you set bootm_size or bootm_mapsize?
<arokux> bootm_size
<hno> <hno> arokux, try setting bootm_mapsize 0x8000
<mripard> bootm_mapsize doesn't work either.
<mripard> I just tried
<hno> fdt_high 0x8000
<hno> maybe?
<mripard> as long as it's in the first gigabyte of memory, we should be fine
<arokux> hno, ERROR: Failed to allocate 0x4ec8 bytes below 0x8000.
<arokux> (for fdt_high)
<hno> ok, so first 16KB is allocated by u-boot for something..
<mripard> isn't fdt_high supposed to be an address?
<mripard> and not a size/
<mripard> ?
<arokux> mripard, yes
<hno> Right... 0x40008000
<arokux> hno, ?
<hno> arokux, try setenv fdt_high 0x40008000
<arokux> hno, fail!
<slapin_nb> hno: hi
<mripard> hno: setting bootm_mapsize to 0x10000000 works nicely though
<slapin_nb> hno: I see mamalign returning NULL pointer allocating 10K for MTD, I wonder what happened
<slapin_nb> hno: in u-boot
<hno> slapin_nb, sounds odd.
<slapin_nb> hno: as malloc pool is more than 16MB it makes me wonder wtf
libv has joined #linux-sunxi
<slapin_nb> hno: I see early failure with if (!(chip->options & NAND_OWN_BUFFERS))
<slapin_nb> chip->buffers = memalign(ARCH_DMA_MINALIGN,
<slapin_nb> sizeof(*chip->buffers));
<slapin_nb> and the same code was working licke charm until I updated to ucrrent sunxi-current
<slapin_nb> chip->buffers is NULL after this
<oliv3r> slapin_nb: hey dude back working on mtd? :)
<slapin_nb> ARCH_DMA_MINALIGN is 64, sizeof is 10112
<oliv3r> slapin_nb: what branch are you using?
<slapin_nb> oliv3r: yep
<arokux> mripard, ERROR: Failed to allocate 0x4ec8 bytes below 0x40000000.
<slapin_nb> oliv3r: own repo
<slapin_nb> oliv3r: based on hno's sunxi-current
<arokux> mripard, there is no ram mapped to those addresses or what?
<mripard> 0x4000000 ? no
<mripard> this address is the RAM's base address
<oliv3r> slapin_nb: remember rz2k and yuq have done a lot of work on mtd
<oliv3r> slapin_nb: rz2k has done a whole lot
<slapin_nb> oliv3r: I play with u-boot, rz2k touched kernel, so we add to each other's work
<arokux> mripard, cannot understand why it fails if fdt_high 0x40008000. in this case ftd is before the kernel, so it cannot get overwritten
<slapin_nb> oliv3r: I will eventually switch to kernel this week
<oliv3r> slapin_nb: really? I know yuq did both, mtd for u-boot AND kernel; he and his teacher have a mtd booting system
<oliv3r> slapin_nb: i THOUGHT that rz2k also did some mtd u-boot work, buti could be wrong
<mripard> arokux: yeah, but if u-boot uses it for some kind of memory pool or something like hno suggested, it could very well mess up whatever we put there
<rz2k> i did not do u-boot
<rz2k> but it should be similar
<slapin_nb> oliv3r: well, I'm reworking on top of some yuq's work which is on top of my earlier work so it is just plain evolution
<rz2k> also most of my work was figuring out the ECC controller settings
<rz2k> and the conclusion is that the identify table is going to stay
<hno> Probably the right is simply to not define CONFIG_SYS_BOOTMAPSZ..
<arokux> :D
<slapin_nb> well, now I fight basics a bit, not really something creative...
<hno> it then falls back on size of first DRAM bank.
<arokux> hno, and it is?
<hno> unless overridden by bootm_* variables.
<hno> arokux, the amount of memory you have.
<slapin_nb> hno: do you have jtag attached on any of the boards? I'd like to ask you to test something...
<arokux> hno, but then there could be a problem with highmem vs. lowmem
<hno> arokux, there is no hightmem.
<hno> slapin_nb, not at the moment, and already late to bed..
<mripard> hno: we will use highmem for A20 and A31
<slapin_nb> hno, can you test tomorrow? just add memalign(64, 12000) anywhere late in u-boot (arm lib's board.c is good candidate) and see its result, if 0 then debug out why?
<arokux> ... Previously, we defined
<arokux> this to prevent the DTB from being relocated to the very end of RAM,
<arokux> cause boot failures ...
<arokux> which on most Tegra systems is within highmem, and hence which would
<oliv3r> slapin_nb: that's u-boot mtd + mtd kernel
<oliv3r> 1 second boot time to a QT app :)
<hno> 1 second is not possible. Power on sequence is 1 second before it loads SPL.
<Turl> hno: well maybe it was a second and a half then :P but it was insane fast
<rz2k> it is also squashfs buildroot with everything thrown out
<rz2k> so dont expect linaro to get that fast
<Turl> rz2k: I think /sbin/init was the qt app itself, statically linked
<hno> Yes it's fast.
<hno> Hmm.. maybe the poweron delay is only half a second.
<hno> No I remember wrong. It's very short.
<oliv3r> hno: check the video!
<oliv3r> it's awesome
<hno> I have.
<oliv3r> but really old
<oliv3r> 4+ months?
<hno> Yes we are slow in merging that stuff...
<oliv3r> i'll work harder :(
<hno> wonder what happened with the product.
<oliv3r> well that version couldn't even write image without livesuit due to the randomizer
<Turl> oliv3r: I believe they got that fixed
<arokux> mripard, hno so solution is to push CONFIG_BOOTMAPSZ to 256MiB?
<oliv3r> Turl: yeah it was statically linked and was 'init' or something really close to init; not much but still, quite usable for certain embedded projects
<oliv3r> Turl: yep they did
<oliv3r> Turl: i think to them, it's pretty much 'done' as it works mostly
<oliv3r> and rz2k was cleaning it up and makeing it work with more memory chips etc, making it more generic and mergeable
<oliv3r> but $job got in his way :(
<oliv3r> so it's awesome seeing slapin_nb picking it up again :D
<hno> arokux, or not set it at all.
<arokux> hno, or use uImage.gz!
<oliv3r> what if you only have 128 MiB ram (very unlikly, but besdies the point)
<hno> arokux, that only pushes the limit a little bit.
<oliv3r> what if you only have 32 MiB ram
<mripard> hno: I'd set it actually. but anyway, it's your call :)
<arokux> hno, correct.
<slapin_nb> oliv3r: I know it all
<oliv3r> slapin_nb: :D
<oliv3r> slapin_nb my hero!
<oliv3r> but bed time now
<oliv3r> nn all
<hno> mripard, I know.. not sure the last MB of memory is wise to use here. There is MALI etc around there which I guess distubs things a bit.
<arokux> hno, isn't it freed after parsing dtd?
<arokux> dtb*
<hno> arokux, not sure.
<hno> some kernels is rather aggressive about that memory reservation.
<arokux> ok
<hno> but probably yes.
<hno> arokux, can you try if it works for you without?
<arokux> since I've now booted with cubieboard.dtb on mele, what are the further steps. should I verify everything supported works fine?
<arokux> hno, without what?
<mripard> hno: what part of the memory space is reserved for mali ? higher ? lower? some other part ?
<arokux> hno, it works. tried long time ago
<hno> mripard, the upper part of the first 512MB I think.
<hno> if using static reservation.
<hno> fixed address.
<mripard> ok
<mripard> actually, I'm pretty sure it would work on an A10, it doesn't have enough RAM for highmem to kick in
<arokux> mripard, is it verifiable that everything you added for cubieboard works fine for mele too?
<ssvb> hno, mripard: mali does not really need this memory reservation
<mripard> hno: we can actually be pretty conservative about that now that we know the symptoms.
<mripard> we can set it to 128M, and see if it works for every one
<mripard> arokux: well, yeah, test that it works.
<mripard> ssvb: what do you mean?
<ssvb> mripard: mali has mmu and it is the least problematic hardware accelerator in a10 for anything related to memory allocation
<mripard> ssvb: ah, it has an IOMMU?
<ssvb> mripard: if you mean IOMMU as a kernel framework, then I'm not sure
<mripard> yeah, so you don't really need a contiguous physical memory chunk
<mripard> ssvb: nah, as an hardware block
<mripard> but yeah, the kernel also have a framework to handle those
<hno> ssvb, I know. Only worry about what happens on kernel who do this..
<rz2k> slapin_nb: oliv3r: i got a cubieboard around so I will test mtd with samsung NAND flash soon. no idea how soon.
cyp__ has joined #linux-sunxi
<rz2k> s/cubieboard/cubieboard2/
mripard_ has joined #linux-sunxi
torindel_ has joined #linux-sunxi
<hno> ssvb, mali have two memory allocations modes. kernel allocations of self managed region.
<hno> or self ...
libv has quit [Ping timeout: 248 seconds]
mripard has quit [Ping timeout: 248 seconds]
torindel has quit [Ping timeout: 248 seconds]
cyp has quit [Ping timeout: 248 seconds]
libv has joined #linux-sunxi
<ssvb> hno: yes, and also the mix of both
<rz2k> one of those has perfomance impact iirc
<ssvb> rz2k: there is no performance impact (at least I could not measure it)
<rz2k> check on odroid with dedicated memory cut and shared
<rz2k> it will differ
<rz2k> it did on 3.0 kernel when I was playing around with odroid
<ssvb> rz2k: do you have a link to some benchmark numbers?
<rz2k> nope, but I remember it clearly :p
libv has quit [*.net *.split]
<rz2k> not a proof, but atleast.
<rz2k> if you are going to invest some time into mali mmu - please check both modes
<hno> mmu settings likely differ, and also "allocation reliability". Shared memory means kernel may have eaten all memory for I/O buffers..
<ssvb> rz2k: and I remember clearly that there was no performance difference on sunxi at least in glmark2
<rz2k> then it might be something wrong with shared mem on odroid 3.0.y
<rz2k> also wanted to ask
<rz2k> any progress with a20 ? did you try to run g2d on it?
<ssvb> hno: we discussed this in the mailing list earlier -
<hno> rz2k, or maybe there is something wrong with dedicated mem on a10...
<ssvb> rz2k: g2d runs fine on a20, it seems to be exactly the same hardware as in a10
bsdfox_ has quit [Ping timeout: 264 seconds]
<ssvb> rz2k: and sun6i supposedly has a newer and better revision
<rz2k> really?
<rz2k> you mean whole SoC? :p
<rz2k> or we talking about g2d
<hno> so only sun5i is lacking g2d?
<ssvb> rz2k: the g2d sources for sun6i have code for setting premultiplied alpha, which is the feature we really miss
<rz2k> great
<ssvb> but sun7i kernel sources for g2d don't have it, and if we try to set the same bits in the g2d hw registers, then this has no real effect :(
<ssvb> hno: yes, assuming that sun5i is really lacking g2d
<ssvb> hno: it might be interesting to check android sources to see what they use instead
<ssvb> rz2k: do you have a20 hardware?
<rz2k> yes
<rz2k> a20-olinuxino and cubieboard2
<ssvb> have you already tried mali drivers there? ;)
<rz2k> no, but I know that it wont work that easy
<arokux> what kernel option is needed for DHCP to work?
<ssvb> rz2k: hmm, why?
<rz2k> iirc, platform definitions are missing
<rz2k> the stuff in devices.c in mach-sun6i
<arokux> IP: DHCP support <-- is on
<ssvb> rz2k: do android kernels support mali?
<rz2k> have no idea
<rz2k> they have very weird procedure of compiling mali
<ssvb> rz2k: maybe the needed platform definitions can be copy/pasted from android?
<rz2k> but i bet we need to setup the platform device data and memory cut
<rz2k> yes, i think it wont be that hard, but it wont work right now out of the box, people on the ML already tried it
<rz2k> it panics
<ssvb> well, they apparently did not try it the right way
utente has quit [Remote host closed the connection]
<ssvb> rz2k: I'm currently reworking the X11 DRI2 code for proper buffers swapping and vsync (which is now possible because the window resize bug is workarounded)
libv has joined #linux-sunxi
<ssvb> rz2k: and then will try to see what is necessary to get mali working on a20
<rz2k> what tree will you use?
<ssvb> rz2k: unless somebody else gets it done first :)
<rz2k> the HdG 3.4 or vanilla 3.3?
<ssvb> 3.4 most likely
<ssvb> 3.3 is not very interesting in general
\\Mr_C\\ has quit []
<arokux> oliv3r, still here? what is needed for mainline to support nand and sd card (mmc?)?
bsdfox has joined #linux-sunxi
<rz2k> arokux: please read the wiki
<arokux> rz2k, I am, but with lots of three letters words it's difficult
<arokux> :)
<rz2k> DMA needs to be implemented using the kernel's DMAEngine framework
<rz2k> there is a guy who already wants to do that
<arokux> rz2k, is wireless independent of everything else?
<rz2k> dma is well documented, try reaching mdp if you want to help
<rz2k> hmm
<rz2k> what wireless do you mean
<rz2k> ?
BJfreeman has quit [Quit: had a good time]
<arokux> wifi adapter
<rz2k> in sunxi devices many wireless stuff is done using usb host
<rz2k> or SDIO
\\Mr_C\\ has joined #linux-sunxi
<arokux> rz2k, I need to get wireless working.
<arokux> so I'd like to work towards it
<rz2k> how your wireless card is connected to the sunxi SoC?
<arokux> rz2k, how could I know? :)
<rz2k> google the chip name?
<rz2k> usually it is realtek something, and usb is used
<rz2k> and usb needs a driver, which we lack right now
<rz2k> so go work on usb support :p
<arokux> the card is at the lower left corner
<rz2k> mele usb wifi, I have mele a2000 around
<rz2k> s/mele/mele has/
<arokux> rz2k, yep, mine is a1000
<rz2k> so you are tied with usb support then
<rz2k> if you will not have it - you wont get that realtek wireless working
<arokux> rz2k, ok, USB Gadget driver is something else or this is also needed?
<rz2k> that is USB-OTG
<rz2k> you dont even have that connector on mele
<arokux> rz2k, I doo
<arokux> do*
<rz2k> if you soldered it to the pinheader - then yes :)
<rz2k> and no, your wifi is connected to USB-HOST
<rz2k> which is different block
<rz2k> USB-OTG is separated from USB-HOST's
<rz2k> and usb-otg is actually MentorGraphics Inventra controller
<arokux> where do you know all that?
<rz2k> common sense? sorry :p
<rz2k> just had a lot of experience with ARM boards
<rz2k> and embedded devices in general
<arokux> rz2k, no need to solder, just disassemble old usb mouse :)
<arokux> rz2k, there are pluses, next to new files here
<arokux> all of them have to do something with USB only, or with USB To Go to?
<arokux> too*?
<rz2k> hmm
<rz2k> dont quite remember, but otg is in the /gadget/
<rz2k> you should ask someone who worked on usb
<rz2k> I remember techn_ did
<rz2k> and mnemoc when he had time
<arokux> rz2k, good
<arokux> rz2k, thanks
<rz2k> expect USB-host to be integrated really ugly way
<rz2k> since allwinner code is bad
<rz2k> and can use dirty hacks all around
<arokux> rz2k, well, i'm a beginner, so......
<rz2k> read Robert Love - The linux kernel development
<arokux> rz2k, too simple
<rz2k> and Greg KH - Linux device drivers
<arokux> rz2k, better, but i'm a bit better then that.
<arokux> ok, but this usb host, does allwinner use some standard hardware part?
<rz2k> thats the problem
<rz2k> they dont as it seems
<rz2k> for USB-OTG they used MentorGraphics core that they purchesed
<rz2k> but host seems to be writted from scratch
<rz2k> written*
<arokux> rz2k, so it's a new device with the code only?
<rz2k> yes, you will need to describe new OHCI/EHCI controller
<rz2k> in mainline
<rz2k> read the USB core for details or some other USB controller sources
Offshore has quit [Ping timeout: 240 seconds]
<rz2k> like Freescale one, it is in the mainline iirc
<rz2k> or OMAP4 one
<arokux> rz2k, in the data sheet wifi is connected to some card controlle 3
<arokux> rz2k, it's different in mele?
<rz2k> hmm
<arokux> it's just a picture though...
<rz2k> no idea, but I bet wifi is on usb on mele, i dont think they would use SDIO one
<rz2k> without real need
<rz2k> usb ones are cheaper
<arokux> rz2k, not that i disbelieve you, but how can I be sure?
rzk has joined #linux-sunxi
<rzk> arokux: sorry, got disconnect.
<arokux> rz2k, not that i disbelieve you, but how can I be sure?
<rzk> google the chip name of your wireless card and check info - usually these chips are very dedicated - like one model only support one interface
<rzk> and other with different name supports other
<arokux> rz2k, ok, need microscope though, cannot read name of the chip
<rzk> also
<rzk> your card has 6 pins right?
rz2k has quit [Ping timeout: 240 seconds]
<arokux> rzk, where?
<rzk> wireless card mounted on the board
<rzk> now lets count: 1 pin for +5VCC, 1 pin for GND, 2 pins for antenna, 2 pins for D+ and D- of usb
<rzk> everything counts right :p
<arokux> rzk, yes, mine is identical
<arokux> to yours
<rzk> so it cant be SDIO wifi
<rzk> it would need more pins
<arokux> good
<arokux> rzk, hm.. there could be some from the other side :P
<arokux> rzk, QF9700 one chip USB 2.0 ethernet devices
<arokux> this is something strange.. we do not have this hardware,right?
naobsd has quit [Quit: Page closed]
<rzk> hmm?
<rzk> only Texas Instruments part is there
<rzk> the ethernet is done using the Realtek RTL8201CP
<rzk> which is MII PHY ethernet driver, iirc
tzafrir has quit [Read error: No route to host]
bsdfox_ has joined #linux-sunxi