Related
How to extract the boot image from your tablet, set up adb, compile a new kernel with cool options, and put it back on your device!
UPDATED for Lolipop 12-4-14
This is a complete guide from start to finish, copy and paste style. If you own a gpe510, or any other AOSP device and a computer running Debian Linux, you can do all of this.
If all you want is the modified kernel, download from here:
Sleekai Kernel For The LG GPad 8.3 V510(GPE)
I am hoping people will add to this with new ideas and patches in order to make the GPE a better device. I see the potential for all sorts of neat stuff.
This guide assumes a basic knowledge of linux operating systems. I am using a Debian 64 bit (wheezy stable) to compile my kernel. I have used many, many hours of the day to figure this out properly, with specific thanks going to Pete of Pete's Blog for his image tools.
But first, lets keep this simple. As usual, you are on your own if you brick your device, though I don't see how you could if you are paying attention!
There are dependencies for building your own kernel, and you will definitely want to use a 64 bit system as a 32 bit will not work properly for kitkat.
Here are all of the packages you will need, and they will draw in further dependencies when you install, but these are it! So, here we go:
Open a terminal, su to root and:
Code:
dpkg --add-architecture i386
##This will allow for the use of some 32 bit librarys that we will need for both adb and the kernel compile. Then:
Code:
apt-get update ; apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libc6-i686:i386 lzop liblzo2-dev libgpm2:i386 git-core git gnupg flex bison gperf libsdl1.2-dev libesd0-dev build-essential zip curl gedit libncurses5-dev zlib1g-dev fakeroot lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib
Next, you will need to install adb and have your permissions set up.
In order to do this you will need to go into the developer options on your device to enable debugging on your tablet. Go to settings/about tablet/build number, and tap on build number several times to unlock the developer options.
then:
You will need to create new udev rules for your device in/etc/udev/rules.d on your computer.
Use "lsusb" in your terminal to find the manufactures code of your device. it will show up as a nexus 4, or Google device.
You will need to create a file in your computer in /etc/udev/rules.d/99-android.rules.
You can use gedit if you like:
Code:
gedit /etc/udev/rules.d/99-android.rules
Put the following inside and save, changing the manufactures code as necessary to fit your device, and change “your-login” to your login name on your computer.
Code:
# Google Nexus devices
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", OWNER="your-login" # Google Nexus devices
18d1 is the manufacturers code.
You will then want to restart udev on your computer:
Code:
service udev restart
you will now have permissions to access your android device from user space.
Now to download adb and get started. You should probably not use adb from the Debian repositories, as it may be an older version. the V510 is using kitkat android and needs the latest build of adb to work properly. It is a good idea to get rid of any old adb files on your computer first. The code below will do just that.
Code:
apt-get purge android-tools-adb android-tools-fastboot
Now download the latest adb bundle from here:
http://developer.android.com/sdk/index.html
Move it into a new directory,
*note -the version number may be different.
Code:
mkdir ~/adb
Code:
cd ~/adb
Code:
unzip adt-bundle-linux-x86_64-20131030.zip
su to root and Move the bundle to /opt:
Code:
mv adt-bundle-linux-x86_64-20131030 /opt/android-sdk-linux-x86_64-20131030
Other google products reside in /opt, this should too. This takes a minute or so on slow machines.
Next we need to link adb to /usr/bin
Code:
ln -s /opt/android-sdk-linux-x86_64-20131030/sdk/platform-tools/adb /usr/bin
Code:
ln -s /opt/android-sdk-linux-x86_64-20131030/sdk/platform-tools/fastboot /usr/bin
We are ready to begin working on the device! first start the adb server and look for your device.
Code:
adb start-server
Code:
adb devices
You will then need to confirm the connection on your tablet screen to allow access from your computer.
Okay, wev'e got this first part set up. it's time to begin working on a kernel!
Lets get started.
I want to extract and build my zimage in $userspace, so open a terminal from /home and:
Code:
mkdir ~/android
Download the source package LG-V510(G-Pad 8.3 Google Play Edition)_Android_KK_V510_11c from here :
https://www.lg.com/global/support/opensource/opensourceList?types=ALL&search=lgv510
and open it to find three folders, including a kernel folder. Move the kernel folder to ~/android and then:
Code:
cd ~/android
Download the current eabi-4.6 Google tool chain to ~/android to cross compile your android kernel:
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8
When it completes, enter ~/android/kernel and get ready to compile a new kernel from the source code.
Code:
cd ~/android/kernel
Do the following each time you compile another kernel. This insures the correct path.
Code:
export PATH=$PATH:~/android/arm-eabi-4.8/bin
Code:
arm-eabi-gcc --version
you should get:
Code:
arm-eabi-gcc (GCC) 4.6.x-google 20120106 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Continue on! we are not done yet!
Code:
export ARCH=arm
Code:
export SUBARCH=arm
Code:
export CROSS_COMPILE=arm-eabi-
Code:
export KERNEL_DEFCONFIG=palman_defconfig
Code:
make clean
Code:
make palman_defconfig
Doing the above prepares your kernel build environment, while the following code opens a interface to configure the kernel. You can simplify this later however you wish.
But for now,
Code:
make menuconfig
At this point make whatever changes you wish to the config file. for a list of the changes I have made, and that are in the kernel available to download, look in the sleekai kernel thread. (At start of thread, or in my signature).
After saving your changes,
Code:
make
Or conversely
Code:
make -o2
which will optimize the make. I recommend using simply "make" first, as the other may not properly show errors should any occur.
and go make a pot of coffee, and probably drink the whole pot! This will take a while.
At the end you will see that the "zimage is ready"
If you have errors, then you probably have dependency problems. If not, Yay! You compiled your first kernel, but we are not done yet!
The zimage you just produced is stored in /kernel/arch/arm/boot/zImage
To put both the zimage and any modules into a separate folder inside of ~/android so as to make extracting them easier:
Code:
mkdir ~/android/kernel_output
Code:
cp ~/android/kernel/arch/arm/boot/zImage ~/android/kernel_output/zImage
Code:
find ~/android/kernel -name "*.ko" -exec cp {} ~/android/kernel_output/ \;
The above code will find all the modules for your kernel. We don't need them for this tutorial, but it still is mighty handy!
Extract your boot image (boot.emmc.win) for the ramdisk You may also download the stock.zip from the sleekai kernel thread
Now make a backup to transfer to your computer.
Reboot to recovery on your tablet. I'm using TWRP. If you are using something else it should be just as easy.
Code:
adb reboot recovery
Only tick the boot
make a backup to your sd card. I changed the name to boot.bac to keep it simple
reboot
make sure the backup of boot is present using a file explorer. I am using ES File explorer.
On your computer, pull the file using adb
Code:
adb start-server
Code:
adb devices
Code:
adb pull /storage/sdcard1/TWRP/BACKUPS/LG0000606708987/boot.bac /home/sleek
sleek is my user name, replace with yours or use tilde.
What we are after is the "boot.emmc.win" file. We will only need this and the zImage to compile a new boot image and run it on your tablet.
The tools to extract the kernel and ramdisk from the boot.emmc.win you will need the following boot image tools installed on your computer.
So, again, lets keep this simple. All the tools are forked to my github for ease of use.
So lets install the tools! Ready?
As Root:
Code:
mkdir /usr/src/android
Code:
mkdir /usr/src/android/boot
Code:
cd /usr/src/android/
Code:
git clone https://github.com/sleekmason/bootimg-tools.git
Code:
cd bootimg-tools/libmincrypt/
Code:
gcc -c *.c -I../include
Code:
ar rcs libmincrypt.a *.o
Code:
cd ../mkbootimg
Code:
gcc mkbootimg.c -o mkbootimg -I../include ../libmincrypt/libmincrypt.a
Code:
cp mkbootimg /usr/local/bin/
Code:
cd ../cpio
Code:
gcc mkbootfs.c -o mkbootfs -I../include
Code:
cp mkbootfs /usr/local/bin/
Code:
cd /usr/src/android/bootimg-tools/mkbootimg/
Code:
wget https://raw.github.com/sleekmason/bootimg-tools/master/mkbootimg/unmkbootimg.c
Code:
gcc -o unmkbootimg unmkbootimg.c
Code:
cp unmkbootimg /usr/local/bin/
Now everything is in place to make a new boot image for your tablet!
Finishing this up is easy.
As root, we made a directory in /usr/src/android/boot for your boot.emmc.win file to be torn apart:
Code:
cd /usr/src/android/boot
Copy your new zImage and the boot.emmc.win file you extracted from your device.
Note* "/home/sleek" is the path on my computer, and should be changed to reflect yours!
Code:
cp /home/sleek/android/kernel_output/zImage /usr/src/android/boot
Code:
cp /home/sleek/boot.emmc.win /usr/src/android/boot
Now unpack the boot.emmc.win file to get the ram disk
Code:
unmkbootimg -i boot.emmc.win
Now you may remove the current boot.emmc.win file, and the resultant kernel file as we will be making new ones, and rename the zImage file you moved here to "kernel".
Code:
rm boot.emmc.win kernel && mv zImage kernel
Now repack using the command given to you during the unpack:
Code:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80208000 --ramdisk_offset 0x82200000 --second_offset 0x81100000 --tags_offset 0x80200100 --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=palman lpj=67677 vmalloc=300M' --kernel kernel --ramdisk ramdisk.cpio.gz -o boot.emmc.win
Note* For 500 users this may be different. Simply use the command from the prompt.
You should now have a brand new boot.emmc.win image in /usr/src/android/boot!!
To push back on your device to test
Code:
adb reboot bootloader
Code:
fastboot boot boot.emmc.win
USING the above will only put your kernel build into memory and should not hurt your device if something goes wrong. Use the command below to make it permanent.
If everything works well, you should see the change you made to the /general/perf-localversion/ in your settings under kernel. from there it's up to you to hack away! make new and unique kernels!
If you want your kernel to survive reboot do;
Code:
fastboot flash boot boot.emmc.win
then:
Code:
fastboot reboot
You can expect a slow bootup on the first go around as your new kernel populates the widgets, etc..
NOTE*For the use of the latest eabi-4.7 google toolchain, you will need the libglibc libraries from the "testing" branch as gcc 4.7 is in testing. I advise completing the guide with eabi 4.6 first before trying 4.7.
The gamma correction though enabled in 4.6, isn't near as good as the native compile using 4.7. If you want the screen to look like it does in my kernels, you will need 4.7
For the eabi-4.7:
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7
That's it! Good luck! Remember, If you post a kernel you have made, you will need to show your kernel source, etc . . . Git hub is a good choice to keep track of changes you make. Best regards, Sleekmason
If you are a v500 user and want to build your own kernel!
First, read the above post as you will be following the steps listed there.
There are just a couple of changes that you will need to do, and maybe a riddle to figure out as well. Read on.
You will need to download the v500 source from here: https://www.lg.com/global/support/opensource/opensourceList?superOsCategoryId=CAT00000001&osCategoryId=
Look for the LGV500 kernel source.
Where it says "palman" for the defconfig items, you will want to replace that with the defconfig for the 500, so replace palman with awifi-perf,
like this:
Code:
export KERNEL_DEFCONFIG=awifi-perf_defconfig
Code:
make awifi-perf_defconfig
Important
Follow the guide and build with the Google Toolchain eabi4.6 first
LG compiled for the 500 and 510 using the eabi4.6. It works, and will give you a feel for the process, and allow you to use your kernel.
Note*
I use the google toolchain eabi-4.7 for the sleekai kernels as it changes the gamma to reasonable defaults on the 510 without further tweaking. After compiling a kernel or two to get a feel for it, you should try using the 4.7 toolchain. To do so, you will probably need the libglibc libraries from the "testing" branch. Look it up.
caveat: I recieved a compile error for the v500 when I used the eabi-4.7 . . . . . yeah. You'll have to work that out.
There is a modified anykernel script for emmc devices out there (Search Google or here in xda). You will have to use the anykernel script after making your boot.emmc.win image as fastboot won't work on the 500. There may be another way .... But I don't know what it is.
Edit* There are now two different kernels for the LG GPad 8.3 V500(awifi) located in the development section of the forum.
Best of luck! -sleekmason
Can this be used to create a kernel for the non Google Play Edition Gpad to be able to allow us to install the Google Play edition ROM on it
Sent from my SM-N900W8 using Tapatalk
Canadoc said:
Can this be used to create a kernel for the non Google Play Edition Gpad to be able to allow us to install the Google Play edition ROM on it
Sent from my SM-N900W8 using Tapatalk
Click to expand...
Click to collapse
I would think so. I edited the above to show how to put the image back on your device. You should be able to use any source you wish to compile with. My thoughts are that you might wish to examine the differences in the ram disk if any.
sleekmason said:
Howdy, I would like to share how to download the kernel source for the gpe, compile a new custom kernel, and insert into your LG gpad GPE 510.
...
Click to expand...
Click to collapse
Thanks for the guide. Making GPE kernel was my next step in trying to get the GPE ROM to work on v510.
I just made guide for getting your Android build environment going if you want to use it on your blog or where ever.
http://forum.xda-developers.com/showthread.php?t=2629008
The problem with v500 is that it does not have fastboot so we can not flash kernel like how you can on v510.
@ AndroidUser00110001 Hi! I know that somebody tweaked the Any kernel to work on emmc devices... Maybe it could be adapted? Actually getting the menuconfig and make should be the same process as well as repacking the image. I take it just getting it back on the 500 device is the problem?
I will add your link to this post for setting up a build environment if that is okay.
sleekmason said:
@ AndroidUser00110001 Hi! I know that somebody tweaked the Any kernel to work on emmc devices... Maybe it could be adapted? Actually getting the menuconfig and make should be the same process as well as repacking the image. I take it just getting it back on the 500 device is the problem?
I will add your link to this post for setting up a build environment if that is okay.
Click to expand...
Click to collapse
Is that the koush any kernel? I was going to mess with that too. I just need a small break now. Took a few days to get new system exactly how I want it.
Go ahead and use guide...mo problem at all.
AndroidUser00110001 said:
Is that the koush any kernel? I was going to mess with that too. I just need a small break now. Took a few days to get new system exactly how I want it.
Go ahead and use guide...mo problem at all.
Click to expand...
Click to collapse
Yes, from here: http://forum.xda-developers.com/showthread.php?t=847265
I noted that boot was on block nncblk0p21 on our device, and not 22? better double check that. I tried it Anykernel as well to no avail when getting this set up. Fastboot is Awesome!
It's taxing to get it set up right. Seems like things change very often for the dependencies based on other package changes. I ussually go with testing but redid two partitions with stable. The 32 bit is just going to sit there, which seems kinda silly due to the need for extra packages in 64 to compile for 32 but whatever. Yeah.
AndroidUser00110001 said:
Thanks for the guide. Making GPE kernel was my next step in trying to get the GPE ROM to work on v510.
I just made guide for getting your Android build environment going if you want to use it on your blog or where ever.
http://forum.xda-developers.com/showthread.php?t=2629008
The problem with v500 is that it does not have fastboot so we can not flash kernel like how you can on v510.
Click to expand...
Click to collapse
I don't understand, what are the differences bettween the v500 and v510? they both have the same hardware, but not the same boot partition or something like that?
ayziaa said:
I don't understand, what are the differences bettween the v500 and v510? they both have the same hardware, but not the same boot partition or something like that?
Click to expand...
Click to collapse
The boot on the 500 cannot be fully unlocked.
This is not the appropriate place to ask that kind of question should be asked in general or in troubleshooting. Also, there are already many threads about this same question please use the search utility to find them. Thank you.
i was thinking of writing a tutorial about this as well for the v500 but this better than i would have done Well done...
sleekmason said:
Yes, from here: http://forum.xda-developers.com/showthread.php?t=847265
I noted that boot was on block nncblk0p21 on our device, and not 22? better double check that. I tried it Anykernel as well to no avail when getting this set up. Fastboot is Awesome!
It's taxing to get it set up right. Seems like things change very often for the dependencies based on other package changes. I ussually go with testing but redid two partitions with stable. The 32 bit is just going to sit there, which seems kinda silly due to the need for extra packages in 64 to compile for 32 but whatever. Yeah.
Click to expand...
Click to collapse
Another tool that i ported to the lg g pad a bit back along with loki-doki...
Quick hint, dont bother with direct mmc naming as qcom (i dont know if the other chip makers do the same thing, as i have only had qcom devices) has given us a simple naming scheme...
should only be used by people who know how to use this,
darkassain said:
i was thinking of writing a tutorial about this as well for the v500 but this better than i would have done Well done...
Another tool that i ported to the lg g pad a bit back along with loki-doki...
Quick hint, dont bother with direct mmc naming as qcom (i dont know if the other chip makers do the same thing, as i have only had qcom devices) has given us a simple naming scheme...
should only be used by people who know how to use this,
Click to expand...
Click to collapse
Thank you! Have you successfully used your script to push a kernel onto the 500 Or 510?
I would think this could be very handy for sharing a custom kernel for the 510, but would like to see somebody report a positive test result. Very cool!
sleekmason said:
Thank you! Have you successfully used your script to push a kernel onto the 500 Or 510?
I would think this could be very handy for sharing a custom kernel for the 510, but would like to see somebody report a positive test result. Very cool!
Click to expand...
Click to collapse
yes back before when there wasnt a overclocked kernel i basically used this to push it when i would compile just the kernel (didnt maintain so i now use dyn's)...
yes this is only for the v500 as this has the extra loki step, but it shouldnt be hard to modify so it does not do that extra step
darkassain said:
i was thinking of writing a tutorial about this as well for the v500 but this better than i would have done Well done...
Another tool that i ported to the lg g pad a bit back along with loki-doki...
Quick hint, dont bother with direct mmc naming as qcom (i dont know if the other chip makers do the same thing, as i have only had qcom devices) has given us a simple naming scheme...
should only be used by people who know how to use this,
Click to expand...
Click to collapse
Hi, can you just use a generic anykernel updater script too?
For example to flash a packed boot.img
Code:
run_program("/tmp/busybox", "dd", "if=/dev/block/platform/msm_sdcc.1/by-name/boot", "of=/tmp/boot.img");
run_program("/tmp/unpackbootimg", "-i", "/tmp/boot.img", "-o", "/tmp/");
run_program("/tmp/repack-ramdisk.sh");
run_program("/tmp/mkbootimg.sh");
run_program("/tmp/busybox", "dd", "if=/tmp/newboot.img", "of=/dev/block/platform/msm_sdcc.1/by-name/boot");
mako and flo can do like this.. I think HTC One as well, since they are all similar qcom chipsets maybe this device can too
poondog said:
Hi, can you just use a generic anykernel updater script too?
For example to flash a packed boot.img
Code:
run_program("/tmp/busybox", "dd", "if=/dev/block/platform/msm_sdcc.1/by-name/boot", "of=/tmp/boot.img");
run_program("/tmp/unpackbootimg", "-i", "/tmp/boot.img", "-o", "/tmp/");
run_program("/tmp/repack-ramdisk.sh");
run_program("/tmp/mkbootimg.sh");
run_program("/tmp/busybox", "dd", "if=/tmp/newboot.img", "of=/dev/block/platform/msm_sdcc.1/by-name/boot");
mako and flo can do like this.. I think HTC One as well, since they are all similar qcom chipsets maybe this device can too
Click to expand...
Click to collapse
thanks for reminding me the any kernel uploaded by me won't work as it doesn't parse Loki images xorrectly, I'll upload the correct one once I have access to my pc
darkassain said:
thanks for reminding me the any kernel uploaded by me won't work as it doesn't parse Loki images xorrectly, I'll upload the correct one once I have access to my pc
Click to expand...
Click to collapse
could you please re-post to a different thread rather than hijacking this thread, as your script does not work with the 510 currently and I do not want to go to get confused with my kernel how to. what started out to maybe become relevant apparently will not and so shouldn't be confused with what I'm doing here. I will be happy to try working with your script if you would open up an appropriate thread. Thank you.
Installed kenel and booted. Now to install trickster mod and fix the dang gamma.
gunnyman said:
Installed kenel and booted. Now to install trickster mod and fix the dang gamma.
Click to expand...
Click to collapse
Excellent!! Pleased to know that you are able to use it. Have you changed your gamma settings?
I did on mine and am pleased with the result. I'm using 248, 252, 255 using trickster mod What are you going with?
sleekmason said:
Excellent!! Pleased to know that you are able to use it. Have you changed your gamma settings?
I did on mine and am pleased with the result. I'm using 248, 252, 255 using trickster mod What are you going with?
Click to expand...
Click to collapse
havent messed around too much.
I had a thought about this and I think it would be awesome if we could incorporate faux123's bits for gamma and color control. His fauxcontrol offers much more granular control than trickster.
I'm thankful to have what we have, and THANK YOU for sharing it, but like any good geek I WANTS MOAR!!!!!
gunnyman said:
havent messed around too much.
I had a thought about this and I think it would be awesome if we could incorporate faux123's bits for gamma and color control. His fauxcontrol offers much more granular control than trickster.
I'm thankful to have what we have, and THANK YOU for sharing it, but like any good geek I WANTS MOAR!!!!!
Click to expand...
Click to collapse
me too! I'll look into it. There are other apps besides trickster to give you more control. I think at the kernel level everything we need is unlocked. And yeah, he knows his business like nobody else eh? I'm just persistent.
I'm not an active developer but I'm also not a *total* noob -- I've successfully compiled usable kernels for Nexus 4, Moto G, HP TouchPad -- but I'm not making much headway on my Z5C kernel.
I want to run an otherwise stock Sony ROM on my phone, but make a couple of minor tweaks to the kernel. With that in view, I downloaded the source tree from Sony's dev site for the kernel that matches the one that shipped with the ROM I am currently running (at the moment, for Reasons, it's a Lollipop one, and I'm not really interested in debating that point anyway), and then I started by building a kernel with ZERO changes applied first. But it will not boot. Instead, with my first attempt at a kernel compiled from scratch, after the Sony Xperia boot logo and before the boot animation would normally kick in, the screen goes black and the notification LED blinks red 4 times, and then it reboots and starts over (bootloop).
I'm not sure what I am supposed to do to diagnose the problem since the screen doesn't display anything and it never gets far along enough in the boot process to where the USB port is initialized. And, yes, the bootloader is unlocked (I can flash a stock kernel to the phone with the DRM fix applied, and that boots and works just fine).
Here is what I have done so far:
Downloaded the kernel sources that match my ROM's kernel at https://developer.sonymobile.com/do...rchives/open-source-archive-for-32-0-a-6-200/
Downloaded the GCC 4.9 for ARM64 cross-compiler / toolchain from https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
Applied kitakami_defconfig and suzuran_diffconfig, and built the kernel. It compiled cleanly without any errors.
Extracted kernel.elf from my ROM's kernel.sin, and then unpacked the binary image, initramfs, and device tree blob from that.
Re-packaged a new kernel into .img format for Fastboot flash by substituting in my kernel image binary for the official Sony one, but keeping the original ramdisk and DTB.
Flashed image to boot partition with Fastboot == bootloop
Flashed original kernel back == works fine
Decided to try creating a new DTB instead of reusing the one from the original kernel...but dtbTool spits out this:
Code:
Found file: msm8994-v2.0-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Found file: msm8994-v2.1-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Grabbed dtbToolCM from https://github.com/xiaolu/mkbootimg_tools instead, which seems to work.
Substituted in the new DTB image for the original Sony one, repackaged up a new boot.img, flashed that == bootloop
Tested my mkbootimg and the parameters I was using by extracting kernel, ramdisk, and DTB from original kernel.elf, then repackaging them all together into a boot.img and flashing that to the phone with Fastboot == works just fine
Hypothesized that perhaps my kernel didn't like the Sony kernel modules on the system partition because of version magic mismatch, so I changed CONFIG_LOCALVERSION from "-perf" to "-perf-g75e6207" in .config and rebuilt kernel, repackaged, reflashed with Fastboot == bootloop ... ARGH
So at this point, I'm at a loss. I've proven that it's not the way I am packaging up the boot image because if I repack the original Sony kernel binary up with the original ramdisk and DTB and then flash that file to the boot partition, that has no problem booting the phone. Is there some modification that I need to make to the contents of the ramdisk? I'd think I should just be able to use the stock Sony ramdisk unmodified, especially if the kernel itself doesn't differ at all (same sources, same .config) from the one Sony compiled, but...?
Any leads that any experienced Xperia Z-series kernel hackers out there can supply before I end up tearing my hair out would be greatly appreciated.
Thanks so so so much,
-- Nathan
[UPDATE]: Just tried assembling with mkqcdtbootimg instead. No go. Also unpacked the image made by that utility and verified that everything (e.g. offsets, etc.) looked sane. GARGH.
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
nlra said:
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
Click to expand...
Click to collapse
I think that cannot be possible. There are lots of kernels out there compiled with toolchains different than the stock one (e.g. Androplus kernel is compiled with UBERTC 4.9)
I am in the same situation as you, but with the Xperia X Compact:
-Untouched copyleft source code
-Untouched ramdisk
-Using AOSP mkbootimg (the new one written in Python: https://android.googlesource.com/platform/system/core/+/nougat-release/mkbootimg/mkbootimg) with arguments specified in README_Xperia (https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/README_Xperia)
And still no boot... I am about to give up on this as I cannot find any other solution...
You can see my build script here for reference: https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/utils/build.sh
bamsbamx said:
I think that cannot be possible.
Click to expand...
Click to collapse
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
nlra said:
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
Click to expand...
Click to collapse
Yeah, sorry about that, I didnt push the new commits to Github yet because of the kernel not booting, the current script I am using is this one:
Code:
#!/bin/bash
RED=1
GREEN=2
BLUE=4
colorPrint() {
tput setaf $2
echo $1
tput sgr0
}
colorPrint "Initializing workspace..." $BLUE
#Device config
device=kugo
#Workspace directories
workdir="$(pwd)"
outputfolder=${workdir}/OUTPUT
outputdir=${outputfolder}/${device}
toolchains=${workdir}/toolchains
ramdisk=${workdir}/ramdisks/${device}/ramdisk
export ARCH=arm64
export CROSS_COMPILE=${toolchains}/aarch64-linux-android-4.9-kernel/bin/aarch64-linux-android-
export KBUILD_DIFFCONFIG=kugo_diffconfig
colorPrint "Cleaning previous builds..." $BLUE
rm -rf $outputdir
mkdir -p $outputdir
colorPrint "Configuring kernel..." $BLUE
make msm-perf_defconfig O=$outputdir
colorPrint "Building kernel..." $BLUE
time make -j8 O=$outputdir 2>&1
if [ ! -f $outputdir/arch/arm64/boot/Image.gz-dtb ]; then
colorPrint "ERROR: kernel image not found. Kernel build failed" $RED
exit 1
fi
if [ ! -e $outputdir/ramdisk.cpio.gz ]; then
colorPrint "ERROR: ramdisk image file not found. Compression failed" $RED
exit 1
fi
colorPrint "Packaging boot image file" $BLUE
${workdir}/utils/mkbootimg \
--kernel $outputdir/arch/arm64/boot/Image.gz-dtb \
--ramdisk $outputdir/ramdisk.cpio.gz \
--base 0x20000000 \
--ramdisk_offset 0x02000000 \
--pagesize 2048 \
--tags_offset 0x01E00000 \
--cmdline "androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 zram.backend=z3fold earlyprintk" \
--output $outputdir/boot.img
if [ ! -f $outputdir/boot.img ]; then
colorPrint "ERROR: boot image file not found. boot packaging failed" $RED
exit 1
fi
colorPrint "DONE" $GREEN
colorPrint "boot image file can be found at ${outputdir}/boot.img" $GREEN
This one is for the build 34.3.A.0.217... However, I already had managed to boot copyleft kernel builds in other versions (such as 34.2.A.0.XXX) using the Github script, the UBERTC 4.9 Toolchain and not changing the GCC version, although I had to set # CONFIG_MODULE_SIG_FORCE is not set There must be something strange here
I think there must be something with kernel files permissions, or... maybe this? https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
zacharias.maladroit said:
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
Click to expand...
Click to collapse
Hi,
Nope, I didnt disable RIC neither dm-verity, the only thing I changed was CONFIG_MODULE_SIG_FORCE to 'is not set'. But I guess that wasnt the cause of kernel not booting since my /system partition is untouched. I tried both with mkqcdtbootimg and mkbootimg but still nothing
Hey @nlra, I figured out the problem (finally). The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken (resulting in a 7.0MB ramdisk.cpio.gz file)
I managed to pull up the boot.img from the device (via dd if=/dev/block/mmcplk0p33 of=/sdcard/boot.img) and then extract the ramdisk from it, resulting in a 11.4MB file
Then, I was able to boot it BOTH USING mkqcdtbootimg file and mkbootimg python script from AOSP nougat-release branch
Thats it
bamsbamx said:
The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken
Click to expand...
Click to collapse
Nice! Glad you figured out what was going on in your case, and thanks for confirming that both mkqcdbootimg and mkbootimg both work for building the X Compact boot image.
-- Nathan
I am thinking of starting a new thread to solve the issue of ArnoldTheBat r72 booting to blank screen on Acer Chromebook C720P
oops I just did -
Building Chromium/Chrome OS r71 or r72 Kernel RFC
It seems the only way to tackle drivers issues is to build the Kernel.
So, trying to build a Chrome OS r72 Kernel to use on ATB r72 to address these drivers issues, particularly the inability to boot Acer Chromebook C720P -
As I have never done this before, I need some pointers as documentation for this is very sketchy on Google groups. RFC alesimula...
What I have available is Ubuntu Bionic, & necessary storage to build (over 100 GB) -
I also have a chromefied Nocturne then eve 73/swtpm.tar SSD (on top of ABT r72) with Bionic crouton with same over 100 GB storage available.
First steps to build Kernel
Build chrome os kernel and kernel modules
In a Chrome OS box (like Nocturne r71 with kernel 4.14) - install crouton Bionic
$ sudo sh ~/Downloads/crouton -r bionic -t xfce,xiwi,touch,extension,keyboard,cli-extra,chromium
after installation enter chroot
$ sudo enter-chroot
$ sudo apt-get install git-core make kernel-package bc nano
$ git clone https://chromium.googlesource.com/chromiumos/third_party/kernel -b chromeos-4.14
TBC after download
adapted from https://github.com/dnschneid/crouton/wiki/Build-chrome-os-kernel-and-kernel-modules
Kernel download Chrome OS Kernel 4.14
After issuing the git clone command - I received some errors...
such as
error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
...
& after several tries succeeded with the message:
remote: Sending approximately 2.11 GiB ...
remote: Counting objects: 24648, done
remote: Total 7215674 (delta 5927776), reused 7215674 (delta 5927776)
Receiving objects: 100% (7215674/7215674), 2.10 GiB | 1.59 MiB/s, done.
Resolving deltas: 100% (5927776/5927776), done.
Checking out files: 100% (62736/62736), done.
So now the next business after securing the source code is to compile the kernel adding the modules/drivers needed to resolve issues such as camera & graphics, etc.
Hopefully this info is in here too
https://github.com/dnschneid/crouton/wiki/Build-chrome-os-kernel-and-kernel-modules
I am using Acer Iconia W700 with chromefied nocturne on top of arnoldthebat r72...
crouton bionic with xfce4 is my chroot environment to compile the kernel...
I guess I need to dig in, get the proper commands, it should not be different from compiling other Kernels for Android, Ubuntu, Arch Linux...
What I know is that it takes time...
hopefully if I get drivers, it will be worth the effort
Extra refs to solve cloning issues
https://devopscube.com/gnutls-handshake-failed-aws-codecommit/
https://stackoverflow.com/questions/38378914/git-error-rpc-failed-curl-56-gnutls
Compressed Chrome OS Kernel 4.14 using tar/xz is bleeming 2.4 GB!
$ tar cJvf kernel.tar.xz kernel
References for setting up configuration to build the Chrome OS kernel -
https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/kernel-configuration
https://www.chromium.org/chromium-o...n-snow#TOC-Building-and-installing-the-kernel
Building Chrome OS kernel 4.14
Putting it together - trial & improvement (PC of trial & error)
in bionic chroot
sudo enter-chroot
go to kernel source code (folder where cloned)
$ cd kernel
$ ls chromeos/scripts/
generate-its-script.sh kernelconfig prepareconfig README splitconfig update_smatch_whitelist
challenge - how to generate .config to build kernel - & what are the commands to build it - I know how to with Ubuntu & Arch Linux, even done it a few time for Android Jelly Bean...
scratch - here goes...
from bionic chroot - kernel folder source code kernel/
sh ./chromeos/scripts/prepareconfig chromeos-intel-pineview
sudo modprobe configs; zless /proc/config.gz
cat /proc/config.gz | gunzip > ~/Downloads/base.config
base.config contains all the current configuration of ATB v72 kernel. This file should replace the current file on path kernel/chromeos/config/base.config
Editing base.config - to get extra kernel modules
I use nano
cd ~/Downloads/
nano base.config
it starts like this:
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.14.83 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
...
First change is Apple backlight keyboard replacing where it says is not set by:
CONFIG_BACKLIGHT_APPLE=m
Improving Kernel 4.14.83 from ATB v72 Methodology
Methodology
Extract base.config from FydeOS 5.3.1 (Chromium OS v70) & merge in its settings into base.config extracted from ATB Chromium OS v72...
Busy doing this, as I am not good at coding, so cannot devise an automated script, doing it manually is a long bummer
My comment in Telegram, frustration included -
Modifying kernel basic.config of ATB v72 to incorporate all settings/modules of FydeOS 5.31 (v70) is so tedious, it's a nightmare - I wish there was a way to automate this with a script that merges in FydeOS basic.config entries that are not present in ATB v72 - I am crap at coding & scripting, so doing it manually, it takes forever, & I keep making mistakes :stuck_out_tongue_closed_eyes: - as I am not sure what stops ATB v72 Acer C720P from booting, I have to include all missing settings in basic.config before building the kernel.
Chrome OS Kernel 4.14.96 built with extra modules for ATB v72
It does generate .config after all as usual for Linux kernels - got some issues from enter-chroot - had to do it from Ubuntu bionic proper with (from kernel source folder):
$ sh ./chromeos/scripts/prepareconfig chromeos-intel-pineview
$ make oldconfig
$ make -j4
Just now...
Finished compiling Chrome OS 4.14.96 for ATB v72 (which has Kernel 4.14.83), got vmlinux & modules - now need to find out how to deploy them on a Chrome OS installation...
After some struggle, managed to boot the new kernel as 4.14.96-09859-ga5c3f2f0428a-dirty
installed extra modules
by doing in crosh shell (not chroot)
in kernel compiled source code folder:
$ sudo make modules_install
it creates a new folder /lib/modules/4.14.96-09859-ga5c3f2f0428a-dirty
to get the kernel I just overwrite vmlinuz.A in /dev/sdb12 by kernel/arch/x86/boot/bzImage
(backup vmlinuz.A as vmlinuz.C)
to get to this:
$ mkdir efi
$ sudo mount /dev/sdb12 efi
$ cd efi
$ cd syslinux
$ sudo cp vmlinuz.A vmlinuz.C
$ sudo cp bzImage vmlinuz.A
../..
It boots great on Acer Iconia W700 & MacBook Air mid-2011
the joke is despite modules still no WiFi & no trackpad for MacBook Air
other joke does not boot Acer Chromebook C720P
well at least I tinkered with building this darn Chrome OS kernel - not much documentation on it (apart from how to do this in arm architecture)
Linux localhost 4.14.96-09859-ga5c3f2f0428a-dirty #1 SMP PREEMPT Wed Feb 13 08:04:55 GMT 2019 x86_64 Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz GenuineIntel GNU/Linux
As I do not know how to proceed from this due to lack of Google documentation - I will stop.
I think to get it working, I need to install Chromium OS from scratch, but documentation is unclear, & arnoldthebat has no instructions on how to do this.
So I am starting an effort to build a full Chromium OS from scratch - as
the best way to learn is to share know how.
New thread - https://forum.xda-developers.com/hardware-hacking/chromebooks/chromium-os-building-t3900245
Chromium OS building effort here -
https://forum.xda-developers.com/hardware-hacking/chromebooks/chromium-os-building-t3900245
Rebuilding Chromium OS kernel - a little extra...
Small improvement - removing dirty label from kernel name -
in scripts/setlocalversion # comment out:
if git diff-index --name-only HEAD | grep -qv "^scripts/package"; then
printf '%s' -dirty
fi
will rebuild it again to see if this helps for deployment
Rebuilt successfully - works OK on Acer Iconia W700, including camera & camera migration...
Notes -
in chroot
sudo enter-chroot
in kernel/
sudo make modules_install
sudo make install
outside chroot
in kernel/
sudo mkdir /boot
sudo make modules_install
sudo make install
in ~/Downloads
sudo mount /dev/sdb12 efi
sudo cp efi/syslinux/vmlinuz.A efi/syslinux/vmlinuz.A.83
sudo cp kernel/arch/x86/boot/bzImage efi/syslinux/vmlinuz.A
& for backup
sudo cp efi/syslinux/vmlinuz.A efi/syslinux/vmlinuz.A .96
I think this wraps it up - sadly still not booting Acer CB C720P
Linux localhost 4.14.96-09859-ga5c3f2f0428a #4 SMP PREEMPT Sun Feb 17 11:02:41 GMT 2019 x86_64 Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz GenuineIntel GNU/Linux
Not exactly... always something
Installing Chrome OS Kernel 4.1.4.96 removes crostini, wonder why that is...
solution might be flags - as new kernel, some flags might have been lost
chrome://flags
will check
crostini already there - must be some settings lost with new kernel, or dependencies unmet
NB - all previous commands presuppose you have r/w privilege as root, i.e. issue:
$ sudo mount -o remount,rw /
$ sudo mount -o remount,exec /mnt/stateful_partition
Note - my gripe after all this is that drivers I needed do not seem to load, or I did not select the proper entries in base.config / .config
What's the point of building a kernel if modules cannot be loaded
Google Chrome OS is well protected, & Chromium OS does not seem to bypass kernel protection.
nabil2000 said:
Methodology
Extract base.config from FydeOS 5.3.1 (Chromium OS v70) & merge in its settings into base.config extracted from ATB Chromium OS v72...
Busy doing this, as I am not good at coding, so cannot devise an automated script, doing it manually is a long bummer
My comment in Telegram, frustration included -
Modifying kernel basic.config of ATB v72 to incorporate all settings/modules of FydeOS 5.31 (v70) is so tedious, it's a nightmare - I wish there was a way to automate this with a script that merges in FydeOS basic.config entries that are not present in ATB v72 - I am crap at coding & scripting, so doing it manually, it takes forever, & I keep making mistakes :stuck_out_tongue_closed_eyes: - as I am not sure what stops ATB v72 Acer C720P from booting, I have to include all missing settings in basic.config before building the kernel.
Click to expand...
Click to collapse
hi, how did you extracted fydeos base.config ? if possible, can you provide me with a dropbox link to fydeos 5.3.1 base.config. Thanks
improving kernel 4.14.96
Hello2Clans said:
hi, how did you extracted fydeos base.config ? if possible, can you provide me with a dropbox link to fydeos 5.3.1 base.config. Thanks
Click to expand...
Click to collapse
Here is the dropbox link
[dropbox.com/s/esr407ybr5tev1u/configs.zip?dl=0](https://www.dropbox.com/s/esr407ybr5tev1u/configs.zip?dl=0)
it has the FydeOS 5.3.1 base config I extracted & your ATB v72 which I merged Fydeos 5.3.1 entries into - it updates to 4.14.96 from your 4.14.83 (replace z.config by .config)
It does compile a kernel OK - I did this manually, still learning how to do it signed. As I said details in my XDA thread.
I added all LCD panels modules, maybe it will finally allow to boot Chromebook C720P to GUI.
Oddly, I lose crostini, maybe unsigned kernels do that.
Linux localhost 4.14.96-09859-ga5c3f2f0428a #4 SMP PREEMPT Sun Feb 17 11:02:41 GMT 2019 x86_64 Intel(R) Core(TM) i3-2365M CPU @ 1.40GHz GenuineIntel GNU/Linux
You are welcome to improve on it - it builds, but modules I thought added did not work on MacBook Air nor graphics of Acer CB C720P
Hello2Clans said:
hi, how did you extracted fydeos base.config ? if possible, can you provide me with a dropbox link to fydeos 5.3.1 base.config. Thanks
Click to expand...
Click to collapse
I show how to do it in a previous post - but you need to be in a running FydeOS box, same with ATB.
sudo modprobe configs; zless /proc/config.gz
cat /proc/config.gz | gunzip > ~/Downloads/base.config
.config for Acer CB C720P
Still no luck with Acer Chromebook C720P - tried several changes to .config with make menuconfig & manually - boots to a blank screen still
Fydeos 5.3.1 does not have this problem.
Also tried just the .config of FydeOS on its own, & strangely no luck - there must be something else -
will now try this
# Display Panels
CONFIG_DRM_PANEL_LVDS=y
scratch - learning about kernel blobs /dev/sdx2 & /dev/sdx4
Just building the kernel & forcing in vmlinuz.A in /dev/sdx12 syslinux using bzImage (& modules in /lib/modules)
is apparently not enough...
It seems I also need to generate a new blob for the kernel which is /dev/sdx2
From documentation -
https://chromium.googlesource.com/chromiumos/docs/+/master/kernel_faq.md
we have
Kernel Root
pair A /dev/sda2 /dev/sda3
pair B /dev/sda4 /dev/sda5
in my case (as installed to usb)
Kernel Root
pair A /dev/sdb2 /dev/sdb3
pair B /dev/sdb4 /dev/sdb5
Some pointers here:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-dev/zmaziTddu5E
Major learning curve for me here...
what I need to do is upgrade the Arnoldthebat kernel blob KERN-A (4.14.83) with a new one for the new kernel (4.14.96).
I would appreciate if someone knew how to do this - that might be the cause issue of losing crostini when loading the new 4.14.96 instead of the original ATB.v72 4.14.83 one.
Share knowledge if you know how to do this, thanks.
Cooking -
I just flashed FydeOS 5.3.1 ROOT-A /dev/sdx2 blob which is 16MB over ATB v72 ROOT-A /dev/sdx2 blob which is 64MB & it booted, might be the solution I was looking for...
FydeOS (v70) is more compatible than ATB (v72) for many things. If the blob is involved, then it could be good news, easier than producing a new blob from scratch (don't know how either).
If so, working on blobs is an addition to-do list for hacking Chrome OS.
Hello. I am really glad someone is trying to build and install a custom kernel for ChromiumOS, as it will help fix *many* compatibility issues as well as it will make possible to add support for some hardware and features (for instance, audio over Bluetooth doesn't work as of now because the support library needed for BlueZ isn't included).
My computer isn't working properly and I don't have much space to build the kernel by my own, but I can help with testing and research. If you could share the binaries online (maybe a Git with releases?), this would be great.
What I have found and read about kernel on ChromiumOS so far:
1. Official documentation, it explains about the partition pairs:
http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format
2. More info (I think you have it already) but I think it is outdated as "console=tty1" doesn't work anymore (ChromiumOS now uses Frecon):
https://chromium.googlesource.com/chromiumos/docs/+/master/kernel_faq.md
3. This is a nice repo, it explains a lot, specially about kernel modules (drivers):
https://github.com/dnschneid/crouton/wiki/Build-chrome-os-kernel-and-kernel-modules
From what I have used and tested, you can use GRIB to either boot from the vmlinuz.A/B image or use the partition with the kernel, using the partition is much complicated as you found out because it would need some blobs/keys.
lfom said:
Hello. I am really glad someone is trying to build and install a custom kernel for ChromiumOS, as it will help fix *many* compatibility issues as well as it will make possible to add support for some hardware and features (for instance, audio over Bluetooth doesn't work as of now because the support library needed for BlueZ isn't included).
My computer isn't working properly and I don't have much space to build the kernel by my own, but I can help with testing and research. If you could share the binaries online (maybe a Git with releases?), this would be great.
What I have found and read about kernel on ChromiumOS so far:
1. Official documentation, it explains about the partition pairs:
http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format
2. More info (I think you have it already) but I think it is outdated as "console=tty1" doesn't work anymore (ChromiumOS now uses Frecon):
https://chromium.googlesource.com/chromiumos/docs/+/master/kernel_faq.md
3. This is a nice repo, it explains a lot, specially about kernel modules (drivers):
https://github.com/dnschneid/crouton/wiki/Build-chrome-os-kernel-and-kernel-modules
From what I have used and tested, you can use GRIB to either boot from the vmlinuz.A/B image or use the partition with the kernel, using the partition is much complicated as you found out because it would need some blobs/keys.
Click to expand...
Click to collapse
Thanks for the resources, I am getting old, so rather hard to learn & deal with new stuff - tinkering OSes & software is a hobby for me, but I usually do test stuff, not create - I had nice experience with Hackintosh, before I owned my own Macbook Air, still use it from USB's & PC when needed.
So far, I find out blob does not improve matters, it just gets used, like above blob from ATB or FydeOS does same thing.
The way I started in this was just to get Acer Chromebook C720P to load Android, chromefy carried on better than where I started.
The most successful outcome for me is Acer Iconia W700 which works with eve 73 (leaked on Telegram)...
I have the resources to build the kernel - but it is not doing what I want, like booting ATB v72 in Acer CB C720P - it i not vital, C720P works well with FydeOS & cyan or eve 71, just a challenge - why is ATB v72 not booting properly - i's a graphics VESA or LVDS bios issue I believe (C720P board uses LVDS for graphics), but where does it get loaded, I believe it's before loading modules...
FydeOS 5.31 boots to a black screen on my Miix320 but I have to wait until it loads everything then I must hit Ctrl+Alt+F2 then go back to main screen and then it works properly thereafter. Is your Acer the one bellow? Maybe it's related?
http://www.chromebookspecs.com/acer-c720p-chromebook
By the other hand, I cannot enable clicking for the detachable touchpad (+keyboard), what is almost a dealbreaker... Neither it goes to tablet mode when I detach it from the keyboard (not a big deal).
By the other hand, it boots correctly on a ThinkPad 8 tablet, but if freezes after a few seconds unless I use acpi=off or noacpi as kernel parameters, what makes it usesless since it only detects USB hardware.
From the text I linked it seems that the extra data added to the kernel before flashing it to a disk partition is both its signature and kernel paramenters, so you may want to check if there is any special paramenter needed for the kernel to boot correctly on your C720P.
FydeOS base upgrading kernel from 4.14.67 to 4.14.96
Kernel 4.14.96 upgrade progress -
I allowed
CONFIG_TCG_VTPM_PROXY=m
in .config
& this allowed me to update a chromefied FydeOS with eve/caroline 71 to eve 73 dev by using chromefy2!
this in turn allowed me to use an edimax Wifi USB dongle in MacBook Air -
the onboard WiFi still not loading, no trackpad but still progress :relaxed:
so modules do get loaded unlike my concern, it's just a matter to identify the proper entry in .config to load them when compiling the kernel...
now what are the proper entries for internal WiFi & trackpad?
Extra - Icing on the cake -
FydeOS 5.3.1 with eve dev 73 - putting the correct files in place allows to load kernel 4.14.83 & its modules to get crostini -
of course loading FydeOS kernel which is 4.14.67 stops Android 9.
This amended chromefy.sh script might help with MacBooks for trackpad & WiFi.
https://github.com/youngyou/chromefy/blob/master/chromefy.sh
*** Important note ***
To install the kernel modules in the Chrome OS box, you need to install Chromebrew to have access to the necessary commands -
$ curl -Ls http://git.io/vddgY | bash
In kernel source code folder:
$ sudo make modules_install
then copy bzImage over vmlinuz.A (after backing up the original)
I am planning to release an archive with kernels & modules including the one I built, it will be
vmlinuz.A.67(4.14.67); vmlinuz.A.83 (4.14.83); vmlinuz.A.96 (4.14.96); & corresponding /lib/modules folder
FydeOS 5.3.1 - ATB v72 - my built kernel
Notes -
Kernel 4.14.96 upgrade progress - I allowed CONFIG_TCG_VTPM_PROXY=m so this allowed me to update a chromefied FydeOS to eve 73 dev by using chromefy2! this in turn allowed me to use an edimax Wifi USB dongle in MacBook Air - the onboard WiFi still not loading, no trackpad but still progress :relaxed:
Icing on the cake - FydeOS 5.3.1 with eve dev 73 - putting the correct files in place allows to load kernel 4.14.83 & its modules to get crostini - of course loading FydeOS kernel which is 4.14.67 stops Android 9.
Cool progress - I managed to boot to the GUI of Acer CB C720P with eve dev v73 - still need to iron out something, but could get into guest mode, & to linux prompt - this is great :stuck_out_tongue_winking_eye: this is using kernel 4.14.83 on top of FydeOS 5.3.1
Finally managed to log into my google account in Acer CB C720P- next hurdle, will Android 9 work? - crostini back in the menu -
hurdle - despite changing vmlinuz.A to 4.14.83 or 4.14.96 - it still only loads FydeOS 4.14.67
so
I learnt something new, which means I need to learn more -
when you boot to a real chromebook from usb or internal, it will look for the kernel in the blob KERN-A /dev/sdx2, & will not use the vmlinuz.A in /dev/sdx12 -
so with FydeOS stuck with kernel 4.14.67 -
if I boot from other laptop, blob is not used, vmlinuz.A instead -
so I need to produce new KERN-A /dev/sdx2 blob for new kernel,
FydeOS blob is 16MB, ATB v72 blob is 64MB,
so to flash I need to play with partitions, tricky, & did not work...
still didn't figure out how to make a new blob for a new kernel...
RFC - how to produce a blob for loading a new kernel?
RFC - how to produce a blob for loading a new kernel?
If there is a way to find out how to produce a blob of an updated kernel for a genuine vanilla chromebook such as Acer Chromebook C720P - I will post it here...
Google open source documentation is very confusing about this - it might also be generated when setting up a Chromium OS from scratch (my thread on this is halted for now, but I have all the setup foundation to build)...
What I gather is that vmlinuz.A is the kernel, but for chromebooks, the kernel is also contained in the blob which is in partition /dev/sdx2 labelled KERN-A -
so I need to produce an image kern-a.bin which I then flash to /dev/sdx2 - with FydeOS 5.3.1 the KERN-A blob contains Kernel 4.14.67, with ATB v72 Kernel 4.14.83...
the dilemma is that KERN-A size for FydeOS 5.3.1 is 16 MB & for ATB v72 it is 64MB, so I cannot flash the latter onto the former.
I need to find out how to create a 64MB image for KERN-A from a given kernel, such as ATB v72 or my compiled one which is 4.14.96 -
Anyone who has a clue, & better has the correct instructions to do so, please help...
Actually, you don't need to: you can use the compressed image with GRUB2, and it will boot using your system and state (data) partition.
lfom said:
Actually, you don't need to: you can use the compressed image with GRUB2, and it will boot using your system and state (data) partition.
Click to expand...
Click to collapse
Using a modified FydeOS 5.3.1 as base, no matter I change the kernel, it boots its own 4.14.67 kernel on Acer CB C720P - however using non chromebook devices such as macbook, allow me to boot vmlinuz.A & its associated /lib/modules/...
Care to share how to use grub2 to override the above?
I'm going to show you how to build a custom kernel, and a custom boot.img.
Requirements
A linux OS
Kernel source code from Samsung
Android Image Kitchen (Required for the SEANDROID metadata it appends automatically)
GCC Cross Compilation Toolchain 4.8 (You may just clone the repo with git, or download a zip)
Hypothetical workspace directory on the filesystem: /workspace, now prepare it like this:
/workspace/kernel - this is where the kernel source code will be, this is what we will build. Extract the downloaded Kernel.tar.gz here
/workspace/build - this is the kernel compilation result, populated by the build
/workspace/toolchain - this is the required cross-compilation toolchain you download or check-out from the google link
/workspace/kitchen - Extract Android Image Kitchen here
Click to expand...
Click to collapse
Go to http://opensource.samsung.com/reception.do and search for SM-J415, download one of the results, extract Kernel.tar.gz to /workspace/kernel. I believe SWA stands for South West Asia, and MAE - Middle-east Africa, it doesn't matter which you pick, it is related to radio regulations.
Now overwrite the file /workspace/kernel/build_kernel.sh with:
Code:
#!/bin/bash
# The cross compilation toolchain path
export TOOLCHAIN=$(pwd)/../toolchain/arm-linux-androideabi-4.8
# This is the directory for the compiled kernel
export OUTDIR="O=$(pwd)/../build"
export PATH=$TOOLCHAIN/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-linux-androideabi-
export THREADS=$(nproc --all)
export COMMON_ARGS="-j$THREADS $OUTDIR arch=arm CFLAGS_MODULE=-fno-pic arch=arm"
if [ "$1" == "build" ]; then
make $COMMON_ARGS j4primelte_sea_open_defconfig
make $COMMON_ARGS
elif [ "$1" == "rebuild" ]; then
make $COMMON_ARGS
elif [ "$1" == "clean" ]; then
make $COMMON_ARGS distclean
make $COMMON_ARGS clean
else
echo "./build_kernel.sh build|rebuild|clean"
fi
Building kernel source code
Run the script:
$ cd /workspace/kernel/
edit: /workspace/kernel/arch/arm/configs/j4primelte_sea_open_defconfig
change CONFIG_SECURITY_DEFEX=y to CONFIG_SECURITY_DEFEX=n
$ bash build_kernel.sh build
It should build normally, if it fails there's something wrong with your OS setup. After a long time, you should see the compiled and compressed kernel with the DTP appended at:
/workspace/target/arch/arm/boot/zImage-dtb
The kernel configuration it created from the defconfig files in the kernel source tree is at
/workspace/target/.config
Build a new boot.img
$ cd /workspace/kitchen
$ bash unpackimg.sh /path/to/a/boot/or/recovery.img
Now you will have the unpacked kernel in: /workspace/kitchen/split_img/boot.img-zImage
Delete it
$ rm split_img/boot.img-zImage
Link the built custom kernel there instead
$ ln -s /workspace/target/arch/arm/boot/zImage-dtb /workspace/kitchen/split_img/boot.img-zImage
Now each time you create the boot.img, it will include your custom kernel instead.
Tweak the files and ramdisk as much as you want, and repackage the boot.img
$ bash repackimg.sh
Now you have a boot.img at /workspace/kitchen/image-new.img that is ready to flash to the device. You can unpack custom recoveries the same way as you unpacked boot.img to make them use your custom kernel.
Kernel configurations tried
CONFIG_SECURITY=n - boot loop
CONFIG_SECURITY_SELINUX=n - boot loop
CONFIG_SECURITY_DEFEX=n - works
CONFIG_DM_VERITY=n - works, does not prevent initramfs from using DM-VERITY, you still need some sort of ramdisk hack to disable verification of the next boot phase after initrd.
Often when editing the defconfig files, the same variables are declared in many different files so you might be better off using "sed' to change the variables, example:
$ grep -lr "CONFIG_SECURITY=y" | while read line; do sed -i 's/CONFIG_SECURITY=y/CONFIG_SECURITY=n/g' $line; done
When running "build_kernel.sh build", it will print "configuration written to .config" so verify that the variable was actually changed in the final config /workspace/build/.config
kapmino269 said:
and I think ,They aren't kernel see
Click to expand...
Click to collapse
No that is the latest kernel source code running on the latest firmware. You can use either of those 2 downloads from opensource.samsung.com
kapmino269 said:
it isn't working .
Click to expand...
Click to collapse
The kernel source code is on the Samsung opensource website.... there are two versions one that is MEA ( for Middle East and Africa roms) and the other one for SWA. It works if compiled properly
kapmino269 said:
ok
i have questions loop device depend on kernel and if it is .
How to add support?
Click to expand...
Click to collapse
It seems it depends on the kernel support but I haven't actually tried messing around that stuff
kapmino269 said:
it isn't working .
Click to expand...
Click to collapse
You need to install gcc, python and make before you run the command bash build_kernel.sh build
sudo apt install gcc make python
kapmino269 said:
I knew steps man I used Ubuntu for 2 years without windows .
thank you .
Click to expand...
Click to collapse
Do you tried make mrproper and make clean before you run build_kernel.sh?
kapmino269 said:
ok
i have questions loop device depend on kernel and if it is .
How to add support?
Click to expand...
Click to collapse
Type "make xconfig" in the kernel directory, and a window will open for configuring the .config file in that same directory.
Search for "Loopback device support" and add a checkmark (not a dot, so that the module is built into the kernel.)
kapmino269 said:
it isn't working .
Click to expand...
Click to collapse
Can you please provide a log or something? It sounds like you are missing dependencies in your operating system for building kernels.
how do you flash the new boot.img with a samsung device?
kapmino269 said:
By twrp
Click to expand...
Click to collapse
Thanks!!
I ended up using https://forum.xda-developers.com/showthread.php?t=2446269 which is pretty easy as well.
I am now stuck on how to enable wifi after flashing a different kernal.
Kernal = samsung opensource
Rom = nouget 7.1.1 (different to opensource kernal)
Any suggestions?
heavy load said:
Thanks!!
I ended up using https://forum.xda-developers.com/showthread.php?t=2446269 which is pretty easy as well.
I am now stuck on how to enable wifi after flashing a different kernal.
Kernal = samsung opensource
Rom = nouget 7.1.1 (different to opensource kernal)
Any suggestions?
Click to expand...
Click to collapse
Install the Magisk module LIBSECURE_STORAGE COMPANION
ashyx said:
Install the Magisk module LIBSECURE_STORAGE COMPANION
Click to expand...
Click to collapse
Thanks Ashyx, I had a play with your kernal on github, nice work there!
I ended up downloading a stock rom matching the samsung opensource kernal build number, worked out of the box.
kapmino269 said:
See that :
@ashyx any help
I NEED TO ADD SOME MODULES.
Click to expand...
Click to collapse
It's telling you the path to the defconfig doesn't exist.
Either the name is wrong or it doesn't exist in the config directory.
kapmino269 said:
This, I solved it yesterday, Thanks .
But I have 2 problems :
1- Device is arm and at bulid_kernel.sh tell me to use toolchain arch64 ,
Which I should Use arm or arm64 ,
I confused as cpu is arm64 .
https://www.qualcomm.com/products/snapdragon/processors/425
Or
Ndk
https://developer.android.com/ndk/downloads/index.html
2- Which command I should write after menuconfig
./build_kernel.sh
Or
make -jX .
Click to expand...
Click to collapse
Just use whichever is in the build script.
You will need to add menuconfig to build_kernel.sh before make or your changes will be lost.
Then run build_kernel.sh
kapmino269 said:
@ashyx ,all is ok .
The error from clang and there is 2 config files .
Fixed and I will test kernel but I have problem when compiling I choose lz4 type ,do U see I should choose another .
Also where is zimage now ,i compiled manually not with build_kernel.sh .
Click to expand...
Click to collapse
You don't need the export arguments which are contradictory anyway, as you have already defined your toolchain and architecture before hand.
Also the boot image does not need to be lz4. The compiler will tell you where the finished zImage is when completed. You should find it in the boot directory of the arm64 directory if you are not using OUT_DIR statements.
kapmino269 said:
Sorry ashyx this is last thing ,
-You told me later that device is arm not arm64 .
In Your twrp thread .
-Also defconfig of device in /arch/arm .
-Arch=arm in build_kernel.sh .
-Gsi system armaonly only work on the device .
-All apps told that device is arm .
I confused ,
Please tell that it is right to use arm64 tool chain .
Or How did U build it ?
By arm64 toolchain or arm toolchain ?
Very Thank U .
Click to expand...
Click to collapse
I was just going by the screen shot you posted. Like I said your commands are contradictory.
You have both arm and arm64 toolchains defined in the same script.
You also have an export statement for arm64 directly under a statement for an arm toolchain.
Not sure why you added both?
As far as I can see the architecture you're compiling for is arm, so you need an arm toolchain.
kapmino269 said:
It contains errors
Click to expand...
Click to collapse
This is the script I use.
You will need to modify the path to your toolchain.
can i use the source code to build kernel for android 10 one ui if the source built for mm
Hey, does anyone know how to get the propietary blobs out of the device? I'm kinda done with MIUI and i wanna try to compile some custom rom and maybe a legit twrp.
SanHelios said:
Hey, does anyone know how to get the propietary blobs out of the device? I'm kinda done with MIUI and i wanna try to compile some custom rom and maybe a legit twrp.
Click to expand...
Click to collapse
lol i am looking for the same
check this out
vamsi209 said:
lol i am looking for the same
check this out
Click to expand...
Click to collapse
what shall i check out?
SanHelios said:
what shall i check out?
Click to expand...
Click to collapse
Extracting proprietary blobs from LineageOS zip files | LineageOS Wiki
wiki.lineageos.org
SanHelios said:
Hey, does anyone know how to get the propietary blobs out of the device? I'm kinda done with MIUI and i wanna try to compile some custom rom and maybe a legit twrp.
Click to expand...
Click to collapse
Trying to look for the Chinese tool to flash the unofficial TWRP, once I manage to do that will try help on grabbing those needed proprietary blobs. May need guide on how to pull the blobs, am still a noob
dan079 said:
Trying to look for the Chinese tool to flash the unofficial TWRP, once I manage to do that will try help on grabbing those needed proprietary blobs. May need guide on how to pull the blobs, am still a noob
Click to expand...
Click to collapse
Me too... TWRP is tricky, since it can only be done by this OneInject-function of TWRP, but it's possible. I tried the 'current' unofficial release of TWRP for this, but all i got was a reboot to BL.
vamsi209 said:
Extracting proprietary blobs from LineageOS zip files | LineageOS Wiki
wiki.lineageos.org
Click to expand...
Click to collapse
yshalsager, who created the Firmware-script, told me the same.. here is his answer.
"
Hi,
Thanks for your words, glad to hear my work helps.
You can use LineageOS extract files script that will generate vendor tree for you. It is available in any device tree but you should use one of your device so it reads from its proprietary-files.txt or something.
"
Maybe LOS is closer than we think.
SanHelios said:
yshalsager, who created the Firmware-script, told me the same.. here is his answer.
"
Hi,
Thanks for your words, glad to hear my work helps.
You can use LineageOS extract files script that will generate vendor tree for you. It is available in any device tree but you should use one of your device so it reads from its proprietary-files.txt or something.
"
Maybe LOS is closer than we think.
Click to expand...
Click to collapse
niceee, so for mix 4, i extracted the twrp trees using this,
[SCRIPT] TWRP device tree generator
Create a TWRP-compatible device tree only from an Android recovery image (or a boot image if the device uses non-dynamic partitions A/B) of your device's stock ROM. It has been confirmed that this script supports images built starting from...
forum.xda-developers.com
setup the local repo for building twrp trees, using these
1. Installing the tools
A Python library/script to automatically generate TWRP-compatible device tree from a boot/recovery image - twrpdtgen/twrpdtgen
github-wiki-see.page
tried building but the device doesn't lunch after following the steps shown above,
Code:
http://www.hastebin.com/jonexiyowu.md
and one of the dev https://github.com/imjyotiraditya , helped me build an aospa rom for g8x,
now he is on to building twrp for our device odin.
if anyone has twrp trees, we can try geting aospa build ready for our device
vamsi209 said:
niceee, so for mix 4, i extracted the twrp trees using this,
[SCRIPT] TWRP device tree generator
Create a TWRP-compatible device tree only from an Android recovery image (or a boot image if the device uses non-dynamic partitions A/B) of your device's stock ROM. It has been confirmed that this script supports images built starting from...
forum.xda-developers.com
setup the local repo for building twrp trees, using these
1. Installing the tools
A Python library/script to automatically generate TWRP-compatible device tree from a boot/recovery image - twrpdtgen/twrpdtgen
github-wiki-see.page
tried building but the device doesn't lunch after following the steps shown above,
Code:
http://www.hastebin.com/jonexiyowu.md
and one of the dev https://github.com/imjyotiraditya , helped me build an aospa rom for g8x,
now he is on to building twrp for our device odin.
if anyone has twrp trees, we can try geting aospa build ready for our device
Click to expand...
Click to collapse
hey, i'm trying it right now... was able to manage a device tree from the latest weekly of the EU-rom. Repo is syncing right now for the aosp-twrp-11 repository.
U used the same script for the recovery trees?
vamsi209 said:
U used the same script for the recovery trees?
Click to expand...
Click to collapse
yes, i extracted it from the boot.img.
Update... build/envsetup.sh error, anyone any suggestions?
Update managed to get envsetup.sh to work, got following error messages
source build/envsetup.sh
including device/xiaomi/odin/vendorsetup.sh
COMMON_LUNCH_CHOICES: Befehl nicht gefunden.
COMMON_LUNCH_CHOICES: Befehl nicht gefunden.
lunch twrp_odin-eng
In file included from build/make/core/config.mk:291:
In file included from build/make/core/envsetup.mk:266:
build/make/core/product_config.mk:155: error: Can not locate config makefile for product "twrp_odin".
23:22:04 dumpvars failed with: exit status 1
WARNING: Trying to fetch a device that's already there
Traceback (most recent call last):
File "/home/dave/AOSP-Recovery/vendor/twrp/build/tools/roomservice.py", line 431, in <module>
fetch_device(device)
File "/home/dave/AOSP-Recovery/vendor/twrp/build/tools/roomservice.py", line 399, in fetch_device
git_data = search_gerrit_for_device(device)
File "/home/dave/AOSP-Recovery/vendor/twrp/build/tools/roomservice.py", line 86, in search_gerrit_for_device
device_data = check_repo_exists(git_data, device)
File "/home/dave/AOSP-Recovery/vendor/twrp/build/tools/roomservice.py", line 62, in check_repo_exists
raise Exception("{device} not found,"
Exception: odin not found,exiting roomservice
In file included from build/make/core/config.mk:291:
In file included from build/make/core/envsetup.mk:266:
build/make/core/product_config.mk:155: error: Can not locate config makefile for product "twrp_odin".
23:22:05 dumpvars failed with: exit status 1
** Don't have a product spec for: 'twrp_odin'
** Do you have the right repo manifest?
Anyone a good guess?
Did you had any luck, or any chance I can help?
Puksom said:
Did you had any luck, or any chance I can help?
Click to expand...
Click to collapse
well, i made some progress, but i failed again. I posted a thread in the official twrp forum. Maybe you might want to take a look at it.. thx.
Post in thread '[DEV]How to compile TWRP touch recovery' https://forum.xda-developers.com/t/dev-how-to-compile-twrp-touch-recovery.1943625/post-85686505
Puksom said:
Did you had any luck, or any chance I can help?
Click to expand...
Click to collapse
I'm a total beginner, so i might be wrong. But as far as i can tell, the makefiles of the extracted device tree need to be update or even completely rebuild.
Hi, it seems like I was able to execute the script successfully.
It didn't work on Windows because it got stuck on the execution of unpackimg.bat.
I ran it on Linux and it worked (after chmod 777 of boot.img). This is the command I ran:
python3 -m twrpdtgen -o ./odin ./boot.img
output:
Code:
TWRP device tree generator
Version 1.3.0
[INFO] Cloning AIK...
Done! You can find the device tree in odin/xiaomi/odin
I took boot.img from the latest MIUI 12.5.7.0 China Stable
Now I have what it seems to be the device tree (odin.zip) but I don't know what to do it it or what it is.
radoinc said:
Hi, it seems like I was able to execute the script successfully.
It didn't work on Windows because it got stuck on the execution of unpackimg.bat.
I ran it on Linux and it worked (after chmod 777 of boot.img). This is the command I ran:
python3 -m twrpdtgen -o ./odin ./boot.img
output:
Code:
TWRP device tree generator
Version 1.3.0
[INFO] Cloning AIK...
Done! You can find the device tree in odin/xiaomi/odin
I took boot.img from the latest MIUI 12.5.7.0 China Stable
Now I have what it seems to be the device tree (odin.zip) but I don't know what to do it it or what it is.
Click to expand...
Click to collapse
This is great, so we know this script works and does what it is supposed to do...
I checked the makefiles to see if there are any differences, but there are none. So it suggests that it doesn't matter, from which version you get the files from. I love, that the users of the Mi Mix 4 are more open so compiling than the community of the MI 11 Ultra is..
SanHelios said:
This is great, so we know this script works and does what it is supposed to do...
I checked the makefiles to see if there are any differences, but there are none. So it suggests that it doesn't matter, from which version you get the files from. I love, that the users of the Mi Mix 4 are more open so compiling than the community of the MI 11 Ultra is..
Click to expand...
Click to collapse
I'm trying to replicate your steps but I get the same "Can not locate config makefile for product "twrp_odin"." as you did above. In the other topic I see you managed to get past that step.
I see you get some output after executing envsetup.sh and it seems like this is related to the device tree.
Can you please share what you did with the device tree before attempting to compile twrp? I'd like to try myself but I can't find clear instructions.
radoinc said:
I'm trying to replicate your steps but I get the same "Can not locate config makefile for product "twrp_odin"." as you did above. In the other topic I see you managed to get past that step.
I see you get some output after executing envsetup.sh and it seems like this is related to the device tree.
Can you please share what you did with the device tree before attempting to compile twrp? I'd like to try myself but I can't find clear instructions.
Click to expand...
Click to collapse
Acutally i left it completely unchanged, the only thing i did was to change the repository. I deleted the aosp-repository and took the omni-twrp-repository
(https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni)
mkdir twrp
cd twrp
repo init -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
repo sync
after syncing was complete, i followed these instructions
4. Build TWRP from source
A Python library/script to automatically generate TWRP-compatible device tree from a boot/recovery image - twrpdtgen/twrpdtgen
github-wiki-see.page
SanHelios said:
Acutally i left it completely unchanged, the only thing i did was to change the repository. I deleted the aosp-repository and took the omni-twrp-repository
(https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni)
mkdir twrp
cd twrp
repo init -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
repo sync
after syncing was complete, i followed these instructions
4. Build TWRP from source
A Python library/script to automatically generate TWRP-compatible device tree from a boot/recovery image - twrpdtgen/twrpdtgen
github-wiki-see.page
Click to expand...
Click to collapse
Thanks! Now I managed to get the same result as you. The error seems to be raised by mkbootimg.py:
Python:
def write_header(args):
BOOT_IMAGE_HEADER_V1_SIZE = 1648
BOOT_IMAGE_HEADER_V2_SIZE = 1660
BOOT_MAGIC = 'ANDROID!'.encode()
if (args.header_version > 2):
raise ValueError('Boot header version %d not supported' % args.header_version)
To me it seems like this Omni repo includes old version of mkbootimg.py, because in the google repos I can see that the current version of this function looks like this:
Python:
def write_header(args):
if args.header_version > 4:
raise ValueError(
f'Boot header version {args.header_version} not supported')
if args.header_version in {3, 4}:
return write_header_v3_and_above(args)
It seems like Boot header version 3 was introduced with Android 11: https://source.android.com/devices/bootloader/boot-image-header
I think we can't do much with the Omnia repos until they get updated with current mkbootimg.
radoinc said:
Thanks! Now I managed to get the same result as you. The error seems to be raised by mkbootimg.py:
Python:
def write_header(args):
BOOT_IMAGE_HEADER_V1_SIZE = 1648
BOOT_IMAGE_HEADER_V2_SIZE = 1660
BOOT_MAGIC = 'ANDROID!'.encode()
if (args.header_version > 2):
raise ValueError('Boot header version %d not supported' % args.header_version)
To me it seems like this Omni repo includes old version of mkbootimg.py, because in the google repos I can see that the current version of this function looks like this:
Python:
def write_header(args):
if args.header_version > 4:
raise ValueError(
f'Boot header version {args.header_version} not supported')
if args.header_version in {3, 4}:
return write_header_v3_and_above(args)
It seems like Boot header version 3 was introduced with Android 11: https://source.android.com/devices/bootloader/boot-image-header
I think we can't do much with the Omnia repos until they get updated with current mkbootimg.
Click to expand...
Click to collapse
My question is, do the makefiles from the devicetree need to be adjusted or completely rebuild to android 11 parameters? I.e. rhe command "add_lunch_combo" is obsolete and "COMMAND_LUNCH_CHOICES" took its place..
Sorry in advance for this nooby questions...