Related
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!
I am trying to compile and insert the CFG80211.ko module
I have built an Ubuntu VM and installed the correct codesourcery cross compiler.
I have been able to build several modules which successfully insert. (ntfs, lib80211, all three lib80211_crypt modules, all three wusb modules, uwb, veth etc etc)
however the cfg80211.ko module always fails with invalid argument.
dmesg reports :-
Code:
[140146.246732] cfg80211: disagrees about version of symbol wireless_send_event
[140146.246751] cfg80211: Unknown symbol wireless_send_event (err -22)
cfg80211 depends on rfkill which is, as far as I cant tell, precompiled into the phone kernel.
the relevant section of the config file is as follows:-
Code:
#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_LL is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
CONFIG_BT_HID=m
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_WIRELESS_COMPAT=m
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_DEFAULT_PS is not set
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_WEXT=y
# CONFIG_WIRELESS_EXT_SYSFS is not set
CONFIG_LIB80211=m
CONFIG_LIB80211_CRYPT_WEP=m
CONFIG_LIB80211_CRYPT_CCMP=m
CONFIG_LIB80211_CRYPT_TKIP=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
# CONFIG_MAC80211_RC_PID is not set
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_PM=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
#
# Device Drivers
#
Full .config file attached below.
I have tried converting RFKILL to a module, in order to enable CONFIG_RFKILL_INPUT to yes but the compile completely fails when this is set.
I have added WIRELESS_COMPAT details in the Kconfig file but this did not help and I am now lost as to how to troubleshoot this?
Anyone have any idea on what might be missing?
If you're able to compile the modules, you should be able to compile the kernel - do the modules insmod against the compiled kernel?
Entropy512 said:
If you're able to compile the modules, you should be able to compile the kernel - do the modules insmod against the compiled kernel?
Click to expand...
Click to collapse
Yes all the other modules I mentioned all insert fine the ones that I have compiled that dont insert have dependancies that all stem back to the cfg80211.ko that is giving me the messages in the first post.
from the documentation cfg80211 is dependant on RFKILL which is precompiled into the kernel.
Entropy512 said:
If you're able to compile the modules, you should be able to compile the kernel - do the modules insmod against the compiled kernel?
Click to expand...
Click to collapse
Ahhh rereading your post, I see what you mean, I haven't installed the built kernel (though I did do the full build) on the phone, not entirely sure how to package it and I haven't tried to look because I really dont want to install a full kernel on the phone.
In any case I have used the default samsung config to build from fro the correct kernel.
curioct said:
I am trying to compile and insert the CFG80211.ko module
I have built an Ubuntu VM and installed the correct codesourcery cross compiler.
I have been able to build several modules which successfully insert. (ntfs, lib80211, all three lib80211_crypt modules, all three wusb modules, uwb, veth etc etc)
however the cfg80211.ko module always fails with invalid argument.
dmesg reports :-
Code:
[140146.246732] cfg80211: disagrees about version of symbol wireless_send_event
[140146.246751] cfg80211: Unknown symbol wireless_send_event (err -22)
cfg80211 depends on rfkill which is, as far as I cant tell, precompiled into the phone kernel.
the relevant section of the config file is as follows:-
Code:
#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_LL is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
CONFIG_BT_HID=m
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_WIRELESS_COMPAT=m
CONFIG_CFG80211=m
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_DEFAULT_PS is not set
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
CONFIG_CFG80211_WEXT=y
# CONFIG_WIRELESS_EXT_SYSFS is not set
CONFIG_LIB80211=m
CONFIG_LIB80211_CRYPT_WEP=m
CONFIG_LIB80211_CRYPT_CCMP=m
CONFIG_LIB80211_CRYPT_TKIP=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_HAS_RC=y
# CONFIG_MAC80211_RC_PID is not set
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_PM=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
#
# Device Drivers
#
Full .config file attached below.
I have tried converting RFKILL to a module, in order to enable CONFIG_RFKILL_INPUT to yes but the compile completely fails when this is set.
I have added WIRELESS_COMPAT details in the Kconfig file but this did not help and I am now lost as to how to troubleshoot this?
Anyone have any idea on what might be missing?
Click to expand...
Click to collapse
Are you installing the kernel and modules, or just the modules? If you are just installing the modules, are you using an IDENTICAL version of gcc, with nothing changed between N<=>M<=>Y except for your rt2x00 module in the .config?
useful information would be:
Your kernel version string from the phone: uname -a
A diff of the base .config and the new .config: diff -ubw orig.config new.config
A diff of the phone's working .config and your .config.
You can generally get the .config your running kernel was compiled with from /proc/config.gz on the device. You would then need to gunzip that and compare it to your .config with the diff command above.
s0be said:
Are you installing the kernel and modules, or just the modules? If you are just installing the modules, are you using an IDENTICAL version of gcc, with nothing changed between N<=>M<=>Y except for your rt2x00 module in the .config?
useful information would be:
Your kernel version string from the phone: uname -a
A diff of the base .config and the new .config: diff -ubw orig.config new.config
A diff of the phone's working .config and your .config.
You can generally get the .config your running kernel was compiled with from /proc/config.gz on the device. You would then need to gunzip that and compare it to your .config with the diff command above.
Click to expand...
Click to collapse
Unfortunately /proc/config.gz support is not configured in the samsung kernel by default therefore the file is not present. uname gives 2.6.35.7-I9100XXKH3-CL479037
And I have tried the recommended codesourcery cross compiler and one other variant of this and the results are the same.
it's a stock rom with an insecure kernel (basically a repack of the stock kernel) to allow rooting from what I can gather.
I have tried many configuration of build from the default .config and just building the top dependancy module from the default config
In this case the top of the tree is CFG80211
(rt2x00usb depends on rt2x00lib, depends upon mac80211, mac8211 depends upon cfg80211 and cfg80211 depends upon rfkill. There are also some dependencies on kernel crypto libraries which I am unclear about but should be in the kernel build)
I have found it makes no difference at all if I build lots of modules at once or just the very bare CFG80211.ko with as few options as possible. The failures are the same trying to insert cfg80211.ko. as it is whether I use busybox insmod, standard insmod or insmod from within a chroot. (in the searches I read modules can behave differently with busybox)
the only changes I made from the samsung default config is switching some debugging options off as per this thread http://forum.xda-developers.com/showthread.php?t=1123643
other than that it is a stock samsung default config for a 2.6.25.7 kernel build, as distributed in the samsung source code.
I haven't had the nerve to install the fully built kernel because the phone is a key tool for me reflashing a kernel is kind of a last resort
The attached rar file includes the default config (c1_rev02_premium_defconfig) the config used (.config) the output of diff -uwb between the two (differences.txt) and the two modules built ntfs.ko and cfg80211.ko.
file reveal ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped on both modules. (done chroot)
I use ntfs.ko as a control since it's a small module and in this build it inserts just fine. cfg80211.ko fails with the same message and dmesg info mentioned in the first post.
As I previously mentioned I did try modifying the RFKILL sections to be built as a module but when this is attempt the kernel build fails completely with the error:-
Code:
ERROR: "s3c_gpio_slp_cfgpin" [arch/arm/mach-s5pv310/c1-rfkill.ko] undefined!
ERROR: "s3c_gpio_slp_setpull_updown" [arch/arm/mach-s5pv310/c1-rfkill.ko] undefined!
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
Thanks for looking at this for me
Do you have a link to your kernel tree? I'd suspect that CFG80211_WEXT being enabled makes some changes in the WEXT functions that get compiled in kernel. With CONFIG_WEXT_* being =Y, your enableing CFG80211_WEXT probably made things not agree. Also, I believe the rt2x00 driver is a mac80211 one, so you'll likely need that too.
In summary, you'll very likely have to use your own kernel to get this going. At least loading the ntfs.ko answers that it's not a toolchain/source tree issue.
curioct said:
I use ntfs.ko as a control since it's a small module and in this build it inserts just fine. cfg80211.ko fails with the same message and dmesg info mentioned in the first post.
As I previously mentioned I did try modifying the RFKILL sections to be built as a module but when this is attempt the kernel build fails completely with the error:-
Code:
ERROR: "s3c_gpio_slp_cfgpin" [arch/arm/mach-s5pv310/c1-rfkill.ko] undefined!
ERROR: "s3c_gpio_slp_setpull_updown" [arch/arm/mach-s5pv310/c1-rfkill.ko] undefined!
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
Click to expand...
Click to collapse
This error is due to another missing dependency (and the lack of proper dependency definitions in KCONFIG). You need to do:
egrep "s3c_gpio_slp_" -rsn
to find where those functions are defined, and find out why they're not being compiled. It's quite likely something like enabling rfkill for your arch/tree pulled in that c1-rfkill file (is your board a c1?) which is either not for your actual device, or dependent on something else being enabled. This is wholly based on previous experience with HTC kernel trees, where files from other Boards seemed to tag along.
I have no samsung hardware (although the GSII is on the list of what I'm considering ;-) )
s0be said:
Do you have a link to your kernel tree? I'd suspect that CFG80211_WEXT being enabled makes some changes in the WEXT functions that get compiled in kernel. With CONFIG_WEXT_* being =Y, your enableing CFG80211_WEXT probably made things not agree. Also, I believe the rt2x00 driver is a mac80211 one, so you'll likely need that too.
In summary, you'll very likely have to use your own kernel to get this going. At least loading the ntfs.ko answers that it's not a toolchain/source tree issue.
Click to expand...
Click to collapse
I am aware I'll need other modules but they all come back to dependancy on CFG80211 so I am concentrating my efforts around that.
The link to the kernel tree is
git://opensource.samsung.com/p_497
but I have also used :-
https://github.com/GalaxySII/samsung-kernel-galaxysii
with the exact same results.
The config_wext elements are listed under the bluetooth elements, but I am firstly concerned that disabling these elements with adversely effect the standard wifi comms. which would not be acceptable even if I could package and install a fully kernel build. (which I can probably do enough research, on this site, to work out eventually, although I admit to some trepidation about this).
curioct said:
I am aware I'll need other modules but they all come back to dependancy on CFG80211 so I am concentrating my efforts around that.
The link to the kernel tree is
git://opensource.samsung.com/p_497
but I have also used :-
https://github.com/GalaxySII/samsung-kernel-galaxysii
with the exact same results.
The config_wext elements are listed under the bluetooth elements, but I am firstly concerned that disabling these elements with adversely effect the standard wifi comms. which would not be acceptable even if I could package and install a fully kernel build. (which I can probably do enough research, on this site, to work out eventually, although I admit to some trepidation about this).
Click to expand...
Click to collapse
Ok, per:
https://github.com/GalaxySII/samsun...gt-i9100-gingerbread/net/wireless/wext-core.c
Lines: 434, 548, and 613, 653
Your kernel will have to be replaced to have cfg80211, mac80211, and rt2x00 working. There is no way around this, as that code is compiled into the kernel, and cfg80211 and mac80211 depend on those function doing more than your kernel does. There's no way around it. That's only analyzing the wext-core... there may be other differences.
s0be said:
Ok, per:
https://github.com/GalaxySII/samsun...gt-i9100-gingerbread/net/wireless/wext-core.c
Lines: 434, 548, and 613, 653
Your kernel will have to be replaced to have cfg80211, mac80211, and rt2x00 working. There is no way around this, as that code is compiled into the kernel, and cfg80211 and mac80211 depend on those function doing more than your kernel does. There's no way around it. That's only analyzing the wext-core... there may be other differences.
Click to expand...
Click to collapse
thanks for a definitive answer
I guess I need to go away and learn about kernel packaging and the bootloader stuff cant afford to brick my phone regularly trying this stuff and must keep CWM alive
Thanks for your help
I am looking to compile a new kernel for this device. I have pulled off the boot.img file from /dev/block/nandc and used split_bootimg.pl to pull apart the kernel and the boot ramdisk. I have used extract-ikconfig to get the kernel config and built my new 3.4 kernel (with modules). So far so good...
I have tried to build the new boot.img file with no avail. My concern is with the original kernel as the new one should be build the same (I think). It looks like it is not compressed as I run the command
file boot.img-kernel
It returns
boot.img-kernel: data
So it is not a Linux kernel ARM boot executable zImage
Is this correct? Can Android boot with this or is the split_bootimg.pl tool not creating the file correctly (it does pull the ramdisk as I have uncompressed it fine! and the file does contain the kernel config)
Ok So assuming I can create a proper boot.img with my built zImage and the old ramdisk, what do I need to do with the modules? Do I update the boot.img on the tablet and copy the modules over to the existing /system/lib/modules? (this appears to not work)
I did not find an exact guide on android kernel and the modules....
Domenic
link to the old (working) boot.img hxxps://docs.google.com/file/d/0B0c1jpaziDZ-NU5Sd18wbUVjN1E/edit?usp=sharing
some progress
domenictroilo said:
I am looking to compile a new kernel for this device. I have pulled off the boot.img file from /dev/block/nandc and used split_bootimg.pl to pull apart the kernel and the boot ramdisk. I have used extract-ikconfig to get the kernel config and built my new 3.4 kernel (with modules). So far so good...
I have tried to build the new boot.img file with no avail. My concern is with the original kernel as the new one should be build the same (I think). It looks like it is not compressed as I run the command
file boot.img-kernel
It returns
boot.img-kernel: data
So it is not a Linux kernel ARM boot executable zImage
Is this correct? Can Android boot with this or is the split_bootimg.pl tool not creating the file correctly (it does pull the ramdisk as I have uncompressed it fine! and the file does contain the kernel config)
Ok So assuming I can create a proper boot.img with my built zImage and the old ramdisk, what do I need to do with the modules? Do I update the boot.img on the tablet and copy the modules over to the existing /system/lib/modules? (this appears to not work)
I did not find an exact guide on android kernel and the modules....
Domenic
link to the old (working) boot.img hxxps://docs.google.com/file/d/0B0c1jpaziDZ-NU5Sd18wbUVjN1E/edit?usp=sharing
Click to expand...
Click to collapse
Ok so the mkimage command can be used to pull the uImage out of the Kernel Part of the file like this:
mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Linux 3.0.8" -d uImage boot.img-kernel2
The only question is where in the boot process can I find the "Load Address" and "Entry Point" values that are required to create my uImage. I would think that these are going to be needed as options when I build my new kernel, and I will need to change the boot process or add a boot.scr file with my options. I have mounted the /dev/block/nanda partition (uBoot partition) but am not certain on where I would find the current environment values.
I did find this little snippet on the net that referes to the base address for this device xxx.tabletroms.com/forums/all-other-android-tablets-general-discussion/5791-full-specs-whatever-else-polaroid-pmid10c-tablet-2.htmlx
mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' --board sun4i --base 0x40000000 -o boot.img
But he never discusses where he found the -base address. Is this the same as the Load Address and Entry Point?
Domenic
domenictroilo said:
Ok so the mkimage command can be used to pull the uImage out of the Kernel Part of the file like this:
mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Linux 3.0.8" -d uImage boot.img-kernel2
The only question is where in the boot process can I find the "Load Address" and "Entry Point" values that are required to create my uImage. I would think that these are going to be needed as options when I build my new kernel, and I will need to change the boot process or add a boot.scr file with my options. I have mounted the /dev/block/nanda partition (uBoot partition) but am not certain on where I would find the current environment values.
I did find this little snippet on the net that referes to the base address for this device xxx.tabletroms.com/forums/all-other-android-tablets-general-discussion/5791-full-specs-whatever-else-polaroid-pmid10c-tablet-2.htmlx
mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' --board sun4i --base 0x40000000 -o boot.img
But he never discusses where he found the -base address. Is this the same as the Load Address and Entry Point?
Domenic
Click to expand...
Click to collapse
So the base address is found in script.bin (converted to text file with bin2fex tool). This is the information found in it:
[dram_para]
dram_baseaddr = 0x40000000
Still how do I find the "Load Address" and "Entry Point" for the current kernel...
unmkbootimg
domenictroilo said:
So the base address is found in script.bin (converted to text file with bin2fex tool). This is the information found in it:
[dram_para]
dram_baseaddr = 0x40000000
Still how do I find the "Load Address" and "Entry Point" for the current kernel...
Click to expand...
Click to collapse
Well more reading leads me to use unmkbootimg but on my linux 32bit system all I get is:
# strace ./unmkbootimg
execve("./unmkbootimg", ["./unmkbootimg"], [/* 20 vars */]) = 0
--- SIGILL (Illegal instruction) @ 0 (0) ---
+++ killed by SIGILL +++
Illegal instruction
Too bad I can see the souce code to find out what this program is doing or compile it for myself.....
split_bootimg.pl should give you the parameters i listed on tabletroms.
What source are you using? Polaroid never coughed any up and i last harassed them in February.
bigsupersquid said:
split_bootimg.pl should give you the parameters i listed on tabletroms.
What source are you using? Polaroid never coughed any up and i last harassed them in February.
Click to expand...
Click to collapse
Here is the split:
letourneau:~/tmp# ../split_bootimg.pl /root/boot.img
Page size: 2048 (0x00000800)
Kernel size: 8112836 (0x007bcac4)
Ramdisk size: 210343 (0x000335a7)
Second size: 0 (0x00000000)
Board name:
Command line: console=ttyS0,115200 rw init=/init loglevel=8
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
I am using the linux--sunxi kernel for now with an additional patch for dmard06.ko (which I do not expect to work!) I emailed them for the kernel source but just received a form email saying they will get back to me..... oh well I will as again.
Just playing around for now to see if a newer kernel will tweek up the speed on this device as it is very laggy.
Domenic
I may be using an older version of split_bootimg.pl?
On another note, I was able to execute unmkbootimg on a different linux server. I was attempting to run it on a PIII 800 so it needs something > a pentium (I guess).
./unmkbootimg boot.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 8112836
Kernel address 0x40008000
Ramdisk size 210343
Ramdisk address 0x41000000
Secondary size 0
Secondary address 0x40f00000
Kernel tags address 0x40000100
Flash page size 2048
Board name is ""
Command line "console=ttyS0,115200 rw init=/init loglevel=8"
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x40000000 --cmdline 'console=ttyS0,115200 rw init=/init loglevel=8' -o new_boot.img
---------------
Domenic
think the parameters you're searching for are specific for building the new kernel without proper source code to extract them from?
maybe you could get them from dmesg while the tablet is running?
else think there might be a way to grep the variable names in the existing kernel binary or headers?
i also would like a fresh kernel.
maybe useful stuff here:
https://vilimpoc.org/research/sh3dev/kernel-hacking.html
http://forum.xda-developers.com/showpost.php?p=46668556&postcount=31
thanks jjchico
i haven't checked this out yet, but may be useful.
Well I have build a new kernel and copied the modules over, but I does not boot. It appears that it never mounts the ramdisk as it never gets to the second splash screen, but I am flying blind as there is no serial port to debug with. I suspect that I do not quite understand the boot process for this tablet.... here is what is on the nanda vfat partition: (good information here http://rhombus-tech.net/allwinner_a10/a10_boot_process/)
since this is in my linux.ini
cat linux.ini
[segment]
img_name = c:\linux\u-boot.bin
img_size = 0x80000
img_base = 0x4A000000
[script_info]
script_base = 0x43000000
script_size = 0x10000
[logo_info]
logo_name = c:\linux\linux.bmp
logo_show = 1
Not quite certain how to setup img_base on my compile I guess.
I have tried the linix.ini from the link above but the tablet booted to livesuite image... that is a fail.
Not being a kernel developer.... I am wondering if the option to setup SUNXI_NAND_COMPAT_DEV is creating /dev/block/nandX or /dev/nandX as this will definatly impact the init.sun4i.rc file as it is mounting /dev/block/nandX This could be my first issue.... but then does /init first display the initlogo.rle or start processing init.sun4i.rc. Well if the first thing it does in load initlogo.rle then I am not even getting this far....below is the description of SUNXI_NAND_COMPAT_DEV
Symbol: SUNXI_NAND_COMPAT_DEV [=y] │
│ Type : boolean │
│ Prompt: Create old nand device names (nanda-nandz) │
│ Defined at drivers/block/Kconfig:564 │
│ Depends on: BLK_DEV [=y] && SUNXI_NAND [=y] │
│ Location: │
│ -> Device Drivers │
│ -> Block devices (BLK_DEV [=y]) │
│ -> SUNXI Nandflash Driver (SUNXI_NAND [=y]) │
well a little more reading leads me to this page on the CarbonRom http://www.slatedroid.com/topic/64378-rom-carbonrom-422/ turns out that if you want to run a 3.4 kernel you MUST update u-boot (http://www.mediafire...4ro667xcfkd2dv7).... so I have flashed the CarbonRom and it does boot with the u-boot update. Not to worry the new u-boot will still boot the old kernel. The only issue I have with the CarbonRom kernel is the missing dmard06 driver so no touch screen..... I may get a new kernel working yet!
domenictroilo said:
well a little more reading leads me to this page on the CarbonRom http://www.slatedroid.com/topic/64378-rom-carbonrom-422/ turns out that if you want to run a 3.4 kernel you MUST update u-boot (http://www.mediafire...4ro667xcfkd2dv7).... so I have flashed the CarbonRom and it does boot with the u-boot update. Not to worry the new u-boot will still boot the old kernel. The only issue I have with the CarbonRom kernel is the missing dmard06 driver so no touch screen..... I may get a new kernel working yet!
Click to expand...
Click to collapse
https://github.com/fsebentley/linux_allwinner_drivers_input_touchscreen_mods
https://groups.google.com/forum/#!topic/linux-sunxi/D0n8dyaVA34
?
bigsupersquid said:
https://github.com/fsebentley/linux_allwinner_drivers_input_touchscreen_mods
https://groups.google.com/forum/#!topic/linux-sunxi/D0n8dyaVA34
?
Click to expand...
Click to collapse
the patch compiles,you need to comment out #include <linux/earlysuspend.h> as it is not supported on the newer kernel and not required by the driver anyway. I just need to get the kernel to actually load lol..... I have at least gotten past the boot screen now, but it hangs.... I will try a different arm tool chain and see what happens next.....
So close but yet so far..... well I have the new kernel installed and booted with adb shell available but it turns out the new mma7660.ko is not compatable with my device I get this error from dmesg over and over and over....
<4>[ 3254.934675] incomplete xfer (0x20)
<3>[ 3254.938093] Assertion failed! drivers/hwmon/mma7660.c,196,mma7660_read_xyz,result>=0
Will rename the driver and see if I can get past init further in the boot....
Edit
Well more issues with drivers the dmard06 is not compatible either, I had more success with the Carbon Kernel I will see if I can find the source git, should be around....
dmesg | busybox grep dmard
<4>[ 5.408528] dmard06: init
<3>[ 5.447835] dmard06gsensor_fetch_sysconfig_para: after: gsensor_twi_addr is 0x4c, dirty_addr_buf: 0x4c. dirty_addr_buf[1]: 0xfffe
<4>[ 5.488546] dmard06_init: after fetch_sysconfig_para: normal_i2c: 0x4c. normal_i2c[1]: 0xfffe
<6>[ 5.508612] gsensor_detect: Detected chip dmard06 at adapter 1, address 0x4c
<4>[ 5.601533] dmard06 gsensor I2C err = 0!
<4>[ 5.613430] dmard06 probe failed
<4>[ 5.624926] dmard06: probe of 1-004c failed with error -1
This all makes some sense as Polaroid has not get gotten me the kernel and the drivers they load (their kernel have very unique names:
Module Size Used by Not tainted
8192cu 575431 0
rtl8150 8910 0
mcs7830 6557 0
qf9700 8513 0
asix 22500 0
usbnet 23745 3 mcs7830,qf9700,asix
dmard06_gl 8202 2
mma7660 6541 0
mali 130177 14
ump 42178 19 mali
gt811_ts_828 19947 0
sun4i_csi0 27946 0
nt99250 14254 1
gc0308 12848 1
videobuf_dma_contig 5659 1 sun4i_csi0
videobuf_core 18067 2 sun4i_csi0,videobuf_dma_contig
Well more issues with drivers the dmard06 is not compatible either, I had more success with the Carbon Kernel I will see if I can find the kernel source git, should be around....
dmesg | busybox grep dmard
<4>[ 5.408528] dmard06: init
<3>[ 5.447835] dmard06gsensor_fetch_sysconfig_para: after: gsensor_twi_addr is 0x4c, dirty_addr_buf: 0x4c. dirty_addr_buf[1]: 0xfffe
<4>[ 5.488546] dmard06_init: after fetch_sysconfig_para: normal_i2c: 0x4c. normal_i2c[1]: 0xfffe
<6>[ 5.508612] gsensor_detect: Detected chip dmard06 at adapter 1, address 0x4c
<4>[ 5.601533] dmard06 gsensor I2C err = 0!
<4>[ 5.613430] dmard06 probe failed
<4>[ 5.624926] dmard06: probe of 1-004c failed with error -1
This all makes some sense as Polaroid has not provided me the kernel they used and the drivers they load have unique names see below from the original stock rom:
Module Size Used by Not tainted
8192cu 575431 0
rtl8150 8910 0
mcs7830 6557 0
qf9700 8513 0
asix 22500 0
usbnet 23745 3 mcs7830,qf9700,asix
dmard06_gl 8202 2
mma7660 6541 0
mali 130177 14
ump 42178 19 mali
gt811_ts_828 19947 0
sun4i_csi0 27946 0
nt99250 14254 1
gc0308 12848 1
videobuf_dma_contig 5659 1 sun4i_csi0
videobuf_core 18067 2 sun4i_csi0,videobuf_dma_contig
I suspect after all the trouble I had with LG source that there are device-specific bits in the drivers.
Polaroid will most likely have to cough up source to get it all working.
Have you considered trying punchmod to use the old drivers? I dunno if that'd work considering the stock kernel is a lower version... but it might be worth a try.
bigsupersquid said:
I suspect after all the trouble I had with LG source that there are device-specific bits in the drivers.
Polaroid will most likely have to cough up source to get it all working.
Have you considered trying punchmod to use the old drivers? I dunno if that'd work considering the stock kernel is a lower version... but it might be worth a try.
Click to expand...
Click to collapse
I have changed the vermagic on the old modules and tried with the newer kernel but no go.... the latest 3.0 sunxi kernel is at 3.0.96 so I will build this one and see if I can get the special 3.0.8 polaroid modules to load.
I have a ticket open with Polaroid lol I guess we will see if the cough up a kernel or not.... I would not put money on it...
domenictroilo said:
I have changed the vermagic on the old modules and tried with the newer kernel but no go.... the latest 3.0 sunxi kernel is at 3.0.96 so I will build this one and see if I can get the special 3.0.8 polaroid modules to load.
I have a ticket open with Polaroid lol I guess we will see if the cough up a kernel or not.... I would not put money on it...
Click to expand...
Click to collapse
I've had an open ticket since November from talking on the phone after email did nothing.
nothing but autoresponder.
bigsupersquid said:
I've had an open ticket since November from talking on the phone after email did nothing.
nothing but autoresponder.
Click to expand...
Click to collapse
Do you believe that something like this http://gpl-violations.org/faq/violation-faq.html could force them to provide the source code? I could try to get the group at "FreakTab" to make the same requests for the kernel sources. Maybe with enough requests the gpl-violations group could take it on?
(K I am getting off topic here sorry anyone out there......)
I have attempted to build the 3.0.96 kernel but it did not boot.... back to hacking at the .config to see what I have missed (I need to move my build environment off this old p3 800 lol)
I have started this thread as a place to discuss random development thought that probably don't need their own threads, and as a place to discuss issues so other threads don't go too far off topic.
Table of Contents:
DBV for c6843: Posts 1 - 6
GPL: Post 7
F2FS: Post 8
wlan: post 9, 11 -
Optimisation Bookmark: post 10
Original Post 1:
First thought
@dbolivar Have you tried building you (DooMKernel) with CONFIG_DVB_CORE = y/m to see if you can get the TV function to work?
blueether said:
I have started this thread as a place to discuss random development thought that probably don't need their own threads, and as a place to discuss issues so other threads don't go too far off topic.
First thought
@dbolivar Have you tried building you (DooMKernel) with CONFIG_DVB_CORE = y/m to see if you can get the TV function to work?
Click to expand...
Click to collapse
Hi, good start. In fact I have, the differences in the kernel options between C6833 and C6843 (Brazilian model with digital TV) are:
Code:
47c47
< CONFIG_MACH_SONY_TOGARI_BRAZIL=y
---
> CONFIG_MACH_SONY_TOGARI_ROW=y
275d274
< CONFIG_ISDBT_TUNER_SMTEJ11X=y
325a325,327
> CONFIG_TOUCHSCREEN_CLEARPAD=y
> CONFIG_TOUCHSCREEN_CLEARPAD_I2C=y
> CONFIG_TOUCHSCREEN_CLEARPAD_RMI_DEV=y
Yes, I don't know why the Clearpad touchscreen is enabled for the C6833, but not for the C6843; I think it's just garbage (perhaps they made the togari defconfig based off honami, and corrected that when making the togari_brazil defconfig). It doesn't make any difference for me, disabling them keep the touchscreen (MAX1187) functions normal.
Well, back to the point: even when applying these differences to the ZU DooMKernel, the digital TV doesn't work. The app stays a long time in a black screen, and finally closes (FC). I investigated the kmsg and logcat, but nothing useful.
CONFIG_DVB_CORE is "m" by default. I tried insmod'ing every module in /system/lib/modules, but same result. I temporarily gave up, because I don't watch the crap they broadcast on the open TV here. But yeah, it would be good to have everything working...
dbolivar said:
Hi, good start. In fact I have, the differences in the kernel options between C6833 and C6843 (Brazilian model with digital TV) are:
Code:
47c47
< CONFIG_MACH_SONY_TOGARI_BRAZIL=y
---
> CONFIG_MACH_SONY_TOGARI_ROW=y
275d274
< CONFIG_ISDBT_TUNER_SMTEJ11X=y
325a325,327
> CONFIG_TOUCHSCREEN_CLEARPAD=y
> CONFIG_TOUCHSCREEN_CLEARPAD_I2C=y
> CONFIG_TOUCHSCREEN_CLEARPAD_RMI_DEV=y
Yes, I don't know why the Clearpad touchscreen is enabled for the C6833, but not for the C6843; I think it's just garbage (perhaps they made the togari defconfig based off honami, and corrected that when making the togari_brazil defconfig). It doesn't make any difference for me, disabling them keep the touchscreen (MAX1187) functions normal.
Well, back to the point: even when applying these differences to the ZU DooMKernel, the digital TV doesn't work. The app stays a long time in a black screen, and finally closes (FC). I investigated the kmsg and logcat, but nothing useful.
CONFIG_DVB_CORE is "m" by default. I tried insmod'ing every module in /system/lib/modules, but same result. I temporarily gave up, because I don't watch the crap they broadcast on the open TV here. But yeah, it would be good to have everything working...
Click to expand...
Click to collapse
I hadn't got around to diff'ing them I just noticed the DVB line and had a quick look at the brazil defconfig.
I guess there is a binary blob that is needed?
For some reason I have to include the clearpad stuff at the moment in the pimped kernel, I should dig to find out why so the kernel is a tad smaller.
blueether said:
I hadn't got around to diff'ing them I just noticed the DVB line and had a quick look at the brazil defconfig.
I guess there is a binary blob that is needed?
For some reason I have to include the clearpad stuff at the moment in the pimped kernel, I should dig to find out why so the kernel is a tad smaller.
Click to expand...
Click to collapse
Hmm very good insight about the binary blob... It's very possible. I have FTFs for the C6833 and C6843, I'll extract them and compare the file list.
I made it work!! Well, involves some manual steps, but it's a very good progress. I started by comparing the file listing in /system from stock C6833 and C6843 firmwares, and although there is no kernel blob, there ARE some files related to DTV, mostly dynamic libs (.so), some configuration, but most importantly, these two:
Code:
/system/bin/dtvsdserver
/system/bin/dtvserver
So, I insmod'ed every module related to DTV/DVB, and then started these guys... And the TV works! BUT, as soon as I quit the Mobile TV app, the process "dtvserver" is killed with a hangup signal, and opening the app again does not restart it, so I have to manually bring the dtvserver up first (otherwise the same previous issue happens, black screen and finally Mobile TV FC's).
I notice some DTV/DVB modules couldn't be insmod'ed:
Code:
insmod: init_module 'dib3000mc.ko' failed (No such file or directory)
insmod: init_module 'dib7000m.ko' failed (No such file or directory)
insmod: init_module 'dib7000p.ko' failed (No such file or directory)
insmod: init_module 'dib8000.ko' failed (No such file or directory)
insmod: init_module 'dib9000.ko' failed (No such file or directory)
insmod: init_module 'mpq-dmx-hw-plugin.ko' failed (No such file or directory)
insmod: init_module 'tuner-simple.ko' failed (No such file or directory)
But the modules are there, and they are the new ones... I don't get it why they can't be insmod'ed, perhaps something is missing from the kernel config? It could be one of the reasons.
Another thing I've been wondering, is why the DVB modules necessary for the Mobile TV are not loaded automatically, like the wlan module is, for instance. Perhaps a difference in the ramdisk? Something to investigate next.
dbolivar said:
I made it work!! Well, involves some manual steps...
Another thing I've been wondering, is why the DVB modules necessary for the Mobile TV are not loaded automatically, like the wlan module is, for instance. Perhaps a difference in the ramdisk? Something to investigate next.
Click to expand...
Click to collapse
Congrats on getting that far with the DTV, will make for a more complete device for the c6843 users that want to use custom ROMs
Any differences in udev or init.rc or whatever android uses?
Development using the GPL and GPL'd code
The GPL is a very powerful tool, as are the other OSS licences. One has to know how they are used and can/can't be enforced before publishing any code under these licences or modifying code that that been published under a OSS licence. Using a OSS licence brings with it risks and rewords, often these are one and the same.
When we do anything with Android [Linux] kernels we fall under the bounds of the GPL v2 that it is published under. Any modification to the kernel has to be published under the same licence, and we have to publish the newly modified source in a sate that can recreate the binary that you publish to the public/xda.
I'll leave you with this quote from http://programmers.stackexchange.com
...are you prepared to live by it, and let other people use what you've written, rather than just liking it because of what you can get out of it?
Click to expand...
Click to collapse
F2FS mount and sysfs options
Now that we have an F2FS-enabled firmware by default, I've been reading about the mount options and sysfs entries available. As many of us know, there are lots of tweaks out there for EXT4, but what about F2FS? Well, here is the official documentation from the Linux kernel:
https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
As for the mount options, I think only discard could be interesting (but it's questionable, some people say it's better to schedule a regular fstrim call instead). There are also some sysfs tunables which I think can have a noticeable impact in battery life, and performance. Testing them would require a lot of trial and error. I'm pasting them below for those who don't want to go through the full document:
Code:
================================================================================
SYSFS ENTRIES
================================================================================
Information about mounted f2f2 file systems can be found in
/sys/fs/f2fs. Each mounted filesystem will have a directory in
/sys/fs/f2fs based on its device name (i.e., /sys/fs/f2fs/sda).
The files in each per-device directory are shown in table below.
Files in /sys/fs/f2fs/<devname>
(see also Documentation/ABI/testing/sysfs-fs-f2fs)
..............................................................................
File Content
gc_max_sleep_time This tuning parameter controls the maximum sleep
time for the garbage collection thread. Time is
in milliseconds.
gc_min_sleep_time This tuning parameter controls the minimum sleep
time for the garbage collection thread. Time is
in milliseconds.
gc_no_gc_sleep_time This tuning parameter controls the default sleep
time for the garbage collection thread. Time is
in milliseconds.
gc_idle This parameter controls the selection of victim
policy for garbage collection. Setting gc_idle = 0
(default) will disable this option. Setting
gc_idle = 1 will select the Cost Benefit approach
& setting gc_idle = 2 will select the greedy aproach.
reclaim_segments This parameter controls the number of prefree
segments to be reclaimed. If the number of prefree
segments is larger than the number of segments
in the proportion to the percentage over total
volume size, f2fs tries to conduct checkpoint to
reclaim the prefree segments to free segments.
By default, 5% over total # of segments.
max_small_discards This parameter controls the number of discard
commands that consist small blocks less than 2MB.
The candidates to be discarded are cached until
checkpoint is triggered, and issued during the
checkpoint. By default, it is disabled with 0.
ipu_policy This parameter controls the policy of in-place
updates in f2fs. There are five policies:
0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
2: F2FS_IPU_UTIL, 3: F2FS_IPU_SSR_UTIL,
4: F2FS_IPU_DISABLE.
min_ipu_util This parameter controls the threshold to trigger
in-place-updates. The number indicates percentage
of the filesystem utilization, and used by
F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies.
max_victim_search This parameter controls the number of trials to
find a victim segment when conducting SSR and
cleaning operations. The default value is 4096
which covers 8GB block address range.
dir_level This parameter controls the directory level to
support large directory. If a directory has a
number of files, it can reduce the file lookup
latency by increasing this dir_level value.
Otherwise, it needs to decrease this value to
reduce the space overhead. The default value is 0.
ram_thresh This parameter controls the memory footprint used
by free nids and cached nat entries. By default,
10 is set, which indicates 10 MB / 1 GB RAM.
@blueether & @dbolivar :
our primary concern should be to get custom wlan (prima/pronto) drivers working on custom compiled kernel for stock ROMs.. once we have that there are a LOT of features which we can add!
so far I havent had much luck but you can find all my tests here
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan_clean
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_z1_gpe_port_wlan
A bookmark
Worth the read @dbolivar
http://forum.xda-developers.com/showthread.php?t=2754997
DooMLoRD said:
@blueether & @dbolivar :
our primary concern should be to get custom wlan (prima/pronto) drivers working on custom compiled kernel for stock ROMs.. once we have that there are a LOT of features which we can add!
so far I havent had much luck but you can find all my tests here
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_stock_4.3_wlan_clean
https://github.com/DooMLoRD/android_kernel_sony_msm8974/commits/testing_z1_gpe_port_wlan
Click to expand...
Click to collapse
I'm giving it a try - downloaded the latest sources from CodeAurora and applied to your kernel (adjusting Kconfigs, Makefiles and defconfig). The compilation stops here:
Code:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c: In function ‘wlan_hdd_send_avoid_freq_event’:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c:574:18: warning: assignment makes pointer from integer without a cast
error, forbidden warning: wlan_hdd_cfg80211.c:574
make[3]: *** [drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.o] Error 1
OK, so I edited wlan_hdd_cfg80211.c and changed line 574 to add an explicit cast:
Code:
vendor_event = (struct sk_buff *)cfg80211_vendor_event_alloc(pHddCtx->wiphy,
Then it passes by this point, but stops in following lines with similar errors (not even pasting here). What I noticed from these errors it that CodeAurora's sources seem to be incompatible with Sony's kernel, because for instance, the function cfg80211_vendor_event_alloc is not defined anywhere (ran a grep over all *.c and *.h files in the kernel).
Comparing with a CM11 kernel, this function is also not defined anywhere, but the prima sources are very different, they don't call it. So I thought: let's use CM11's prima sources.
Bingo!
Compiled fine, booted, and with the correspoding firmware in /system/etc/firmware/wlan/prima, WLAN came up normally after boot. :victory:
Now you mentioned something about CM11's prima sources, from what I understood they are not ideal. Is that true? Because there are CM11-based custom kernels which implement intelliplug (dependent on custom WLAN drivers), for instance.
Hope it works for you. In this case, I'll put together a more organized how-to of what I did.
dbolivar said:
I'm giving it a try - downloaded the latest sources from CodeAurora and applied to your kernel (adjusting Kconfigs, Makefiles and defconfig). The compilation stops here:
Code:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c: In function ‘wlan_hdd_send_avoid_freq_event’:
drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.c:574:18: warning: assignment makes pointer from integer without a cast
error, forbidden warning: wlan_hdd_cfg80211.c:574
make[3]: *** [drivers/staging/prima/CORE/HDD/src/wlan_hdd_cfg80211.o] Error 1
OK, so I edited wlan_hdd_cfg80211.c and changed line 574 to add an explicit cast:
Code:
vendor_event = (struct sk_buff *)cfg80211_vendor_event_alloc(pHddCtx->wiphy,
Then it passes by this point, but stops in following lines with similar errors (not even pasting here). What I noticed from these errors it that CodeAurora's sources seem to be incompatible with Sony's kernel, because for instance, the function cfg80211_vendor_event_alloc is not defined anywhere (ran a grep over all *.c and *.h files in the kernel).
Comparing with a CM11 kernel, this function is also not defined anywhere, but the prima sources are very different, they don't call it. So I thought: let's use CM11's prima sources.
Bingo!
Compiled fine, booted, and with the correspoding firmware in /system/etc/firmware/wlan/prima, WLAN came up normally after boot. :victory:
Now you mentioned something about CM11's prima sources, from what I understood they are not ideal. Is that true? Because there are CM11-based custom kernels which implement intelliplug (dependent on custom WLAN drivers), for instance.
Hope it works for you. In this case, I'll put together a more organized how-to of what I did.
Click to expand...
Click to collapse
great!
can you just fork my repo and shift to the branch which worked for you, then send pull request? i will investigate on the Z1...
and yes please do send the steps!
well if we get custom compiled WLAN modules properly working on custom compiled kernel for stock ROM then i can have features like intelli-plug, F2FS, AsyncFS and lots more on stock ROMs!
DooMLoRD said:
great!
can you just fork my repo and shift to the branch which worked for you, then send pull request? i will investigate on the Z1...
and yes please do send the steps!
well if we get custom compiled WLAN modules properly working on custom compiled kernel for stock ROM then i can have features like intelli-plug, F2FS, AsyncFS and lots more on stock ROMs!
Click to expand...
Click to collapse
Well I'm still learning my way around git & GitHub, so I think it will be faster if you just reproduce the steps below:
1) Copy Prima WLAN sources from CM11-based kernel:
I copied from SlimRom's kernel source. Put the sources under drivers/staging/prima.
2) Modify related Kconfig and Makefile:
drivers/staging/Kconfig
Code:
131,132d130
< source "drivers/staging/prima/Kconfig"
<
drivers/staging/Makefile
Code:
58,59d57
< obj-$(CONFIG_PRIMA_WLAN) += prima/
< obj-$(CONFIG_PRONTO_WLAN) += prima/
3) Modify defconfig:
I'm pasting every option related to WLAN. The Prima options should appear after a "make menuconfig".
Code:
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=y
CONFIG_NL80211_TESTMODE=y
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_CFG80211_INTERNAL_REGDB=y
# CONFIG_CFG80211_WEXT is not set
# CONFIG_WIRELESS_EXT_SYSFS is not set
# CONFIG_LIB80211 is not set
# CONFIG_CFG80211_ALLOW_RECONNECT is not set
# CONFIG_MAC80211 is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_PM=y
CONFIG_RFKILL_LEDS=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_RFKILL_GPIO is not set
...
# CONFIG_WIFI_CONTROL_FUNC is not set
...
CONFIG_WLAN=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_LIBRA_SDIOIF is not set
# CONFIG_ATH6K_LEGACY_EXT is not set
CONFIG_WCNSS_CORE=y
CONFIG_WCNSS_CORE_PRONTO=y
CONFIG_WCNSS_MEM_PRE_ALLOC=y
CONFIG_WCNSS_REGISTER_DUMP_ON_BITE=y
# CONFIG_ATH_COMMON is not set
# CONFIG_BCMDHD is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_IWM is not set
# CONFIG_LIBERTAS is not set
# CONFIG_MWIFIEX is not set
...
#
# Qualcomm Atheros Prima WLAN module
#
CONFIG_PRIMA_WLAN=m
CONFIG_PRONTO_WLAN=y
# CONFIG_PRIMA_WLAN_BTAMP is not set
CONFIG_PRIMA_WLAN_LFR=y
CONFIG_PRIMA_WLAN_OKC=y
CONFIG_PRIMA_WLAN_11AC_HIGH_TP=y
CONFIG_WLAN_FEATURE_11W=y
CONFIG_QCOM_VOWIFI_11R=y
CONFIG_CONFIG_ENABLE_LINUX_REG=y
4) Include Prima WLAN firmware in kernel ZIP file:
Copy from a CM11-based firmware (I used PAC-Rom). Remember to set permissions as 644.
/system/etc/firmware/wlan/prima
Code:
WCNSS_cfg.dat
WCNSS_qcom_cfg.ini
WCNSS_qcom_wlan_nv.bin
5) Include wlan.ko in kernel ZIP file:
Actually I include every compiled kernel module, because we are using a different toolchain and they may benefit from it too. Remember that /system/lib/module/wlan.ko is a symlink, but in my test the target got updated accordingly.
dbolivar said:
Well I'm still learning my way around git & GitHub, so I think it will be faster if you just reproduce the steps below:
1) Copy Prima WLAN sources from CM11-based kernel:
I copied from SlimRom's kernel source. Put the sources under drivers/staging/prima.
2) Modify related Kconfig and Makefile:
drivers/staging/Kconfig
Code:
131,132d130
< source "drivers/staging/prima/Kconfig"
<
drivers/staging/Makefile
Code:
58,59d57
< obj-$(CONFIG_PRIMA_WLAN) += prima/
< obj-$(CONFIG_PRONTO_WLAN) += prima/
3) Modify defconfig:
I'm pasting every option related to WLAN. The Prima options should appear after a "make menuconfig".
Code:
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211=y
CONFIG_NL80211_TESTMODE=y
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
CONFIG_CFG80211_INTERNAL_REGDB=y
# CONFIG_CFG80211_WEXT is not set
# CONFIG_WIRELESS_EXT_SYSFS is not set
# CONFIG_LIB80211 is not set
# CONFIG_CFG80211_ALLOW_RECONNECT is not set
# CONFIG_MAC80211 is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_PM=y
CONFIG_RFKILL_LEDS=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_RFKILL_GPIO is not set
...
# CONFIG_WIFI_CONTROL_FUNC is not set
...
CONFIG_WLAN=y
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_LIBRA_SDIOIF is not set
# CONFIG_ATH6K_LEGACY_EXT is not set
CONFIG_WCNSS_CORE=y
CONFIG_WCNSS_CORE_PRONTO=y
CONFIG_WCNSS_MEM_PRE_ALLOC=y
CONFIG_WCNSS_REGISTER_DUMP_ON_BITE=y
# CONFIG_ATH_COMMON is not set
# CONFIG_BCMDHD is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_IWM is not set
# CONFIG_LIBERTAS is not set
# CONFIG_MWIFIEX is not set
...
#
# Qualcomm Atheros Prima WLAN module
#
CONFIG_PRIMA_WLAN=m
CONFIG_PRONTO_WLAN=y
# CONFIG_PRIMA_WLAN_BTAMP is not set
CONFIG_PRIMA_WLAN_LFR=y
CONFIG_PRIMA_WLAN_OKC=y
CONFIG_PRIMA_WLAN_11AC_HIGH_TP=y
CONFIG_WLAN_FEATURE_11W=y
CONFIG_QCOM_VOWIFI_11R=y
CONFIG_CONFIG_ENABLE_LINUX_REG=y
4) Include Prima WLAN firmware in kernel ZIP file:
Copy from a CM11-based firmware (I used PAC-Rom). Remember to set permissions as 644.
/system/etc/firmware/wlan/prima
Code:
WCNSS_cfg.dat
WCNSS_qcom_cfg.ini
WCNSS_qcom_wlan_nv.bin
5) Include wlan.ko in kernel ZIP file:
Actually I include every compiled kernel module, because we are using a different toolchain and they may benefit from it too. Remember that /system/lib/module/wlan.ko is a symlink, but in my test the target got updated accordingly.
Click to expand...
Click to collapse
which branch did u test this with?
also can you please upload the correct firmware (/system/etc/firmware/wlan/prima) which worked for you?
DooMLoRD said:
which branch did u test this with?
also can you please upload the correct firmware (/system/etc/firmware/wlan/prima) which worked for you?
Click to expand...
Click to collapse
The branch from your kernel was master_kk-4.4.2. The Prima WLAN sources were, as I mentioned, from SlimRom's kernel, branch kk4.4.
I'm attaching the firmware to this post.
blueether said:
A bookmark
Worth the read @dbolivar
http://forum.xda-developers.com/showthread.php?t=2754997
Click to expand...
Click to collapse
Wow this is very nice! Follows the same line of research I've been doing, but this is more "elegant" and in-depth, especially because of all the benchmarks and other comparisons he has done. I'll try this approach myself on my custom builds.
One thing I noticed is that we may still have to use the "hammer" approach with the find & replace of the "-O" flags in *.mk and Makefiles I've been doing, because some of them have these flags hardcoded (i.e. they don't take the value from core/combo/TARGET_linux-arm.mk or other base files). I'll tip JustArchi in his thread about it.
Hi guys, I posted this in the general android section and have had no answer, maybe some one here might know?
I'm trying to build AOSP using CM 11's device tree for togari/togari_gpe and have hit a brick wall after solving the first few make errors.
I have to errors, that I suspect are the same problem:
The first is if I just build with make I get this error:
Code:
Import includes file: out/target/product/togari/obj/SHARED_LIBRARIES/copybit.msm8974_intermediates/import_includes
Import includes file: out/target/product/togari/obj/SHARED_LIBRARIES/libmemalloc_intermediates/import_includes
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/profiler.cpp
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/mdp_version.cpp
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/idle_invalidator.cpp
target thumb C++: libqdutils <= hardware/qcom/display/msm8974/libqdutils/comptype.cpp
hardware/qcom/display/msm8974/libqdutils/mdp_version.cpp:33:27: fatal error: linux/msm_mdp.h: No such file or directory
#include <linux/msm_mdp.h>
^
Import includes file: out/target/product/togari/obj/SHARED_LIBRARIES/gps.msm8974_intermediates/import_includes
compilation terminated.
make: *** [out/target/product/togari/obj/SHARED_LIBRARIES/libqdutils_intermediates/mdp_version.o] Error 1
make: *** Waiting for unfinished jobs....
and if I do make bootimage I get this:
Code:
make: *** No rule to make target `out/target/product/togari/kernel', needed by `out/target/product/togari/boot.img'. Stop.
I suspect that both stem from aosp not finding the kernel source?
kernel source is at ~/dev/aosp/kernel/sony/msm8974/ and I'm building in ~/dev/aosp
I'm also trying to build vanir aosp using the same device tree and kernel and make bootimage completes fine.
Any help would be great
Yo, @DooMLoRD, @blueether @dbolivar
You guys have probably registred that Geohot (iPhone, PS3 jailbreaker) has successfully rooted the Galaxy S5 (and can now claim the $18,000 bounty), but i just read that this one-click root tool should work on any device running a pre-June 3rd kernel, i.e Android 4.4.2. The question is, does it work on the Ultra? I'm aware that it's easy to root an UItra AS LONG as the bootloader is unlocked, but this thing circumvents that part, and roots it. I think.
Are there anyone here still left on 4.4.2 that can try?
More here: Click
LordManhattan said:
Yo, @DooMLoRD, @blueether @dbolivar
You guys have probably registred that Geohot (iPhone, PS3 jailbreaker) has successfully rooted the Galaxy S5 (and can now claim the $18,000 bounty), but i just read that this one-click root tool should work on any device running a pre-June 3rd kernel, i.e Android 4.4.2. The question is, does it work on the Ultra? I'm aware that it's easy to root an UItra AS LONG as the bootloader is unlocked, but this thing circumvents that part, and roots it. I think.
Are there anyone here still left on 4.4.2 that can try?
More here: Click
Click to expand...
Click to collapse
Can't say... Will have to test
Sent from my C6902 using XDA Free mobile app
DooMLoRD said:
Can't say... Will have to test
Sent from my C6902 using XDA Free mobile app
Click to expand...
Click to collapse
I made a thread here. It should work.
http://forum.xda-developers.com/showthread.php?t=2783982
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