MK908 Android 4.2.2 Complete SDK Released!!!!!!!!!!!!

[mo123]

See link below for more info

http://www.cnx-software.com/2013/08/10/mk908-rockchip-rk3188-mini-pc-android-4-2-2-sdk-leaked/

http://www.armtvtech.com/armtvtechforum/viewtopic.php?f=410&t=2194

Maybe someone can upload it to Github, so that everyone can make improvements to the firmware for different devices.
Wonder if it can be modified to work on other Mini PC's like MK808 & MK808B?

[thesawolf]

I've been looking through and playing with this since this morning (I beat your post by 3 hours over in the kernel dev threads.. hehe). It seems to be a bit outdated and for development boards.. but it's definitely something to work on and compare notes and will definitely aid in putting out some stuff (for the MK908 at least) and with some modifications to the kernel and some of the device settings, would be feasible to get it working for other AMPs. Thankfully I have a MK908 and this will go a long way in my dev efforts for that. I've already seen some improvements that I can incorporate for my CM rom

[Guest]

A question for all:

Rockchip want another 6000$ for the new sdk2 with multi-windows ?

or is free for all that buyed the sdk first version ? (now leaked)

if want another 6000$ i can understand why we have this leaked old version.

is legal sell open source and under gpl software ?

this sdk leaked are very old, but good to understand some tricks.

[hoabycsr]

Thank You!

Thanks so much! I used this to build a new kernel and it's a great source for me to have. I'll get into the rest of it later. So nice to have. Thanks again!

Hoaby

[fonix232]

A question for all:

Rockchip want another 6000$ for the new sdk2 with multi-windows ?

or is free for all that buyed the sdk first version ? (now leaked)

if want another 6000$ i can understand why we have this leaked old version.

is legal sell open source and under gpl software ?

this sdk leaked are very old, but good to understand some tricks.

It is not Rockchip who asks for money for the SDK (they provide it to anyone who buys their SoC or boards in higher volume for free), but the manufacturer who actually makes the device and the final software. And yes, they do ask for another x thousand USD for the update.

It is not legal, at least for the GPL source, to sell it. But it is China, we can't do anything against them, when I threatened a company who are selling a T428 clone (exact same stuff, they claim they designed and manufactured the sticks), their answer was that I won't get the kernel source code, or anything else, unless I either make a 1000pcs+ order, or pay 15000USD for the SDK. And that I can go to any lawyer and sue them, etc., because they clearly know that we cannot do anything against them.

[thesawolf]

well.. at least I was able to pull the code that gets the power on light working again on the MK908 and some extra bluetooth stuff that I'm still testing out.

As for the SDK (taken from GNU.org) (notice the bolded, underlined area below.. yay for leaks):

Does the GPL allow me to sell copies of the program for money? (#DoesTheGPLAllowMoney)
- Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.)

If I distribute GPL'd software for a fee, am I required to also make it available to the public without a charge? (#DoesTheGPLRequireAvailabilityToPublic)
- No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public.

[Legitsu]

Having the source for every RK3188 stick is completely unnecessary the hardware is all identical save for a few minor differences there is ZERO advantage to be had in having the source for the T428 vs the generic tree there is no point to it

what we do need is someone to FORK this codebase and work on getting it compatible with ALL RK3188 devices so we have a stable tree to fork from and work on experimental code
should't take much just need different wifi,BT,HDMI --drivers & configs all that can be done with a few IFDEFs or even easier would be to write some code that allows you to build for a specific stick make MK908 or Make MK908III or make CX-919
ect ect

[thesawolf]

Having the source for every RK3188 stick is completely unnecessary the hardware is all identical save for a few minor differences there is ZERO advantage to be had in having the source for the T428 vs the generic tree there is no point to it

what we do need is someone to FORK this codebase and work on getting it compatible with ALL RK3188 devices so we have a stable tree to fork from and work on experimental code
should't take much just need different wifi,BT,HDMI --drivers & configs all that can be done with a few IFDEFs or even easier would be to write some code that allows you to build for a specific stick make MK908 or Make MK908III or make CX-919
ect ect

