After lots of discussion about the famous "SuperBrick" issue on GT-I9100 4.0.4 stock kernels, I wrote a script to allow everyone to check it on their own and hopefully patch it if needed.
Main goal - Detection
Detect if a STOCK kernel has MMC_CAP_ERASE enabled (unsafe) or not (safe).
I have validated it against XWLPG, XWLPM, XWLPO, XWLPT, XXLP5, XXLP5-CFRoot and all of them were detected correctly: safe on 4.0.3 kernels, unsafe on 4.0.4 ones.
I also checked it against Siyah 3.5.2 (despite knowing from the sources it's safe) and it was also correctly detected.
However, for custom kernels I don't expect the code patterns to be always the same and therefore it's possible that the detection is inconclusive - you will see that in the output.
Secondary goal - Fixing (instructions provided, not the tools)
When an unsafe kernel is detected, provide instructions on how to patch the code so it's safe.
For that, you'll need:
* an external kernel unpack/repack script (just search the forum as there are several available)
* a Linux box
* a hex editor
* any other requirements for the repack script: CROSS_COMPILE, etc.
Requirements for this script
This is pretty much self contained and can be run on either:
* Linux
* Windows with Cygwin
Running on the device itself would be theoretically possible but it ultimately depends on the installed Busybox version, in particular the parameters accepted by the "grep" command.
On my v1.20.0-cm9 version it's not possible to make it work.
Sample outputs
Here are some executions against existing kernel images:
The latest XWLPT (4.0.4):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPT/zImage
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
1 ocurrences of the bad code signature
0 ocurrences of the good code signature
***************
!!! WARNING !!!
***************
[COLOR="Red"]The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices[/COLOR]
Unpacked kernel code stored at: XWLPT/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ec0
==================== Disassembly of the instruction ====================
XWLPT/zImage_instruction: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e3811b01 orr r1, r1, #1024 ; 0x400
========================================================================
*** Instructions for patching ***
- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ec0, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled
XWLPG (4.0.3):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPG/zImage
Kernel: Linux version 3.0.15-I9100XWLPG-CL619441 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu May 24 18:09:27 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
[COLOR="SeaGreen"]The kernel appears to be good (MMC_CAP_ERASE disabled)[/COLOR]
XXLQ5-CFRoot (4.0.4):
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XXLQ5_CFRoot/zImage
Kernel: Linux version 3.0.15-I9100XXLQ5-CL753921 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu Jun 28 14:16:15 KST 2012
1 ocurrences of the bad code signature
0 ocurrences of the good code signature
***************
!!! WARNING !!!
***************
[COLOR="Red"]The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices[/COLOR]
Unpacked kernel code stored at: XXLQ5_CFRoot/zImage_unpacked
The unsafe instruction can be found at offset 0x00594ef4
==================== Disassembly of the instruction ====================
XXLQ5_CFRoot/zImage_instruction: file format binary
Disassembly of section .data:
00000000 <.data>:
0: e3811b01 orr r1, r1, #1024 ; 0x400
========================================================================
*** Instructions for patching ***
- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x00594ef4, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled
Finally, here's the expected output of a kernel after the patch has been applied.
I didn't actually do the entire kernel repack, but I changed the code and compressed the file in a similar way as it will appear in a "complete" zImage file.
Patched XWLPM:
Code:
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: XWLPM-patched/zImage
Kernel: Linux version 3.0.15-I9100XWLPM-CL837163 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Thu Jul 5 11:26:14 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
[COLOR="Blue"]The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe[/COLOR]
Disclaimers
My main goal here is to provide information, not a one-click solution. I'm personally not worried about this issue since I run a kernel compiled from sources rather than a stock one.
Despite my best effort, I can't promise that:
- The detection will be flawless (although checks exist to make sure there's exactly 1 occurrence of either the "good code snippet" or the "bad code snippet" and an inconclusive result is reported if that's not the case)
- The patch will work or even be a runnable kernel (you might need to reflash another one from download mode). I have not performed the full unpack/repack process to test it out, although it's something already done elsewhere such as the CF-Root kernels and others.
That being said, enjoy
(Reserved)
WOW, << That's one small step for man, one giant leap for "s2 community" >> !!!!!
Now this is what XDA is all about. Good stuff man, much appreciated!
sorry for my "stupid" question;
I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?
Tkanks
hahaha yes man nice one... i hope that give us some nice ''stock'' roms
ps i was number 500 that hit your thanks button LOL
xky1980 said:
sorry for my "stupid" question;
I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?
Tkanks
Click to expand...
Click to collapse
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.
Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
Tungstwenty said:
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.
Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
Click to expand...
Click to collapse
Oooohh! So the kernel must be read from the same path of the script, not from the device! OK thanks
Inviato dal mio GT-I9100 con Tapatalk 2
---------- Post added at 09:18 AM ---------- Previous post was at 09:02 AM ----------
I've executed the script with siyah 3.5.2
the result is: The kernel appears to be good (MMC_CAP_ERASE disabled)
So it means that is possible to safely make wipes and nandroid restores from recovery on my XWLPT?
Thanks
Genius!
Sent from my GT-I9100 using Tapatalk 2
great work
Amazing work
Sent from my GT-I9100 using xda premium
Did someone test it on S2 with CWM ?
Great work dude!!
Keep it up
00raq00 said:
Did someone test it on S2 with CWM ?
Click to expand...
Click to collapse
What do you mean?
If you're talking about the detection, there's no such kernel as "CWM"
What exists is:
1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)
2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)
3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe
If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Code:
repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]
padding check (may take some time): 1
Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks
Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'
This checks out OK as having been patched OK.
Code:
./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
but sadly gets stuck at the boot screen
Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.
Peter
Tungstwenty said:
What do you mean?
If you're talking about the detection, there's no such kernel as "CWM"
What exists is:
1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)
2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)
3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe
If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
Click to expand...
Click to collapse
If we can detect brick bug in kernel and know what must be changed so why we can't fix stock kernel? If we can fix stock kernel my question is did someone do that and test it with fake cwm and wipe?
Sent from my GT-I9100 using Tapatalk 2
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Code:
repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]
padding check (may take some time): 1
Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks
Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'
This checks out OK as having been patched OK.
Code:
./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
but sadly gets stuck at the boot screen
Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.
Peter
Click to expand...
Click to collapse
Did you use this script here http://forum.xda-developers.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
Safe version of XWLPT stock.
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
Edit: Variable was assigned to nul rather than zero and was not a real problem.
Code:
repack-zImage.sh -u....
However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:
Code:
repack-zImage.sh -3 -p
...[CODE]./check-kernel-MMC_CAP_ERASE.sh
###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - forum.xda-developers.com #
# [email protected] #
# #
###############################################
Detecting safety of kernel: zImage
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 ([email protected]) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012
0 ocurrences of the bad code signature
1 ocurrences of the good code signature
The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe
Click to expand...
Click to collapse
I have now rebuilt this and it works! and it is available at the Dropbox link below.
http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar
Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)
http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
whiskerp said:
I have now rebuilt this and it works! and it is available at the Dropbox link below.
http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar
Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)
http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
Click to expand...
Click to collapse
Did you already test CWM Wipe?
whiskerp said:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.
I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:
...
Click to expand...
Click to collapse
darth_mickrig said:
Did you use this script here http://forum.xda-developers.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
Click to expand...
Click to collapse
whiskerp said:
I have now rebuilt this and it works!
Click to expand...
Click to collapse
After having the detection, I was also trying to get it to work using exactly that same repacker script, which darth_mickrig tipped me about.
I also found it has some errors, not only in the line you mentioned but also in the packing when using "-3" so that piggy can be edited directly rather that its inner blocks in separate files (which would require subtracting something from the offset displayed by my script).
wiskerp, I'm glad you had it sorted out already. I didn't have a chance to properly testing my patched+repacked zImage from one of the 4.0.4 versions (was planning on testing it despite the fact that I'm running a 4.0.3 ROM) so your feedback is great.
The repack-zImage.v6 script appears to no longer be maintained and its author doesn't post on XDA for a while now, but I'll try to see if I can reach him to know whether he's ok with updating that script for newer kernels in addition to fixing the existing bugs. It might work properly in other shells / bash versions, who knows...
In the meantime, I was also asked by a couple of N7000 guys to make the detection work for their kernels, which apart from the "really stock" ones have a different compression - lzma/xz instead of gzip on the outer layer. On the inner parts (initramfs) it's also not working correctly, so I'll need to check it out. CF-Root, for instance, uses a different compression than the base stock, probably so that the additional payload fits the partition size.
Oh, one note:
Keep in mind that despite being a patch on the stock kernel, the yellow triangle will appear and the counter will be incremented if you flash the patched version through Odin. It's no longer properly signed by Samsung.
Kudos to wiskerp for beating me to share a patched version :highfive:. I had already done the repackaging and was waiting to get home to flash and try it out to see if it would boot before posting it
Related
Whats does it take to port a 1.1BL ROM to 1.2BL? I want to start working on my own ROM and want to use an existing 1.1 ROM as a base, but want to stay on 1.2. I hope this isn't too difficult.
What flavour of ROM? Froyo/GB/HC?
Assuming you already have a flavour in mind, only the kernel changes between 1.1 and 1.2 for each type (the kernel used in the recovery image will also, of course, need to change). You will have to compile a kernel for each version of the bootloader.
This is the config file for an pershoot Android kernel which will be loaded by a 1.1 bootloader:
pershoot_tegra_harmony_android_defconfig
And this is for a kernel loaded by a 1.2 bootloader:
pershoot_tegra_harmony_android-newbl_defconfig
What's the difference between the two?
Code:
$ [B]diff -u pershoot_tegra_harmony_android_defconfig pershoot_tegra_harmony_android-newbl_defconfig[/B]
--- pershoot_tegra_harmony_android_defconfig 2011-09-12 23:55:56.273108334 +0530
+++ pershoot_tegra_harmony_android-newbl_defconfig 2011-09-12 23:55:46.973108334 +0530
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32.46
-# Wed Aug 31 13:11:33 2011
+# Wed Aug 31 13:12:20 2011
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
@@ -252,7 +252,7 @@
CONFIG_TEGRA_ODM_HARMONY=y
# CONFIG_TEGRA_ODM_VENTANA is not set
# CONFIG_TEGRA_ODM_WHISTLER is not set
-# CONFIG_NEWBL is not set
+CONFIG_NEWBL=y
#
# Processor Type
CONFIG_NEWBL is set for 1.2 kernels.
Cool thanks. I am planning on doing a GB ROM, based off the original Vanilla AOSP ROM. Probably nothing public, unless I think it is really good.
Still having a problem with this. I have unpacked the boot.img and re-packed with 1.2 kernels from both clemsyn and pershoot. I have also taken the wifi drivers and added them to the system folder for deployment with the ROM and set the permissions in the updater-script. ROM flashes fine, but gets the the first Android screen and just sits. Not sure what else i am doing wrong.
Obvious queston is: Is the bootloader 1.2 or 1.1?
Next: When you say 1st Android screen, is the
a) the VS birds (boot bitmap)
b) the Android logo (or plain white letters) which appears after that (/initlogo.rle)
c) the boot animation (bootanimation.zip)
Hanging at each stage is indicative of different sorts of problems.
You could also talk to gojimi, tjohnsonjr or craigacgomez here. All have AOSP based ROMs that run on 1.2.
It is b. The plain text Android logo.
markmac said:
It is b. The plain text Android logo.
Click to expand...
Click to collapse
That means that the kernel booted and was able to run /init OK. /init produces that Android logo in the absence of an /initlogo.rle file. This also means that you may be able to attach adb and look at log messages to find out what the problem is.
Thanks. I am not very familiar with adb yet, so i guess its time to learn.
Hi,
If you're a developer, I need your help.
I am running the following:
Android 2.3.4
Baseband I9100XXKH3
Kernel 2.6.35.11-ninphetamine-2.0.5+ ninpo at titan #20
Version Lite'ning Rom v6.1 XXKH3
I would like to compile a module (usb serial driver ftdi_sio.ko). For that I need the kernel source code. I found github.com /Ninpo /ninphetamine and got as far as compiling the module and insmod it, but I got in dmesg
"ftdi_sio: version magic '2.6.35.11-ninphetamine-2.0.5 SMP preempt mod_unload ARMv7 ' should be '2.6.35.11-ninphetamine-2.0.5+ SMP preempt mod_unload ARMv7 '
My problem I assume is that the source for ninphetamine I use, Android-galaxys2-ninphetamine-2d1ffbc, is not the right one. I can't find on the web the right source code version (2.0.5+), not to mention 2.1.3.
Anyone can point to the source code for me? (on a server that is running, kernel.org is on maintenance)
I am also quite open to install another ROM, kernel or other... even if possible one that has by default ftdi_sio.ko module running by default.
Thanks in advance for your responses.
edit:
I have now figured out so much, I can hack a bit to be able to insmod the modules:
- had to manually edit .config (replace ninphetamine-2.0.5 by ninphetamine-2.0.5+)
- make menuconfig modules ARCH=arm CROSS_COMPILE=arm-linux-androideabi-
- make drivers/usb/serial/*.ko ARCH=arm CROSS_COMPILE=arm-linux-androideabi- EXTRA_CFLAGS=-fno-pic
(it seems this -fno-pic was required for that version of tools, but does not work for all modules either)
=> it would still be nice to have access to exact source/config used to compile a ROM/kernel as well as the tools used to build it.
Now both modules load, but when I plug my device I am back to start with dmesg:
- usb 2-1: new full speed USB device using s3c_otghcd and address 2
- usb 2-1: device v0403 p6001 is not supported
- host_notify: ndev name=s3c_otghcd: from state=0 -> to state=5
- otg_dbg: in otg_handle_interrupt()::00087
- => Port Interrupt
- otg_dbg: in process_port_intr()::00271
- => port enable/disable changed
- hub 2-0:1.0: unable to enumerate USB device on port 1
Hope anyone get a clue.
Bump Bump Bump
A nice piece of advice was found here:
http://forum.xda-developers.com/showthread.php?p=18081882#post18081882
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.
Hi guys, im doing a project which requires the tablet to auto start when power is available through USB.
im using a datawind tablet d705 model with a mediatek cpu and kitkat version 4.4.2.
Here is a info dump from MTKtools:
Hardware : MT8312D
Model : D705
Build number : ALPS.KK1.MP7.V1.25
Build date UTC : 20150727-023443
Android v : 4.4.2
Baseband v: MOLY.WR8.W1315.MD.WG.MP.V64, 2014/08/02 09:47
Kernel v : 3.4.67 ([email protected]) (gcc version 4.7 (GCC) ) #1 SMP Mon Jul 27 10:31:34 CST 2015
Uboot build v : -----
LCD Driver IC : 1-rgb_mt6571_wvga
i have attached files that will help with figuring out the file that is loaded to show charging animation.
i have also tried most of the available methods on various forums to try to boot the tablet but failed.
fastboot oem off-mode charge 0 does not work
1. search in /system/bin/ for playlpm, ipod, lpm, kpoc_charger or any other file that have inside some reference to battery animation.
2. edit that file, delete all content inside and add
#!/system/bin/sh
/system/bin/reboot
i have a ipod file but it is not used for animation, deleteting the file from boot.img makes no difference at all.
1. Unpack boot.img and edit init.rc.
2. Add following to the end of file:
#Check if chargermode and start autoreboot service.
on property:ro.bootmode=charger
start autoreboot
#autoreboott service which command reboot
service autoreboot /su/bin/su /system/bin/reboot -c reboot now
user root
oneshot
none of the above worked. i also tried various methods to edit init.rc and init.charger.rc but nothing worked.
could some one please help me with this. im ready to donate for your kind help
So long story short, I wanted to build the ftdi_sio.ko module for the linux kernel of android based MiBox 1S. I was able to build the module but once I run "insmod" via adb, the system crashes and reboots (I couldn't see any error message because of this). Please could anyone suggest how to find where the problem is or whether what I wanted to do is even possible?
The device is running system version 1.3.88 rooted by the Chinese 360 root app. Kernel version follows:
Code:
adb shell cat /proc/version
Linux version 3.10.33 ([email protected]) (gcc version 4.7.3 20130205 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.02-01-20130221 - Linaro GCC 2013.02) ) #1 SMP PREEMPT Tue Jun 16 00:38:26 CST 2015
As Xiaomi doesn't have kernel source release for MiBox (afaik), I went to look for the Amlogic kernel source for AML8726-MX (M6).
The closet kernel source I could find was from Stane1983's github repo amlogic-m6_m8. I'm using the earliest commit for 3.10.33 kernel version.
For the building of the kernel module, I pretty much followed a github document named 'Android-Build-Kernel-Modules-HOWTO.txt' by marco-pratesi. I downloaded the toolchain from the archive of linaro releases 13.02 which shows the same version of the android kernel above. I copied the .config from arch/arm/configs/meson6_deconfig and use 'make menuconfig' to add OTG_support and USB FTDI Single Port Serial Driver. Make the module by "make M=drivers/usb/serial/". And then adb push the generated ftdi_sio.ko file to /mnt/sdcard.
For loading the module, I run
Code:
adb shell
su
insmod /mnt/sdcard/ftdi_sio.ko
Then the box freezes for 10 seconds and reboots...
So my questions are:
1. Is there a way to find some logs of insmod to know what's gone wrong? As the system freezes and reboots, I can't use the dmesg method normally suggested, can I?
2. As the kernel source is from Amlogic, could it be that Xiaomi created their own kernel that is very different from this one to cause this problem?
3. Even if Xiaomi used exactly the same source code, as i'm using the meason6_defconfig file from the repo, it is likely to be different from the one Xiaomi was using. Would it matter for just building a module?
4. Is it possible to recover the config file from the prebuild kernel? I counld't find /proc/config.gz. And modprobe has error "can't open 'modules.dep': No such file or directory. "
5. What else I can try?
Sorry for the long post. I'm very new to this type of work and this forum as well. So any comments would be appreciated.