<naobsd>
mask rom mode, which needs to push bootloader to make rkflashtool work
<naobsd>
bootloader mode, bootloader is loaded from nand
<naobsd>
structure of RK30xxLoader(L)...bin is almost known, and USB protocol is almost known too, but
<naobsd>
there is unknown 2bytes in USB protocol, it prevents to make rkflashtool usable for mask rom mode
<naobsd>
RKAndroidTool works fine for both, of course
<naobsd>
in short, with rkflashtool, we need working bootloader in nand
<mmind00>
yeah, but it's normally present anyway ... only one should not accidentially overwrite it :-)
<naobsd>
yes :)
<naobsd>
fortunately rkflashtool can't rewrite/erase bootloader area :)
<naobsd>
it's enough to play with kernel thing
<naobsd>
I'll try to investigate "read/write RAM" protocol
<naobsd>
I hope it will be useful for kernel development
<naobsd>
btw, how do you think reusing kernel source for some RK30/31 devices floating around on the net?
<naobsd>
or are you trying to do everything yourself w/ mainline source?
<mmind00>
for mainline real reusing is not possible ... while the Rockchip sources are a lot better than others I've seen they still are not of mainline quality, so need a lot of rework
<mmind00>
but thankfully someone from Rockchip choose wisely to not reinvent every component in the SoCs
<mmind00>
so things like the mmc, uat, spi, timers are all Synopsis,Designware IPs
<mmind00>
(with drivers already present)
<naobsd>
yes, I read it from your commit log :)
<naobsd>
very nice
<naobsd>
but NAND is secret :(
<mmind00>
but I have a working mmc, so I'm fine
<naobsd>
I see :)
<mmind00>
and hen looking thru Rockchip sources, this whole secrecy stuff seems to be improving (recent releases seem to have real clock_data.c files instead of the uu-encoded stuff)
<naobsd>
sometimes kernel source for some specific product which uses RK SoC is released/leaked. many people want to use it on his own device,
<mmind00>
so I'd think not all hope is lost :-)
<naobsd>
but in many cases device specific code is missing, then it's not useful for people's daily use(e.g. watching movies)
<mmind00>
true and the changes are most of the time done in a hacky way, so it's also not easy to separate them
<mmind00>
but I'll let other people worry about "daily use" ... my primary interest is experimenting with the lower-level kernel stuff, i.e. getting basic components of the SoC running on a mainline kernel, smp and so on
<naobsd>
I always thinking it's really worthful to spend time to hack leaked source for another device
<naobsd>
I like low level things too.
<naobsd>
and I know other people don't like it ;)
<naobsd>
I'll try your code
<mmind00>
hehe ... "upstream sources" always make my eyes bleed ... so I don't want to touch them more than necessary usually
<naobsd>
after soldering uart pins on my device ;)
<naobsd>
sorry, away for a while
<mmind00>
hehe, ok
<mmind00>
just for the record, there are a lot more patches involved than the ones in arm-soc, there is also necessary stuff in the pinctrl- and clock-tree
<mmind00>
so the best course of action would probably be to wait for the next "linux-next" tree and use this then
<naobsd>
I see. I'm not Linux guy, so I'm not sure about such an staging(?) flow
<mmind00>
hehe ... for the initial rockchip stuff I it was crazy :-)
<mmind00>
I did try to get all the patches that I sent together again in my development tree ... but gave up at some point
<Astralix1>
hi there
<mmind00>
hi :-)
<Astralix1>
got an invitation to land here, so here I am :)
<mmind00>
I got the same invitation :-)
<Astralix1>
Joint forces against rockchip code
<Astralix1>
so whats up today?
<mmind00>
hehe ... compared to others Rockchip code is actually more on the "nice" side :-)
<Astralix1>
don't know, did kernel coding for Atmel and Freescale before...
<Astralix1>
But compared to the DVD system code I had to work with some years ago, yes rockchip is far nicer than that
<Astralix1>
So there are some thet got linux booting on Rk3066 and 3188 the last few days
<Astralix1>
I am at the cleanup of the work and try to push that code back to our github in the next three days
<Astralix1>
so, naobsd, I recall you name. Saw you there in the forums... XDA?
<Astralix1>
mmind00 doesn't trigger my mind, where are you from?
<naobsd>
I'm fun_ at XDA. my site is androtab.info.
<mmind00>
nowhere :-) ... just working a bit on basic mainline support for rockchip socs
<mmind00>
next "linux-next" should probably happen somewhere tomorrow or the next days
<mmind00>
hi leowt
<naobsd>
hmmmmm I see
<leowt>
We should also have the sources released for 30xx and 31xx
<leowt>
I see that there are some 3.0.xx already touched by community somewhwre in github
<naobsd>
I'm preparing 3.0.36 source for MK802IV and bqCurie
<leowt>
thats what? 3066?
<naobsd>
at first I'll push non-touched one as for reference
<naobsd>
3188 and 3066
<naobsd>
as far as I know, they are latest source on public, and some people are working based on them
<leowt>
Hmm, i have an 3168, arent 3188 sources supposed to be the same?
<mmind00>
isn't 3168 dual core with the powervr gpu?
<leowt>
Yes it is
<leowt>
Pretty cool power consumption btw
<mmind00>
and no from what I've seen so far all the different socs share a lot, but also differ at critical points
<mmind00>
for example the clock trees are always somehow different
<leowt>
mmind00: there are defconfs with 8168 name with the 3188 sources
<leowt>
Including a kernel option to select 3 our 4 kinds of 3168 boarda
<leowt>
boards
<leowt>
Tried to do a simple compile but it failed
<leowt>
Still got to see it with more attention
<leowt>
But the supplied defconfs for 8168 gets errors compiling
<leowt>
Some work to do there, supposing there are all the 3168 sources in that kernel, being not the problem itself
mmind00 has left #linux-rockchip ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"]
mmind00 has joined #linux-rockchip
leowt has quit [Quit: Qui]
leowt has joined #linux-rockchip
<leowt>
i see that github/linux-rockchip got some setting up act
<Astralix>
So, since i started I collected some goods like another Loox (2918), a Xelio 10pro (3066) and a Tronsmart MK908 Android TV stick powered by a RK3188
<leowt>
make[1]: *** No rule to make target `arch/arm/mach-rk30/clock_data-rk3066b.o', needed by `arch/arm/mach-rk30/built-in.o'. Stop.
<leowt>
hmm
<Astralix>
clock is sort of secret to rockchip...
<mmind00>
why do you want to build clockdata for the rk3066b?
<Astralix>
You should have either a clock_data.uu and the clock_data.o is commented out in the Makfile, or you have the clock_data.c
<Astralix>
if you have .c romve the comment in the Makefile
<Astralix>
...remove...
<Astralix>
mmind00, do you have some full manuals on these RK chips?
<mmind00>
clock_data-rk3066b is valid, but shouldn't probably be built for a 3168 target
<Astralix>
nope, not for that, lets check what I have
<mmind00>
sadly no
<Astralix>
none of the datasheets?
<mmind00>
nope
<Astralix>
I thought you work for...
<mmind00>
yep, but we get a sort of working kernel tree
<Astralix>
sort of... yes I know that
<leowt>
so
<Astralix>
you like a datasheet?
<leowt>
so can i understand
<leowt>
they modify clock_data-rk3066b for each chip
<leowt>
?
<mmind00>
any time ... the only thing I know is this small excerpt that is floating around everywhere
<mmind00>
no, there are two variants of the rk3066 ... a and b
<Astralix>
Hmm... even the 26MB sized one is not complete. PMU, MALI, VPU and some other units missing in it
<mmind00>
there is a datasheet around? ... :-)
<Astralix>
hmm...
<Astralix>
need you mail address
<leowt>
i see no clockdata file at arch/arm/mach-rk30
<leowt>
there is one at arch/arm/mach-rk3188
<Astralix>
leowt, wihich github do you use?
<mmind00>
wanted to ask the same right now :-)
<mmind00>
Astralix: heiko@sntech.de
<leowt>
so it seems that there is not files for rk8168
<leowt>
Astralix: sorry?
<mmind00>
leowt: sadly I also haven't seen the rk3168 being mentioned in any tree
<leowt>
leojrfs @ github and gmail
<leowt>
another gpl violating issue?
<Astralix>
leowt, where did you get your code from?
<mmind00>
leowt: I think we wanted to know which kernel source you're using ;-)
<Astralix>
uih, that one... Alok... He is from the Omegamoon crew and he has the kernel from us.
<Astralix>
so you see it's all linked together
<mmind00>
also the released kernel sources most of the time are not containing support for all previous socs
<Astralix>
so to get that compiled you should switch to Gallands repo
<Astralix>
mmind00, none of them
<mmind00>
you can see the clockdata for the rk3188
<leowt>
i see
<Astralix>
if there is a kernel having support for more than only one of them, it is self crafted and not an official releas of any tablet company
<mmind00>
but the remnants of the rk30xx support probably only contains the stuff the rk3188 is reusing
<leowt>
:/
<Astralix>
not directly. Rk31 is using stuff of 29/30 but the unused code of these is just left as it was on the point of fork
<leowt>
y they just wont release it
<Astralix>
They do not develop on 29 anymore
<leowt>
im talking about rk8168 files
<Astralix>
hey even do not really do anything on 30 anymore. Only some 31 support, that's it.
<Astralix>
ah, yes the 31xx is supported
<Astralix>
you only have to get 5000USD an to sign an NDA
<leowt>
yeah, but im here stuck just because there isnt 3168 sources
<Astralix>
3168 is a dual-core 3188 I guess?
<Astralix>
Or do you have different GPU?
<mmind00>
I think they have a powervr or so
<leowt>
it is dual-core
<leowt>
and
<leowt>
gpu is powervr
<leowt>
so yes it is different
<Astralix>
örks...
<Astralix>
We had such trouble with vivante as they didn't even answer emails... then we where so happy getting MAIL as ARM supports open source development on that one.
<Astralix>
And now they're changing to powerVR... We need to check with Freescale. They use that too on their iMX series chips
<Astralix>
GPU is so much hard work on disassembling and trying to get it glued again
<Astralix>
mmind00, did you get the datasheet?
<Astralix>
if you guys do not have dropbox, then register through my link. Will rise my limit a bit there
<leowt>
i have it
<leowt>
;)
<mmind00>
Astralix it's stuck in the greylister, so should arrive in some miutes
<Astralix>
ah, ok
<Astralix>
that reminds me, that I do not know what you are doing, leowt
<leowt>
Astralix: sorry?
<Astralix>
job, family, kids, shoesize... ;)
<Astralix>
I don't like to login to PRISM all the day to request that information
<Astralix>
makes me feel like spying...
<mmind00>
haha
<leowt>
well, im a young entrepreneur =P
<mmind00>
you could also ask the british service
<leowt>
product development (kind of a R&D dedicated company)
<leowt>
i can be described as de devops guy xD
<Astralix>
mmind00, why asking for a copy, iff you can have the original...
<Astralix>
leowt so it is half a business act in here
<mmind00>
ok, the archive is prism, but the live data are the brits :-)
<Astralix>
lol
<leowt>
Astralix: hmm, i hope so
<leowt>
hahha
<leowt>
i have plenty toys
<leowt>
so just wanted to give rkchip a try
<leowt>
i liked 8168 power consumption
<Astralix>
Ok, so want you got for Android or Linux?
<Astralix>
based on that RK?
<leowt>
there will be no real business until the fall of year so, it is a *just starting* startup
<Astralix>
ha, ok, then wish ou good luck and stay stong. Most times the first three years are hard, after then it will get better
<Astralix>
So, lets see...
<leowt>
i am still exploring possibilities with my mates, but the android + libhybris its pretty cool
<leowt>
since our work is embedded Qt heavy
<Astralix>
We need to get uBoot running and kill that bullshit rkXXnand.ko driver
<Astralix>
then we are free on that chips
<Astralix>
So, anyona known ro work on uBoot or redboot on that chips already?
<leowt>
redboot is used on rk?
<leowt>
got, i only know it from fonera devices
<leowt>
=P
<leowt>
my fon2100 still runs
<leowt>
=P
<Astralix>
no, there is an encrypted closed source bootloader on it
<Astralix>
but I have the loader and I got it decrypted and I know how to handle a disassembler...
<leowt>
ur evil
<leowt>
hah
<leowt>
so
<leowt>
i will got to wait untill some rk8168 specific sources are released
<leowt>
the android to ubuntu touch kernel is so close
<leowt>
damn
<leowt>
=P
<leowt>
only for a couple of options
<Astralix>
I do hardware-near dev since I was 9. I built my Apple ][ replica, when I was 11. Since then I programmed Fortran, Ada, Lisp, Pascal, C and I programmed Assembler for about 20 different chips including DSP
<Astralix>
And as RK did violate GPL so much, I didn't have any bad feelings about using disassemblers or so
<Astralix>
I am pretty sure you can use the rk3188 kernel with almost no changes
<leowt>
Astralix: there were pentium 2 cpus already wen i was 9
<Astralix>
But you will have to solder a serial debugger to your device
<leowt>
i wish i could have lived at that age
<leowt>
=P
<leowt>
Astralix: first thing i have done
<Astralix>
hmmm, It doesn't make a difference.
<leowt>
searching for uart
<leowt>
and soldering thinks
<leowt>
having a serial console is a requirement for me
<leowt>
=P
<leowt>
it is a generic *crap* tablet board
<Astralix>
at that time a 20MHz scope was fast enough, today you need a 100MHz minimum. But at that time the 20MHz scope was much more expensive as a 100MHz is today
<leowt>
but i am happy to share pics
<leowt>
with the uart location
<Astralix>
just upload and I support
<Astralix>
I have found it on all
<leowt>
Astralix: i am saying that the first thing i have done was to open it up
<leowt>
and locating the uart
<leowt>
and already have uart since the 0 day
<leowt>
=P
<Astralix>
actually most modern 31xx have them on the lower side where almost no parts are
<leowt>
sec
<Astralix>
??
<Astralix>
you need USB-Serial converter with logic levels. So 3.3V max.
<Astralix>
cpy that one, extract the arm toolchain to /opt/ and then use is
<Astralix>
it
<Astralix>
It is a gcc 4.4.3 and verified to work
<leowt>
ok tnks
<leowt>
i will be keeping an eye on irc
<Astralix>
so, cul8er
<leowt>
every ~20 mins
<leowt>
brb
<Astralix>
mmind00, still there?
<mmind00>
barely :-) ... reading and trying not to fall asleep
<Astralix>
just some questions
<Astralix>
and then /me bed too
<mmind00>
hehe
<Astralix>
so, if I have some code in c that is provided by rockchip only as .uu, how to handle that?
<Astralix>
can I push that to you / mainline?
<mmind00>
nope
<Astralix>
I guessed that
<Astralix>
how to handel that?
<mmind00>
i.e. the uu stuff is only an encoded .o
<Astralix>
yes
<mmind00>
which is unacceptable in any case
<Astralix>
ok, two scenarios
<Astralix>
I have sources of files, that where former .uu but where opened by some manufacturers when putting sources online
<Astralix>
I think I can consider these <open>
<Astralix>
an can include them in my work an push the
<Astralix>
them
<mmind00>
yep ... also the rockchip files contain a gpl header, so you should be fine
<Astralix>
there are others, that I disassembled after uudecoding the file and threwing the .o into IDA
<naobsd>
good morning
<Astralix>
So I replicated the c code... sort of...
<Astralix>
moring sir
<naobsd>
what I did on github is, just pushing 2 kernel source, one for rikomagic MK802IV, another for bq Curie
<Astralix>
Ah, can I have the link to the kernel archive again, please?
<Astralix>
saw that
<Astralix>
Omegamoon and Galland made MK908 and S400 sticks booting linux and I am cross checking for booting android
<naobsd>
just for reference. I used AOSP android-3.0 branch as a bese. branch point may not be correct, but it should be helpful to see diff from vanilla(android-3.0) source