I already have a kernel source that attempts to be device neutral and have made define adjustments based on the devices people have sent me info on. It's a good place to start from. This leak, however has an older kernel source (but with some revealing config stuff we needed on the MK908's at least) and all the stuff to build a ROM from (however, stock it may be). We can see the changes Tronsmart (or whomever) made to AOSP (which should placate people like Strauzo that bitch about all the "chinese" stuff in the stock rom)

[Legitsu]

I already have a kernel source that attempts to be device neutral and have made define adjustments based on the devices people have sent me info on. It's a good place to start from. This leak, however has an older kernel source (but with some revealing config stuff we needed on the MK908's at least) and all the stuff to build a ROM from (however, stock it may be). We can see the changes Tronsmart (or whomever) made to AOSP (which should placate people like Strauzo that bitch about all the "chinese" stuff in the stock rom)

I know just kind of sick of threading the post from people that don't even code having a fit about not having the source tree to "insert_name_of_Generic_RK3188_device_here"

[fonix232]

I know just kind of sick of threading the post from people that don't even code having a fit about not having the source tree to "insert_name_of_Generic_RK3188_device_here"

Well, what we can do is to make an rk31-generic tree, then inherit them, and overwrite some values for the separate devices. This way we can always make small changes that updates everything, yet have separate device configs for all of us.

For starters, I'd like to implement the new, FUSE-based internal SD layout (that being, instead of separate /sdcard and /data partitions, there's a huge userdata, and from that we fuse-mount a folder as /storage/emulated). This would free up much wanted space, AND give us the chance of not having 8-10 separate parameter files for all devices.

Thesawolf, your solution, while great for implementing on top of an existing kernel, is just that: implementation on top. I'd rather go deeper and have a kernel that works on all RK3188 sticks, without problem. The first step for this would be rewriting the rkwifi module's code, so that it can detect the device and use it accordingly, and not just the hard-coded one. Then repeat this step for every module that controls a group of modules, etc.

[Legitsu]

Well, what we can do is to make an rk31-generic tree, then inherit them, and overwrite some values for the separate devices. This way we can always make small changes that updates everything, yet have separate device configs for all of us.

For starters, I'd like to implement the new, FUSE-based internal SD layout (that being, instead of separate /sdcard and /data partitions, there's a huge userdata, and from that we fuse-mount a folder as /storage/emulated). This would free up much wanted space, AND give us the chance of not having 8-10 separate parameter files for all devices.

Thesawolf, your solution, while great for implementing on top of an existing kernel, is just that: implementation on top. I'd rather go deeper and have a kernel that works on all RK3188 sticks, without problem. The first step for this would be rewriting the rkwifi module's code, so that it can detect the device and use it accordingly, and not just the hard-coded one. Then repeat this step for every module that controls a group of modules, etc.

agree and drivers for all known wifi and bluetooth chipset should be included

[fonix232]

agree and drivers for all known wifi and bluetooth chipset should be included

They are actually there But never used, thanks to the stupid way rockchip handles wifi.

[Legitsu]

They are actually there But never used, thanks to the stupid way rockchip handles wifi.

whats wrong with using insmod and some scripts

[fonix232]

whats wrong with using insmod and some scripts

They still won't work. rkwifi defines the chip name, and only accepts drivers designated to that. You think I haven't tried yet?

The way it works, by my understanding (and heavily stylized):
WiFi chipset - WiFi .ko module - rkwifi.ko - kernel - Android system and framework

Meaning, the system will only accept a wifi interface through rkwifi, and rkwifi is hardcoded to load only one type of wifi module. BUT, if we can change how rkwifi works, and instead of a hardcoded value it would try to detect the wifi chipset, it could load the proper .ko, meaning all we have to do is to compile the module, then drop it into /system/lib/modules/, and done.

[vlsi2000]

MK908: support for other resolutions

Thanks so much! I used this to build a new kernel and it's a great source for me to have. I'll get into the rest of it later. So nice to have. Thanks again!

Hoaby

Would it be possible to add other screen resolutions to use MK908 with computer monitors?
I have some spare LCD monitors with 1600x1200 resolution.
If MK908 can support such resolution, it would turn them into nice media players.
Right now MK908 picks up 1280x720 when connected to the monitor and the aspect ratio is not right.