Open remay opened 3 years ago
I think so, it would be amazing if more controls could be opened up to be configured through a kernel manager. Thanks for working on this btw, I really appreciate it
it would be amazing if more controls could be opened up to be configured through a kernel manager.
I think that's unlikely (at least from me) - however, assuming I can generate some time to take a look at the alternate kernels linked above, and I can confirm that they work then I should be able to make a way for us to choose and install a different kernel.
I suspect we wouldn't change the kernel used by the recovery system to keep that stable.
Nearly at my wit's end here trying to learn how to compile a kernel and use it in the Hudl. I finally managed to compile the kernel sources successfully after finding the right defconfig in the kernel source (it was in the root folder the whole time) but can't get it to boot. The kernel partition is redundant I'm pretty sure but replacing the kernel in the boot.img causes the Hudl to fail and go straight to recovery. I can unpack and repack the the stock boot.img no problem so it means I'm compiling the kernel wrong. I'm using the same toolchain and this kernel source https://github.com/martinbrook/tesco-hudl which is the only one I can find. There's frustratingly little documentation and after a lot of hours down the drain it's gotten very annoying with rockchip's custom modifications Any ideas?
I've failed to find evidence that anyone actually managed to build a new kernel from the published sources. I have a copy of the last set published by Tesco, whichI think matches the source tree that you linked to in Github. I'm impressed that you got anything to even build, and if you have time then writing up what you 've done so that other can benefit would be great - if you'd like I can try to work out how to give you permission to add to the Wiki in this repo?
I can't be 100% sure but the impression I got from the tread I linked was that this was someone tweaking the existing kernel rather than building entirely from source, but I can't be sure.
As per the stock image the kernel partition is not used and there's a kernel (the smae one) packed into both the recovery and and boot images. I believe that it's possible to remove the kernel from either of those partitions and put it in the kernel partition - the bootloader will prefer a kernel from the boot/recover partition, but if there isn't one will look in the kernel partition. I'd have to look to be 100% sure but I think the Helios ROM did this split. Personally I'd leave the stock kernel in the recovery partition (so that I know recovery will work) and I'd probably move the kernel from the boot partition to the kernel partition so I could flash it independently.
Sounds good, I'd love to help out however I can with the wiki. Here's what I had to do to compile the kernel from https://github.com/martinbrook/tesco-hudl : Pre-requisites:
This was done on Debian WSL2 but should work for other distros as well.
Install these packages:
sudo apt-get install git-core git gnupg flex bison gperf libsdl-dev libesd0-dev libwxgtk2.8-dev build-essential zip curl libncurses5-dev zlib1g-dev ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib sharutils lzop
(no idea how many of these are essential but can't hurt anyhow)
Download the source
git clone https://github.com/martinbrook/tesco-hudl.git
Download the toolchain (I think this is the one used to compile the stock one but other toolchains seem to work
git clone https://github.com/4Fwolf/4.6.x-google_prerelease_toolchain.git
cd into the toolchain cd 4.6.x-google_prerelease_toolchain/arm-eabi-4.6/
Set some variables: export ARCH=arm
and toolchain used export CROSS_COMPILE=$(pwd)/bin/arm-eabi-
cd into source files cd ~/tesco-hudl
Now the weird parts or strange errors happen:
Replace an already existing defconfig file in arch/arm/configs/
with the defconfig file in the root cp defconfig arch/arm/configs/acs5k_defconfig
Or use rk3188_qc880_defconfig which is almost identical with a few extra options turned on (probably should test this and other rk3188deconfigs but not enough time and seems to only be minor changes)
Try to compile! Clean it with make mrproper
then configure it with make acs5k_defconfig
(or whichever defconfig file you're using) and finally make
to actually create it (avoid using make -j4
for now as multithreading hides the errors).
Chances are you get this delightful error:
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at kernel/timeconst.pl line 373.
make[1]: *** [/home/andrew/tesco-hudl-master/kernel/Makefile:141: kernel/timeconst.h] Error 255
make: *** [Makefile:960: kernel] Error 2
So edit that offending bit out at this file kernel/timeconst.pl
About 6 lines before end of the file if (!defined(@val)) {1
to if (@val) {
I think it's important from what I can find online.
Then run through step 8 again which should be successful now.
This creates (in arch\arm\boot
a zImage file which hasn't been helpful and also a Image file which is tantalizing similar to the embedded kernel but doesn't seem to work after unpacking, replacing and repacking the boot.img (using imgRePackerRK).
I've tried a few more attempts and combinations but I think it could be that Tesco updated the kernel to 3.0.36+ instead of 3.0.36 of the source. That's the only thing I can think of at this point and probably a dead end unless we're able to contact one of the developers who worked on a custom kernel for the Hudl.
So edit that offending bit out at this file
kernel/timeconst.pl
About 6 lines before end of the fileif (!defined(@val)) {1
toif (@val) {
I think it's important from what I can find online.
Without trying it and by inspection I think that replacement should be if (!@val) {
THanks for the details. Not sure when I'll get the chance, but I will take a look at a later date and see if I can actually get something to build (and then probably look to see how to get to see the console output during boot to see what's going on.
I think this is the correct patch, which I've seen in a few places:
From 63a3f603413ffe82ad775f2d62a5afff87fd94a0 Mon Sep 17 00:00:00 2001
From: "H. Peter Anvin" <hpa@linux.intel.com>
Date: Thu, 7 Feb 2013 17:14:08 -0800
Subject: [PATCH] timeconst.pl: Eliminate Perl warning
defined(@array) is deprecated in Perl and gives off a warning.
Restructure the code to remove that warning.
[ hpa: it would be interesting to revert to the timeconst.bc script.
It appears that the failures reported by akpm during testing of
that script was due to a known broken version of make, not a problem
with bc. The Makefile rules could probably be restructured to avoid
the make bug, or it is probably old enough that it doesn't matter. ]
Reported-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@vger.kernel.org>
---
kernel/timeconst.pl | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/timeconst.pl b/kernel/timeconst.pl
index eb51d76e058a..3f42652a6a37 100644
--- a/kernel/timeconst.pl
+++ b/kernel/timeconst.pl
@@ -369,10 +369,8 @@ if ($hz eq '--can') {
die "Usage: $0 HZ\n";
}
- @val = @{$canned_values{$hz}};
- if (!defined(@val)) {
- @val = compute_values($hz);
- }
+ $cv = $canned_values{$hz};
+ @val = defined($cv) ? @$cv : compute_values($hz);
output($hz, @val);
}
exit 0;
--
2.29.2
Cool, I did try to recompile it in a old ubuntu version which worked without errors but still didn't boot. That makes me wonder whether the kernel source is different to the stock (3.0.36+ compared to 3.0.36 of the kernel source) but https://www.modaco.com/topic/375651-custom-jellybean-kernels-compiled/ makes it seem like it should work.
Whilst looking in the FreakTab forum, I found this: https://forum.freaktab.com/forum/development-area/rom-hacks-and-mods-development/8794-question-regarding-images-and-other-configs
This might be of interest: https://github.com/phjanderson/rkpatchomatic
Yep I found this tool as well. What we need to find out is how to pack a new kernel into the boot.img. @AndrewChqng how did you repack the boot.img using imgrepackerrk? I get errors whilst trying to do it.
Regarding the kernel partition, I've found that it's 8 MiB, which is too small to hold the Image file. What would happen if we used the zImage file? Half of the boot image is zero-filled, so could we eat into a bit of the boot partition to enlarge the kernel partition.
For future reference, stand-alone kernels flashed to the kernel partition need to be signed with:
rkcrc -k unsigned_kernel kernel.img
@remay @AndrewChqng finally, I've managed to do it. I'm attaching my dmesg log. You can see it was compiled using GCC 4.8 and by mint@mint-vm
(I'm running this in a Linux Mint VM).
dmesg.log
git clone https://github.com/martinbrook/tesco-hudl
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8
cd arm-eabi-4.8
export ARCH=arm CROSS_COMPILE=$(pwd)/bin/arm-eabi-
cd ../tesco-hudl
curl https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=63a3f603413ffe82ad775f2d62a5afff87fd94a0 | git apply -v
make rk3188_qc880_defconfig
make -j$(nproc --all)
make zkernel.img
This gives you a compressed kernel img that will fit into the 8 MiB partition.
For this I used a tool named rkKitchen
, found here. It is in Python 2.
git clone https://github.com/900supersport/rkKitchen
cd rkKitchen
cp [path to original boot.img] working/boot.img
python2 FreakTabKitchen.py
[pick option b]
[pick option 1]
[pick option 5]
[exit]
The boot.img with the kernel removed is now in working/boot.img
and the original kernel has been moved to working/boot.img.old
Flash the kernel.img and boot.img using rkflashtool
.
Can someone explain to me the benefit of a stand-alone kernel in the kernel partition?
I've successfully used imgrepackrk to unpack,modify and re-pack a recovery image with embedded kernel, but not tried other variants with that tool.
I'm not exactly sure, but the benefits would be that:
Thanks! Now to crash course myself on kernel modification 😁.
The instructions worked for me well after I signed the kernel👍 and I'm playing around with voltages and frequencies at tesco-hudl/arch/arm/mach-rk3188/board-rk3188-ds1006h.c
So far stable at:
What's the difference between rk3188_ds1006h and rk3188_qc880?
In the defconfig in / it says CONFIG_RK3188_QC880=y
I'm not sure, I did try editing board-rk3188-ds1006h.c but it changed nothing so I think it's a different version of rk3188 chipset. This is what I ended up with after a bit of testing and bricking🤪... Changing the DDR frequency had the biggest effect on performance
static struct cpufreq_frequency_table dvfs_arm_table[] = {
{.frequency = 126 * 1000, .index = 775 * 1000},
{.frequency = 252 * 1000, .index = 800 * 1000},
{.frequency = 312 * 1000, .index = 825 * 1000},
{.frequency = 504 * 1000, .index = 900 * 1000},
{.frequency = 816 * 1000, .index = 950 * 1000},
{.frequency = 1008 * 1000, .index = 1050 * 1000},
{.frequency = 1200 * 1000, .index = 1125 * 1000},
{.frequency = 1416 * 1000, .index = 1225 * 1000},
{.frequency = 1608 * 1000, .index = 1280 * 1000},
{.frequency = 1704 * 1000, .index = 1325 * 1000},
{.frequency = CPUFREQ_TABLE_END},
};
/******************************** gpu dvfs frequency volt table **********************************/
static struct cpufreq_frequency_table dvfs_gpu_table [] = {
#if defined(CONFIG_ARCH_RK3188)
{.frequency = 133 * 1000, .index = 950 * 1000},//the mininum rate is limited 133M for rk3188
#elif defined(CONFIG_ARCH_RK3066B)
{.frequency = 100 * 1000, .index = 950 * 1000},//the minimum rate is no limit for rk3168 rk3066B
#endif
{.frequency = 200 * 1000, .index = 975 * 1000},
{.frequency = 266 * 1000, .index = 1000 * 1000},
{.frequency = 300 * 1000, .index = 1025 * 1000},
{.frequency = 400 * 1000, .index = 1075 * 1000},
{.frequency = 600 * 1000, .index = 1225 * 1000},
{.frequency = 800 * 1000, .index = 1350 * 1000},
{.frequency = 900 * 1000, .index = 1400 * 1000},
{.frequency = CPUFREQ_TABLE_END},
};
/******************************** ddr dvfs frequency volt table **********************************/
static struct cpufreq_frequency_table dvfs_ddr_table[] = {
{.frequency = 200 * 1000 + DDR_FREQ_SUSPEND, .index = 900 * 1000},
//{.frequency = 300 * 1000 + DDR_FREQ_SUSPEND, .index = 1000 * 1000},
{.frequency = 300 * 1000 + DDR_FREQ_VIDEO, .index = 950 * 1000},
{.frequency = 700 * 1000 + DDR_FREQ_NORMAL, .index = 1200 * 1000},
//{.frequency = 528 * 1000 + DDR_FREQ_NORMAL, .index = 1200 * 1000},
{.frequency = CPUFREQ_TABLE_END},
};
I'm not sure, I did try editing board-rk3188-ds1006h.c but it changed nothing so I think it's a different version of rk3188 chipset. This is what I ended up with after a bit of testing and bricking🤪... Changing the DDR frequency had the biggest effect on performance
static struct cpufreq_frequency_table dvfs_arm_table[] = { {.frequency = 126 * 1000, .index = 775 * 1000}, {.frequency = 252 * 1000, .index = 800 * 1000}, {.frequency = 312 * 1000, .index = 825 * 1000}, {.frequency = 504 * 1000, .index = 900 * 1000}, {.frequency = 816 * 1000, .index = 950 * 1000}, {.frequency = 1008 * 1000, .index = 1050 * 1000}, {.frequency = 1200 * 1000, .index = 1125 * 1000}, {.frequency = 1416 * 1000, .index = 1225 * 1000}, {.frequency = 1608 * 1000, .index = 1280 * 1000}, {.frequency = 1704 * 1000, .index = 1325 * 1000}, {.frequency = CPUFREQ_TABLE_END}, }; /******************************** gpu dvfs frequency volt table **********************************/ static struct cpufreq_frequency_table dvfs_gpu_table [] = { #if defined(CONFIG_ARCH_RK3188) {.frequency = 133 * 1000, .index = 950 * 1000},//the mininum rate is limited 133M for rk3188 #elif defined(CONFIG_ARCH_RK3066B) {.frequency = 100 * 1000, .index = 950 * 1000},//the minimum rate is no limit for rk3168 rk3066B #endif {.frequency = 200 * 1000, .index = 975 * 1000}, {.frequency = 266 * 1000, .index = 1000 * 1000}, {.frequency = 300 * 1000, .index = 1025 * 1000}, {.frequency = 400 * 1000, .index = 1075 * 1000}, {.frequency = 600 * 1000, .index = 1225 * 1000}, {.frequency = 800 * 1000, .index = 1350 * 1000}, {.frequency = 900 * 1000, .index = 1400 * 1000}, {.frequency = CPUFREQ_TABLE_END}, }; /******************************** ddr dvfs frequency volt table **********************************/ static struct cpufreq_frequency_table dvfs_ddr_table[] = { {.frequency = 200 * 1000 + DDR_FREQ_SUSPEND, .index = 900 * 1000}, //{.frequency = 300 * 1000 + DDR_FREQ_SUSPEND, .index = 1000 * 1000}, {.frequency = 300 * 1000 + DDR_FREQ_VIDEO, .index = 950 * 1000}, {.frequency = 700 * 1000 + DDR_FREQ_NORMAL, .index = 1200 * 1000}, //{.frequency = 528 * 1000 + DDR_FREQ_NORMAL, .index = 1200 * 1000}, {.frequency = CPUFREQ_TABLE_END}, };
So this is board_rk3188_qc880.c
?
I've heard that qc880
refers to the screen.
So this is
board_rk3188_qc880.c
? I've heard thatqc880
refers to the screen.
Probably, I'm still guessing my way round things at this stage 😂. I'm also forking the source to share the modifications and what I manage to do which I wouldn't mind any ideas and help for😅, hopefully I can learn how to add governors for the cpu, gpu and io scheduler: https://github.com/AndrewChqng/tesco-hudl
I've created a GitHub Pages site with information about the Tesco Hudl. https://waluigiware64.github.io/hudl-dev/
This thread claims to have some overclocked Kernels https://forum.freaktab.com/forum/tablet-support-android/other-oem-tablets/519127-hudl-kernel
Is it worth investigating?