<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
<oliv3r>
mind.be
<mripard>
yep
<rellla>
utente: not atm
<oliv3r>
'we are hiring'
<mripard>
that's the only one I can think of right now
<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>
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>
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 free-electrons.com
<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) :)
<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?
<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>
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.
<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 https://github.com/rellla/vdra10/tree/master/PLUGINS/src (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/
<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
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?
<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?
<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...
<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?
<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.
<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...!
<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
<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
<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?
<hno>
CONFIG_SYS_BOOTMAPSZ
<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>
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?)?