<Astralix1>
I have a question about the procedure.. again
<mmind00>
fire :-)
<Astralix1>
If you need to provide the modificationas as patched to the mailinglist, where is the kernel you develop actively on?
<Astralix1>
github?
<Astralix1>
So what do I have to clone, if I would like to contribute to your work?
<mmind00>
as I have written before, my current dev kernel is not uploaded anywhere, as it is to messy ... I will provide some sort of dev kernel once the merge window closes for 3.11 (should be in 2.5 weeks)
<mmind00>
github would probably be the right place to work together
<Astralix1>
I would prefer to start things easy, and it might take a while for me, till I am ready to post patches in the kernel mailing lists. (Even I already booked some of them)
<mmind00>
:-) sure
<Astralix1>
So, just throw the kernel into github and set some guys to be project masters
<Astralix1>
or collaborators
<Astralix1>
There are so many places to build around the RK SOC, there is qork for everyone
<Astralix1>
work
<Astralix1>
And I can test everything as I have 2918, 3066 and 3188 and things like Scope, Analyzers...
<mmind00>
as I said it's currently very hard to gather all the changes (and their dependencies from other kernel devs) that are distributed over different trees together again,
<Astralix1>
Yes, I see. Are there more people adding to this rockchip tree? And do we have a list of already compatible IPs inside the SOC?
<mmind00>
no, but some rockchip changes are based on changes from other people ... i.e. they added features for their soc and generalized stuff that I'm using too
<Astralix1>
Looks like clock setup is missing or unknown. But I think we have that as source code
<mmind00>
clock setup is incomplete as the relevant devicetree bindings for generic clock bindings are just coming in
<mmind00>
i.e. currently only the gates are controllable and the rest depends on the bootloader setting it up correctly
<Astralix1>
so for now, the clock is used as bootloader prepares it?
<Astralix1>
ups
<Astralix1>
so afaik we should think about having a more open bootloader...
<mmind00>
so you currenty get a whopping 600mhz the cpu is running at :-)
<mmind00>
this clock state is only an intermediate step ...
<mmind00>
i.e. I have already the divider and mux bindings sitting here, but they are depending on the generic clock bindings from the clock maintainer
<Astralix1>
600MHz? I didn't check, but DDR is limited to 300MHz while it can do 400MHz in any know design and in some it can do more than 566MHz
<mmind00>
no, the apll is running at 600mhz (which feeds the cpu)
<Astralix1>
yes
<Astralix1>
as I sasif, I didn't check
<Astralix1>
I need finger calibration...
<Astralix1>
But that is , what I told
<Astralix1>
You have all this and anyone supporting you doesn't have it. So either work is not done or work is done duplicate...
<Astralix1>
we should set up rockchip-linux-dirty @ github and put everythig inside that is known
<mmind00>
? I don't understand ... the 600mhz I simply know, because I inserted a printk(clk_get_rate(...)) for every clock that gets set up in the original rockchip kernel
<Astralix1>
I never checked that line in the debug output
<Astralix1>
as long as lcd is not showing up, WiFi not working or compiler doesn't generate bootable code, it was not of interest if the cpu is at 300 or 600
<Astralix1>
I didn't tell that you're wrong, I simply never checked the output for how fast my CPU is.
<Astralix1>
In the first days we couldn't influence the cpu speed, as clock related things where closed source and later I worked on other things
<mmind00>
I glaub wir reden einfach nur gelegentlich aneinander vorbei ;-)
<Astralix1>
may be jochen checked that :)
<mmind00>
what I really meant, was only that the apll feeding the cpu gets set to 600mhz by the bootloader and during kernel startup they set the plls to their target values
<mmind00>
which the current mainline code doesn't do currently
<Astralix1>
ah, ok, so straight through
<mmind00>
correct, and something to fix later
<Astralix1>
I guess it is not a problem to implement of-tree system for that. It could get interesting to see how this works together with power-management and dynamic clock rate adaption
<Astralix1>
do you want to skip the 2918 completely?
<Astralix1>
and there is a 3168 missing too
<mmind00>
2918 is a cortex-a8 ... i.e. I'm currently focussing solely on the cortex-a9 ones (2928 and onwards)
<mmind00>
I use only the stuff where I can find sources for ... as the 3168 shouldn't be to different it shouldn't be a problem for an interested party to add the necessary support in the right places
<mmind00>
on both you should at least get an early boot console with the right debug uart selected :-)
<Astralix1>
Yes, for sure
_whitelogger has joined #linux-rockchip
Astralix1 has quit [Read error: Connection reset by peer]
Astralix1 has joined #linux-rockchip
leowt has joined #linux-rockchip
<leowt>
hi!
naobsd has joined #linux-rockchip
<Astralix1>
hi guys
<naobsd>
hello
<leowt>
yo
<naobsd>
mmind00: I know some person who're trying to make a product with RK2918. he said he can offer some eval boards with kernel source. do you have interest about it?
<naobsd>
and he also have some rk3066 board which was canceled due to lack of source... he have some information about hardware configuration, so it may be possible to make working kernel from source on the net
<mmind00>
about the rk2918 I'm not really sure ... my current focus is on the cortex-a9 ones, so I think someone else might have to get interested in the cortex-a8 socs
<Astralix1>
lol, are 2918 sdks now on sale?
<naobsd>
mmind00: I see
naobsd has quit [Changing host]
naobsd has joined #linux-rockchip
<naobsd>
Astralix1: I think I didn't talk any new thing...
<Astralix1>
??
<naobsd>
Astralix1: I think 2918 sdk should be available when it was released for maker