Whats the right way of compiling a module for the Atrix kernel?
I'm currently using the stock android 2.6.32.9 linux sources and the Atrix's config, although I can't get the kernel to agree with the modules I'm trying to build.
Motorola didn't use froyo sources to compile the kernel, they used vanilla 2.6.32.9 to do it.
The last problem is that modules are built as ARMv5 instead of ARMv7, probably since there is a patch setting the system type to Tegra 2.
Compile Atrix 2.3.6 kernel mods
I've grabbed the source for the 91 kernel source since the 141 kernel source has not be release. I need to get iso9660 and udf file system support.
I've followed this thread on compiling the kernel http://forum.xda-developers.com/showthread.php?t=1141506
I can successfully compile the kernel and the kernel modules, but I keep getting an invalid module format error, what's a revised way for compiling kernel mods?
[email protected]:/opt/dev/kernel modules/kmods$ sudo insmod ext4.ko
insmod: error inserting 'ext4.ko': -1 Invalid module format
[email protected]:/opt/dev/kernel modules/kmods$ sudo insmod udf.ko
insmod: error inserting 'udf.ko': -1 Invalid module format
My end Goal after I get the kernel mods working is to compile a kernel with swap support.
Thanks for any help rendered.
When you get the insmod errors try looking at dmesg at the tail end of the log, usually that error means the version string doesn't match what is baked into the kernel.
Cheers!
cpuchip said:
My end Goal after I get the kernel mods working is to compile a kernel with swap support.
Thanks for any help rendered.
Click to expand...
Click to collapse
The general rule is that you do not want to enable swap on a flash based file system, but that is up to you.
Are you getting the module load errors against your own kernel, or are you trying to reproduce the stock kernel and your modules fail when loading against the real stock kernel?
If the latter, there are many things to look at. First would be your cross tools. These could easily produce incompatable code. But if the error is just a symble not found, then most likely your kernel config does not match the running kernel.
EDIT: missed the error messages, but it still is about the same answer. The compiler is generating the wrong code either becasue it is different from that whcih generated the running kernel, or the config options comming out of your kernel tree are not matching.
Have you tried actually running your kernel?
Thanks so much for the advice from the two of you. These are my dmesg errors. they pop up right after I enter the command: insmod isofs.ko
[505123.289798] usb_ether_get_stats
[505123.322414] isofs: no symbol version for module_layout
I'm new to kernel work. I used the config from my phone directly, it was located at /proc/config.gz
I used the cross compilers as defined in the post I linked to in my first post. unfortunately I don't have the source to 141, just 91, what's on source forge from motorola. I don't know if they did any changes between the two, but the release version was slightly different between the two.
I'm okay with burning through external sd cards for the sake of having more browser tabs open, and an overall more responsive system.
---------- Post added at 10:44 PM ---------- Previous post was at 10:20 PM ----------
I saw in one thread that you have to compile the kernel first before the modules. I did that, and now I'm getting a new error:
[506616.823352] usb_ether_get_stats
[506616.867837] isofs: disagrees about version of symbol module_layout
seems to be a version conflict. do I have to inject that in on compile?
Have a look here: http://forum.xda-developers.com/showthread.php?t=1014010
Not the modules you are talking about, but same error.
For cifs/smb I ended up using smbnetfs, taking advantage of the fuse fs already in place. /dev/fuse has to be set group fuse with rw for group, and user adas has to be in group fuse.
Cheers!
Related
Need help with compiling modules for Dell Streak kernel.
Because i could not find cifs.ko module for mounting network shares for Dell Streak stock Froyo 318, i decided to make it on my own.
I did not have any clue how can it be done, but with lot of googling and reading forum posts on xda and modaco, i got vague idea how i can do it.
There was lots of trial-and-error attempts until i learned how to use all comands and tools, and here is final list of things id did to make it:
Already had VMWare workstation with Ubuntu 10.10 instalation, i got Android Froyo source tree from net, replaced kernel with Dell Streak 3.09 kernel (from opensource.dell.com) which is also Froyo, i think, and is closest to my kernel version (318).
Got toolchains from codesourcery.com
Extracted my phone config from /proc/config.gz, renamed to .config, uncommented and changed option for CONFIG_CIFS=m. Did same for tun.ko module which i did not need, but just for comparison. Placed .config file in kernel root.
Did comand:
Code:
make ARCH=arm CROSS_COMPILE=/path-to-toolchains/bin/arm-none-eabi- modules
after confirming some options (irellevant to this), and some compiling in terminal, all went ok without errors and did produce modules in fs/cifs and drivers/net
i also did some debugging to reduce filesize, bud also had tried module without debugging with same result (see below)
transferred modules to my phone in /system/lib/modules and tried to load them via insmod.
loaded tun.ko without problem (i dunno whteher is working because i have no means to try it and have no need for it). i compiled it just to see whether it will be loaded in phone kernel. it DID load without error messages.
when tried to load cifs.ko via insmod cifs.ko, got this error message:
Code:
insmod: init_module 'cifs.ko' failed (no such file or directory)
dmesg provided following errors:
Code:
cifs: Unknown symbol slow_work_register_user
cifs: Unknown symbol slow_work_enqueue
found in similar thread for Galaky Tab that i need to compile slow_work module and load it before because of that dependancies, Found another thread with instructions for compiling slow-work, followed them:
copied all slow-work files in cifs, Remove the calls to round_jiffies in fs/cifs/slow-work.c: round_jiffies(jiffies + SLOW_WORK_CULL_TIMEOUT)); changed to
jiffies + SLOW_WORK_CULL_TIMEOUT); AND round_jiffies(jiffies + SLOW_WORK_OOM_TIMEOUT)); TO jiffies + SLOW_WORK_OOM_TIMEOUT);
edited fs/cifs/Makefile and added slow-work.o to the obj-$(CONFIG_CIFS) += cifs.o line: obj-$(CONFIG_CIFS) += cifs.o slow-work.o.
Ran make command from above, got both modules (cifs.ko and slow-work.ko) in fs/cifs directory without errors.
Copied them to phone, done insmod and got error for slow-work:
Code:
insmod: init_module 'slow-work.ko' failed (no such file or directory)
dmesg provided following message:
Code:
slow_work: module licese "unspecified" taints kernel
slow_work: Unknown symbol mutex_lock_nested
Now i'm clueless (like i haven't been all the time :-D).
All modules compiled without errors, tun.ko will load, cifs.ko apparently need slow-work to run, slow-work compiled, but can't load.
So, if somebody can help, or point me where is possible error, i will be very grateful.
UPDATE:
Found references for missing slow_work modules in cifsfs.c and misc.c, deleted them and ran make.
produced cifs.ko without error.
LOADED cifs in phone without error!!!! With lsmod it shows that module is loaded!
BUT, does not work! Cannot mount anything. When tried with cifsmanager or manually via terminal get error message "No such device" which points that there is no valid cifs.ko module in kernel.
So, module is produced and loaded in phone without errors, BUT DOES NOT WORK. It looks like Streak Froyo need slow-work module after all...
I'm desperate, please if somebody did compiling cifs.ko for Streak, or use cifs mounting with found module, share your thoughts and experiences.
Thanks everybody.
CIFS and Slow worked - compiled
I was able to successfully compile both the slow work module and the CIFS module for the most recent 4G EVO. Took me a couple of days, but I think I could walk you through the specifics fairly easily. Let me know if you want the details.
of course I do!
please write your way.
Sent from my Dell Streak using XDA Premium App
dmandic, did you ever get this working? I went through similar pains doing this for the xperia arc, and did manage to get it working. I have some thoughts about your situation if you want to discuss further.
please, any help is appreciated.
i'm open to any kind of suggestions.
write your thoughts here.
Sent from my Dell Streak using XDA Premium App
Hmm. I originally stumbled upon this thread because I was searching for others who compiled a cifs.ko against a kernel with version "2.6.32.9-perf" (from the android about phone menu), hoping to avoid going through figuring out how to do this. I saw that others with the Dell Streak also had this kernel, and then I found your thread.
Anyway, I was thinking that maybe the kernel you got from the dell website had a slightly different version than your phone (because your phone is 3.18 vs 3.09), and that's why you're getting runtime symbol errors. I thought maybe there's a chance you needed exactly 2.6.32.9-perf and I could offer you mine. However, I downloaded the dell 3.09 kernel source and found that it's also 2.6.32.9-perf... so I guess that idea's out the window. (By the way, is this what your phone shows?)
Well just for kicks, I actually compiled slow-work and cifs from the dell kernel and loaded it on my xperia arc phone and they worked (was able to use CIFSManager).
It's a long shot but just in case there's something about the way you're compiling them, I attached them here - give it a try. [Edit: Duh, I forgot I need your .config file. Email it to me and I'll re-post these]
I tried out the Xperia files from the thread [DEV]TUN, CIFS modules files on my Streak 5. It did not go well, these are my messages from dmesg.
Code:
<4>[ 341.187030] tun: Unknown symbol dynamic_debug_enabled
<4>[ 341.190600] tun: Unknown symbol dynamic_debug_enabled2
<4>[ 341.219513] slow_work: module license 'unspecified' taints kernel.
<4>[ 341.220411] slow_work: Unknown symbol mutex_lock
<4>[ 341.638099] cifs: Unknown symbol mem_section
<4>[ 341.638397] cifs: Unknown symbol mutex_lock
<4>[ 341.641609] cifs: Unknown symbol slow_work_register_user
<4>[ 341.642835] cifs: Unknown symbol slow_work_enqueue
Looks like the kernel is differently compiled and or still some modules missing.
I noticed that in another thread Samba/CIFS for Motorola defy froyo nls_utf8.ko also has been required, however I do not have the 2.6.32.9-perf version of this to try it out.
How has the progression been for you guys?
Hi there,
I would have posted this in /dev but you know...first post.
I was trying to apply these kernel modules: http://forum.xda-developers.com/showthread.php?t=1557868
but I'm getting the error "insmod: init_module '/system/lib/modules/cifs.ko' failed (Exec format error)", or if i use the busybox insmod i get the following error: "insmod: can't insert '/system/lib/modules/cifs.ko': invalid module format"
Are updated versions available for 2.6.39.4? I'm guessing the ones for 2.6.36.3 aren't inter-operable.
I haven't used the other bash-4.2.zip and config from the above link, is that necessary for this to work?
Thanks for any tips on getting these kernel modules working.
Thanks,
abactor
IRC channel
Is there an IRC channel that's in use for sony tablet S, by any chance?
compile module yourself?
You might be successful compiling the kernel modules yourself from the available source code and a crossplatform compiler on linux. It has worked for me for the tun module
Source code at sony.net, I cannot publish external links yet. But you can find the link e.g. in this thread at first page http://forum.xda-developers.com/showthread.php?t=1473621
The free Sourcery G++ Lite for ARM GNU Linux did a good job for me.
I don't know of any Tablet S IRC channels, but it would be cool if there was.
As for the modules, you do need to recompile it. Kernel modules (in practically every Linux flavour) are completely incompatible, even across minor revisions, but recompiling against the newest code and headers should yield the same result with a new module.
The Sony.net link walsera mentioned is (I believe) this one
Thanks guys,
I'll look into it. I've compiled c code for android under mingw, but I don't have a linux toolchain setup. Anyone try to compile these sorts of things on the device itself (I.e. not cross_compiled)? I just started playing around with a native android/arm gcc toolchain, but I was having linker issues I think, with crt0.o and libc and whatnot.
Thanks and take care,
Abactor
I've never tried it natively on the device, but there have been a couple of developments into native versions of gcc and whatnot, so that may be worth a look. You can always compile on your PC, then copy the ko over...
After mounting a debian chroot on the tablet and installing the needed tools, unpacking the kernel source, and copying over config.gz, and editing .config to build the needed modules then calling make modules everything seems to work. What's the best way to make them available and what modules do people need? I've done ntfs and tun so far.
Take care
A
Okay so heres my problem.. Im currently trying to compile modules to add to my z902. i have the 3.0.8 kernel source used for the mele which uses the same allwinner a10 proccessor. I have done some looking around and found that in order for android to load the module it needs to be compiled with the correct vermagic as well.. i managed to get info from both a module already on the device and from the module i compiled.
My module retrieves the following info when using modinfo()...
filename: hid-sony.ko
license: GPL
alias: hid:b0003v0000054Cp0000024B
alias: hid:b0005v0000054Cp00000268
alias: hid:b0003v0000054Cp0000042F
alias: hid:b0003v0000054Cp00000268
depends:
vermagic: 3.0.8+ preempt mod_unload modversions ARMv7
the original im comparing to looks as follows...
filename: sun4i-keypad.ko
alias: platform:sw-keypad
license: GPL
author: Aaron.maoye<[email protected]>
description: SW keypad driver
depends:
vermagic: 3.0.8+ preempt mod_unload modversions ARMv7
this is what it took me a while to acheive. the problem is when trying to insert the module into linux using the insmod command i get this error..
insmod: init_module 'hid-sony.ko' failed (Exec format error)
afterwords i ran dmesg and noticed a line that looks as follows:
hid-sony: dissagrees about version of symbol module_layout
after doing this i read about a way to overlook the vermagic by using modprobe..
here i ran into another problem.. when executing modprobe as follows i recive this error..
#busybox modprobe hid-sony.ko
modprobe: chdir(/lib/modules): No such file or directory
after recieving this error i tried making the directory and typed in the same command..
it returned that modules.dep was not found..i looked into this file and it seems to be where linux stores all the initiated drivers.
I searched high and low and could not find this file anywhere on the system.
my question is.. What the hell am i doing wrong..? lol
I compiled the entire kernel first.. then i compiled the modules afterwords to a set location.
does the baseband version info have anything to do with this because i couldnt find any info on it..
the z902 has 1.2.3 as a baseband..? is it possible i may not have the correct kernel source..?
anyone who helps me solve this i will personally buy them a unit and set it up for them.. lol
BUMP
Bump.. please someone help... how can i make modules.dep without depmod in my busybox applets.. anyone know if i can update busybox within android or through linux. id really like to add support for some controllers and bluetooth dongles. im pretty sure the module is setup and compiled right. but its trying to install it in the wrong place. unless it matters that android is compiled within the kernel as well.. because the tutorial i read through didnt say it was neccisary. i belive it was aimed towards the mele a2000. but its an allwinner a10 with the same kernel. 3.0.8+.. the only thing in not sure of is the build number. the z902 shows a 1.2.3 build. and i have no clue what build number the mele a2000 uses.
prob a waste of time as nobody seems interested...
I managed to update busy box and add depmod to the list of applets. After doing so I tried mod probe and the module still won't load. Don't have the info on the error in front of me but it was something to the effect that it was not compatible with the kernel. Back to square one. Going to try compiling it with android over the weekend and give it another attempt. Need to find some kind of a work around for actual controllers for this thing. USB/bt joystick center would be a phenomenal upgrade for this device.
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'm cross-posting from "General Discussion", I think I picked the wrong forum. Sorry!)
I have:
Downloaded the exact kernel version running on my device from an AOSP mirror (4.9.170) (https://github.com/aosp-mirror/kernel_common.git)
Downloaded the exact compiler used to compile the kernel from my device:
Ran `cat /proc/version`, which returns "Linaro GCC 5.3-2016.05", which I downloaded from https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/aarch64-linux-gnu/
Took the kernel configuration from `/proc/config.gz`, copied it to the kernel source directory `kernel_common` as `.config`
Ran `make ARCH=arm64 CROSS_COMPILE=xxx oldconfig`
What I'm seeing:
First, the downloaded kernel source for 4.9.170 seems to think that my `config` is incomplete, since it will prompt me to answer ~15 extra configuration questions.
Second, this old Linaro compiled doesn't appear to support `-fstack-protector-strong` despite it being explicitly enabled in the `/proc/config.gz` file. So I end up disabling it with `./scripts/config --disable CONFIG_CC_STACKPROTECTOR_STRONG`
Finally, after successfully compiling, I take `net/ipv4/tcp_westwood.ko`, just as a test module, and try to load it on my Android device, and it fails:
`insmod: failed to load tcp_westwood_5.ko: Exec format error`
And in dmesg output: `tcp_westwood: disagrees about version of symbol module_layout`
My questions:
Can I assume that the `/proc/config.gz` file is not the actual file used to compile the running kernel, considering it doesn't completely configure the 4.9.170 kernel?
Am I on the right path to getting a kernel module that my kernel will load?
Background information:
I'm hoping this isn't very relevant, but just to head off some questions
This is a T95 Android TV device running what appears to be, to this newbie's eyes, a very Frankenstein'd Android 10 install (See https://www.cnx-software.com/2020/0...-comes-with-mali-g31-gpu-supports-android-10/)
I can't find any official - or unofficial - source for this device, which is why I'm going to all the trouble above.
I really appreciate any help, thank you!