FTDI kernel module unknown relocation - Gen9, Gen10 General

Hey guys,
I've spent a few days now researching and attempting to build the FTDI kernel module for my Archos 70b. After following this guide I managed to get a successful compilation. I uploaded it to my device (which was rooted via Paul's root and rebooted into sde). When I attempt to use insmod, I get the following error: insmod: cannot insert '/sdcard/ftdi_sio.ko': Invalid module format (-1): Exec format error. I ran 'dmesg -c' and got the following output: [ 684.472290] ftdi_sio: unknown relocation: 27. I have the usbserial module installed already as well. What is the problem here? I'm assuming by relocation it means it's loading the module into the wrong part of the address space? I could be very off I'm new to this process. I just want to thank everyone in advance for their help, this is my first post and I've used these forums extensively over the last few days. You have a great community here.
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules

whistlinwilly said:
Hey guys,
I've spent a few days now researching and attempting to build the FTDI kernel module for my Archos 70b. After following this guide I managed to get a successful compilation. I uploaded it to my device (which was rooted via Paul's root and rebooted into sde). When I attempt to use insmod, I get the following error: insmod: cannot insert '/sdcard/ftdi_sio.ko': Invalid module format (-1): Exec format error. I ran 'dmesg -c' and got the following output: [ 684.472290] ftdi_sio: unknown relocation: 27. I have the usbserial module installed already as well. What is the problem here? I'm assuming by relocation it means it's loading the module into the wrong part of the address space? I could be very off I'm new to this process. I just want to thank everyone in advance for their help, this is my first post and I've used these forums extensively over the last few days. You have a great community here.
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
Click to expand...
Click to collapse
Hi !
First be sure that you have the same version kernel->module , run modinfo module.ko and vermagic need to be the same with kernel version !
- if it's ok you can try strings module.ko and than insmod module.ko !
( but can be many things wrong in your process of compiling module !!! ) Good luck ...

I can confirm that the versions are the same, I was using an incorrect version before and dmesg was complaining. I've since compiled the module for the right kernel version and now dmesg only gives me the "unknown relocation: 27" error.
I ran the strings command, it outputted over 4000 lines. I'm not quite sure what you could gain from the output but I can attached the text file I piped it to if that will be helpful.

whistlinwilly said:
I can confirm that the versions are the same, I was using an incorrect version before and dmesg was complaining. I've since compiled the module for the right kernel version and now dmesg only gives me the "unknown relocation: 27" error.
I ran the strings command, it outputted over 4000 lines. I'm not quite sure what you could gain from the output but I can attached the text file I piped it to if that will be helpful.
Click to expand...
Click to collapse
Ok!
May be you have a problem when your module "export symbols" -> take a look into Module.symvers ... and see if something export !

I looked around and couldn't find Module.symvers either in the source code or on the actual device. Do you know where I might be able to find it or how I can create the file myself? When the module is compiled, make throws a warning about not being able to find it. I think this is the problem.

whistlinwilly said:
I looked around and couldn't find Module.symvers either in the source code or on the actual device. Do you know where I might be able to find it or how I can create the file myself? When the module is compiled, make throws a warning about not being able to find it. I think this is the problem.
Click to expand...
Click to collapse
Hi !
...maybe it help you => http://tldp.org/LDP/lkmpg/2.6/html/lkmpg.html
( module.symvers is created after you run make ( for make module) in directory where you compile module )

I'm not quite sure I understand. I get a warning
WARNING: Symbol fakepath/kernel/Module.symvers
is missing; modules will have no dependencies and modversions.
when I run make in the modules folder. There IS a file created called Module.symvers after I run make, but it is empty; I'm assuming its just a copy of whatever Module.symvers file it is actually looking for.
Has anyone compiled the archos gen9 kernel that might have created this file and can pass it along to me?

whistlinwilly said:
A little extra information:
I'm using the toolkit from the android-ndk-r8. My makefile looks like this:
obj-m := ftdi_sio.o
KDIR := ~/bin/gen8/archos-gpl-gen9-kernel/
PWD := $(shell pwd)
CCPATH := ~/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) M=$(PWD) modules
Click to expand...
Click to collapse
Hi whistlinwilly
Are you sure you've grabbed the right kernel source - your KDIR says gen9, if your compiling for the 70b you probably need the gen8 kernel source code as I think it's on the Gen8 product line
you can check which kernel version you have by running the following from a command prompt.
Code:
adb shell uname -a
Hope that helps

Hey whistlinwilly,
i don't know if you were successful in the meantime, but here's what i suggest for simple kernel module compilation...
You might refer to my custom kernel thread and check my toolchain, which is ready to rock (only 32bit linux right now):
http://forum.xda-developers.com/showthread.php?t=1328027
To compile custom kernel/modules only, look here as well:
http://forum.xda-developers.com/showpost.php?p=19134490&postcount=8
The archos specific toolchain uses uclibc and is used for kernel and userland.
So if you use stock kernel, but choose a different toolchain (e.g. libc based) to compile your modules, you might run into trouble at some point.
BTW, is it correct that you talk about this device:
http://www.archos.com/products/ta/archos_70b/index.html?country=de&lang=de
Not sure which family it exactly belongs to
If you're talking about this one:
http://www.archos.com/products/ta/archos_70it2/index.html?country=de&lang=de
...the kernel should be 2.6.35 then.
http://gitorious.org/archos/archos-gpl-gen9-kernel
I'm not aware of any config for the A70IT2 though.
Please refer to trevd's suggestion and find out your kernel release first...
Good luck!
scholbert

I had the same problem (Relocation error: 27) when trying to compile a custom kernel module for my Moto xoom running Honeycomb.
I was able to compile successfully by rolling back to Android NDK 5b. I also had to force the vermagic string to read ARMv7 so I know this isn't the right way to solve the problem, but when I compiled with the 5b toolchain, the relocation error goes away and I am able to insmod without error on the tablet.
I would love to know why this works and the right way to get NDK 7 to work with this, if anyone can shed some light??
EDIT:
On further digging and testing- I realize it is not necessarily NDK 5b, but rather the toolchain "arm-eabi-4.4.0" as opposed to using the "arm-linux-androideabi-4.4.3" toolchain, that makes the difference with the "unknown relocation 27" error. It just so happens that NDK 5b is the last NDK that shipped with both toolchains, AFAIK.
It still for some reason likes to compile under ARMv5 unless I force it to use ARMv7 but this issue is probably unrelated- I didn't mean to confuse things with the ARM v5/v7 versus NDKr5 /NDKr7 which don't correlate...
Anyway I hope this helps, or maybe someone else who knows more can help us both!

Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!

the_zuck said:
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
Click to expand...
Click to collapse
Thanks a million, finally got past the relocation 27 error now. Insmod doesn't complain anymore and the drivers load successfully, now to just figure out why I'm getting a backtrace on device insertion.
Thanks for solving my major headache tho

Exec format error
the_zuck said:
Well, I solved my toolchain issue- I just needed to add an EXTRA_CFLAGS=-fno-pic to get the arm-linux-androideabi-4.4.3 toolchain to compile without seeing an unknown relocation error on the tablet.
Hope this helps someone!
Click to expand...
Click to collapse
Ok, thanks for the answer. My first post here.
After this got solved. I still have "Exec format error". And! and no errors are display in dmesg. Are there any other places where the error might be displayed? I just created a simple printk("hello world") project.
If i remove the printk it doesn't show the error.
I don't know whether to laugh or cry. I dabbled my self to the brink of madness to solve this. I couldn't find a solution anywhere. Finally solved it after 6 weeks of my time. Probably my boss at work will not be happy if he finds I was working on this instead of working.
And I find the solution here 2 days after I solved it. WOW!!!:crying::crying:
But my saga still continues...

Related

[Q] Cant build kernel modules for Android Desire CM6

Hi All
While I am a relative noob when it comes to Android development (I have been an embedded developer for over 25 years), I am pretty good at creating custom embedded kernels for MIPs targets. However, this issue seems to be getting the best of me.
Environment:
Ubuntu 10.04 + any automatic upgrades
HTC desire phone, rooted, running cyanogenmod 6.0.1 (and 6.1.0 from the daily builds)
Issue: I am trying to add batman-adv to the phone, but I cannot create a batman-adv.ko that insmod will load. When I put my ko file on the phone and try to load it I get "insmod: init_module 'batman-adv.ko' failed (Exec format error)" (Yes I am in su mode). I know that this generally indicates that I have built for the incorrect architecture and I suppose that is the real question. How do I GET the correct architecture.
I extracted a ko from the phone that works on the phone and ran 'file' on it:
ah6.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
and this is what I get on my ko
batman-adv.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
Based on this, the architecture is correct (or appears to be correct).
EDIT1:
I am getting a bit closer. I get this in dmesg
batman_adv: version magic '2.6.35.4-cyanogenmod-gb7da4b8-dirty preempt mod_unload ARMv7 ' should be '2.6.35.4-cyanogenmod preempt mod_unload ARMv7
Looks like I need a way to remove the "-gb7da4b8-dirty" portion of the string (actually avoid having it there in the first place).
End EDIT1
Build environment:
I have downloaded (via repo / git) and built the cyanogenmod SDK (daily build from 9/11/2010 kern: 2.6.35.4). The output of a build of this repo is an update-foo.zip file which I loaded on the phone and verified that it works properly. The repo includes a kernel-msm directory with (an apparently) fully functional kernel build tree (as well as the sdk and ndk trees).
I have pulled the config.gz file from the (working nicely) phone (update-foo.zip version), unzipped it and fed it into the build system. Answered the annoying questions you get when you merge in a new config file and added batman-adv to the selected loadable modules list to be built (also had to play with the file to fix a few other issues).
Build script looks like this (CCOMPILER points to the pre-built compiler in the sdk):
cd $SYSTEM_PATH || exit
. build/envsetup.sh
lunch cyanogen_bravo-eng
cd $SYSTEM_PATH/kernel-msm || exit
make ARCH=arm CROSS_COMPILE=$CCOMPILER -j$CPU_COUNT clean || exit
make ARCH=arm CROSS_COMPILE=$CCOMPILER -j$CPU_COUNT | tee build.log ||
The build completes just fine and I get all of the expected ko's. I have not tested the kernel itself since I am not really interested in it. It should be the same as the kernel built by the SDK and included in the update-foo.zip file. Worst case the KO would load and crash if the ko and the kernel on the phone were incompatible (I would be happy to get that far).
Issue is resolved.
While the insmod function returned a bad format error, it was really complaining about the magic number mismatch. Once I took care of matching the ARMv5 vs ARMv7 issue and then did an over ride on the KERNELVERSION string, I was able to load and execute the ko without any additional issues.
Wow! You do like to write don't you mate?
I'm glad it got resolved....should I close this thread or you want to get some more input?
Cheers,
We can close the thread. I write so much because I see so many post with insufficiant information to make a good diagnosis. In addition, those threads also tend to wander off the subject, making them a bit less than usefull.
Martin
I believe I am trying to do the same thing here, but for a different phone.
You say you're adding your module to the selected loadable modules to be built. Isn't there a way to build a loadable module by itself without rebuilding or changing kernel settings?
I have been able to compile/install modules for ubuntu linux but I haven't been able to figure out how to compile them for my android device. I have the source tree for the kernel build I'm using but I'm not quite sure how to go about cross compiling my module for it...

[HOWTO] tun.ko to run OpenVPN on Froyo xxJPK Galaxy S I9000

NOTE: there is no guarantee this will work, because without access to the corresponding kernel source I can't be sure. It may wipe out your device if there's memory corruption! You're warned, use it only at your risk!!
Over the last weekend I wanted to familiarize with the arm assembly, buildsystem, SDK so I created a tun.ko module for kernel running in the JPK ROM. But lots of the time was also wasted trying to guess their config (things like disabled DMABOUNCE and removal of the dummy they added in 2.6.29 from struct net_device, I hope I got it all right).
I encourage to release the kernel source along with the ROM images in the future (it'd be much simpler if there was a git tree that they can just tag with the name of the ROM), and to include the tun device into the modules/tun/tun.c (as in the tarball) so that it is included by default in the future. I won't be doing this process again.
I had to install openvpn with the openvpn installer a second time with openvpn in xbin, busybox in xbin/bb and I created the bb directory and two symlinks from xbin/bb/{ifconfig,route} to xbin/busybox (after mounting /system rw). The DNS to change during VPN must be set by long pressing on the left of the openvpn config slot in the OpenVPN settings GUI.
The tun.ko I keep it in /sdcard/openvpn/tun.ko and the path has to be configured in the openvpn settings advanced settings menu and I choose to load it with insmod.
This JPK rom works great for me, so I'll likely keep using it for a long while now that I've got openvpn running fine.
252ae6e655fa08774f32f67dd76dad3a tun.ko
EDIT: the same tun.ko module works for JPM too
Great job!!!
I use vpnc daily, so I couldn't even think to upgrade to JPK without an available tun module.. now I can!
Would you share your .config, so other devs can use it? Maybe we can hope in a Froyo-voodoo in a short time..
I'm confirming that it works.
Here is how I did it (I garantee that THIS IS NOT THE MOST ELEGANT WAY to make it work)
Install Openvpn from Openvpn Installer
openvpn in /system/xbin
route and ifconfig in /system/bin
At this point, Openvpn could connect and create a tun device, but route are not pushed so it's not very usefull
So, I downloaded this version of Openvpn
http://github.com/downloads/fries/android-external-openvpn/openvpn-static-2.1.1.bz2
As superuser
Code:
su
I remounted in rw /system
Code:
mount -o remount,rw /system
I renamed /system/xbin/openvpn into openvpn_old
Code:
mv /system/xbin/openvpn /system/xbin/openvpn_old
I put that new openvpn binary in /system/xbin
I created symlinks from /system/bin/route and ifconfig to /system/xbin
Code:
ln -s /system/bin/route /system/xbin/route
ln -s /system/bin/ifconfig /system/xbin/ifconfig
I also created a symlink os /system/xbin to /system/xbin/bb, just in case
Code:
ln -s /system/xbin /system/xbin/bb
Here we go
captive said:
Would you share your .config, so other devs can use it?
Click to expand...
Click to collapse
+1
i tried to complie cifs.ko and tun.ko for the JPC kernel and couldnt get it to work. i ultimately went back to eclair because of this so would like to be able to compile modules and other filesystem support.
thanks.
kanemari said:
+1
i tried to complie cifs.ko and tun.ko for the JPC kernel and couldnt get it to work. i ultimately went back to eclair because of this so would like to be able to compile modules and other filesystem support.
thanks.
Click to expand...
Click to collapse
config attached, but the config is not enough and it may not be fully correct (it is enough as far as the data structures used by tun.ko are concerned, I checked them all against the zImage assembly). The diff of the v2.1 image, has to be applied too but with DMABOUNCE removed from Kconfig of the subarch of the galaxy as far as I can tell and the placeholder added to struct net_device in their v2.1 diff, has to be removed too. cifs.ko may be more complicated than tun, good luck. Unless you've personal interest to familiarize with the enviroment and the arm assmbly like I had, I would wait the source to released, it has to be released eventually to comply with the GPLv2.
Thankyou Newmail!!
I've tryed VPNC 0.99 and works great!!
You have only to type from terminal: insmod /system/folder/tun.ko
After that you can use VPNC...
I've found an issue with the FQDN of the VPN gateway... solved setting the IP address
Just a question:
when I'll update my JPK.. what I have to do to recompile the tun.ko?
Can you write here the procedure?
Cheers
Paolo
newmail said:
config attached, but the config is not enough and it may not be fully correct (it is enough as far as the data structures used by tun.ko are concerned, I checked them all against the zImage assembly). The diff of the v2.1 image, has to be applied too but with DMABOUNCE removed from Kconfig of the subarch of the galaxy as far as I can tell and the placeholder added to struct net_device in their v2.1 diff, has to be removed too. cifs.ko may be more complicated than tun, good luck. Unless you've personal interest to familiarize with the enviroment and the arm assmbly like I had, I would wait the source to released, it has to be released eventually to comply with the GPLv2.
Click to expand...
Click to collapse
OK, but is the placeholder field at the end of the net_device struct?
If so it shouldn't matter and a module cross compiled from the 2.6.29 source should be OK. The absence of DMABOUNCE shouldn't matter for tun.ko either.
In theory you should be able to clone the AOSP git kernel repo and use that kernel for building a module, as long as the module itself doesn't actually use changes that have been made by Samsung (unlikely).
The .config used probably does deserve some attention though, as you have done.
foloap said:
Thankyou Newmail!!
I've tryed VPNC 0.99 and works great!!
You have only to type from terminal: insmod /system/folder/tun.ko
After that you can use VPNC...
I've found an issue with the FQDN of the VPN gateway... solved setting the IP address
Just a question:
when I'll update my JPK.. what I have to do to recompile the tun.ko?
Can you write here the procedure?
Cheers
Paolo
Click to expand...
Click to collapse
Glad it works great for you too. So the tun.ko has to be recompiled if they alter .config. It may work but it's not guaranteed. The procedure is nasty and hard to document and I don't have enough time for that sorry. But I'm sure we'll get the source when there will be an official Froyo release that is shipped to all phones so I wouldn't worry.
raven-au said:
OK, but is the placeholder field at the end of the net_device struct?
If so it shouldn't matter and a module cross compiled from the 2.6.29 source should be OK. The absence of DMABOUNCE shouldn't matter for tun.ko either.
In theory you should be able to clone the AOSP git kernel repo and use that kernel for building a module, as long as the module itself doesn't actually use changes that have been made by Samsung (unlikely).
The .config used probably does deserve some attention though, as you have done.
Click to expand...
Click to collapse
The .config is the fundamental part, and it may be enough I'm not sure. There was a placeholder was a samsung customization done in the middle of net_device and that was removed in the Froyo ROM (initially I applied it). the DMABOUNCE removal affects the struct device that is part of net_device so a lot of stuff goes off by 4 bytes by tweaking that arch config option. That gets set in some Kconfig patched in by samsung. You're right that probably tun isn't affected by the DMABOUNCE but I tried to get the net_device size right (just in case) and it may affect other net modules.
Hi newmail, thanks so much for the tun.ko file, this is the first time I've managed to get VPNC working on my SGS!! One question though, I find I'm having to run insmod everytime I reboot the phone to make tun.ko available again, does anyone know if there's a way around this please so it stays permanently available? Many thanks!!
@bdl1969
I made a subdir in /system/lib called "modules" and placed my tun.ko there.
Now it's insmodded automagically..
newmail said:
The .config is the fundamental part, and it may be enough I'm not sure. There was a placeholder was a samsung customization done in the middle of net_device and that was removed in the Froyo ROM (initially I applied it). the DMABOUNCE removal affects the struct device that is part of net_device so a lot of stuff goes off by 4 bytes by tweaking that arch config option. That gets set in some Kconfig patched in by samsung. You're right that probably tun isn't affected by the DMABOUNCE but I tried to get the net_device size right (just in case) and it may affect other net modules.
Click to expand...
Click to collapse
Oh crap, that is bad news.
Then both the DMABOUNCE and the net_device are likely a problem.
That's a stupid way of doing things.
raven-au said:
Oh crap, that is bad news.
Then both the DMABOUNCE and the net_device are likely a problem.
That's a stupid way of doing things.
Click to expand...
Click to collapse
The smart way of doing things I already mentioned in the first post (public git tree tagged at every ROM release .
captive said:
@bdl1969
I made a subdir in /system/lib called "modules" and placed my tun.ko there.
Now it's insmodded automagically..
Click to expand...
Click to collapse
hmm I tried and it didn't work for me... are you sure? openvpn GUI runs insmod for me so it's no big deal.
That worked great for me, thanks for the suggestion! The only problem I found was that it caused my Good for Enterprise app to crash so I uninstalled and reinstalled it and then it was all fine. Only problem I'm left with now is when using VPNC, I make the VPN connection fine but I can't disconnect via the app, I have to bounce the network connection (eg. toggle WiFi) to drop the tunnel!
I compiled tun.ko using the 2.6.32 kernel from android git and your .config, but it won't load with dmesg saying "Unknown symbol mem_map". May I ask which kernel version did you use, and what arm toolchain are you using?
sztupy said:
I compiled tun.ko using the 2.6.32 kernel from android git and your .config, but it won't load with dmesg saying "Unknown symbol mem_map". May I ask which kernel version did you use, and what arm toolchain are you using?
Click to expand...
Click to collapse
Probably you have discontigmem off in the .config. The platform of the galaxy isn't in the android kernel, it's in arch/arm/plat-s5pc11x (it's the thing that sets DMABOUNCE in v2.1 roms and I guess it doesn't on the JPK kernel).
You need to make a diff between android 2.6.29 and their tree, and apply it to the 2.6.32 kernel, then you need to solve enough rejects so that it can build external module. I didn't port the whole diff of course, just enough so make can start with the headers and .config all right. Then I built the module externally (adding the tun/ directory to their modules/ directory) but it should also work with just make modules setting CONFIG_TUN=m if you want to build it in-tree.
It's a bit tricky.. If you really need I can give you the broken diff to apply to the 2.6.32.9 android kernel. That is enough to build some module including tun.ko
newmail said:
Probably you have discontigmem off in the .config. The platform of the galaxy isn't in the android kernel, it's in arch/arm/plat-s5pc11x (it's the thing that sets DMABOUNCE in v2.1 roms and I guess it doesn't on the JPK kernel).
You need to make a diff between android 2.6.29 and their tree, and apply it to the 2.6.32 kernel, then you need to solve enough rejects so that it can build external module. I didn't port the whole diff of course, just enough so make can start with the headers and .config all right. Then I built the module externally (adding the tun/ directory to their modules/ directory) but it should also work with just make modules setting CONFIG_TUN=m if you want to build it in-tree.
It's a bit tricky.. If you really need I can give you the broken diff to apply to the 2.6.32.9 android kernel. That is enough to build some module including tun.ko
Click to expand...
Click to collapse
It'd be great. I've already tried to do the patching. It compiles, but crashes the phone when loaded. Maybe your version is a bit better.
sztupy said:
It'd be great. I've already tried to do the patching. It compiles, but crashes the phone when loaded. Maybe your version is a bit better.
Click to expand...
Click to collapse
Did you find the source now that JPM has been released officially with Kies? I upgraded to JPM now, in the hope we get the source....
BTW, my tun.ko and my rfs_async.ko also works fine on JPM. I don't know about my ext4 build but I assume that will work too.
I used one CSC of this thread http://forum.xda-developers.com/showthread.php?t=802909 and I deleted the KOR /efs/nv_data* created by the JPK ROM (leaving the .nv_data.bak*). So with this combination of CSC from that thread, and MODEM and PDA from the JPM rar, I apparently restored the original product_id (SGSToolbox also says I'm back to the original product_id). Not that product_id matters but I thought I'd try that next time I flashed and apparently it worked fine...
newmail said:
Did you find the source now that JPM has been released officially with Kies? I upgraded to JPM now, in the hope we get the source....
BTW, my tun.ko and my rfs_async.ko also works fine on JPM. I don't know about my ext4 build but I assume that will work too.
I used one CSC of this thread http://forum.xda-developers.com/showthread.php?t=802909 and I deleted the KOR /efs/nv_data* created by the JPK ROM (leaving the .nv_data.bak*). So with this combination of CSC from that thread, and MODEM and PDA from the JPM rar, I apparently restored the original product_id (SGSToolbox also says I'm back to the original product_id). Not that product_id matters but I thought I'd try that next time I flashed and apparently it worked fine...
Click to expand...
Click to collapse
The JPM source was avialable for a few hours on the samsung's site, did grap it. You can find it on megaupload somewhere. I couldn't manage to compile a working module from that source either (it now loads fine, but does a kernel panic when I try to mount a loop device formatted with ext4), but I'm sure that's my fault.

[Guide] Building from sources [Kernel only for now]

Hello everyone.
This guide will help you in building a kernel from source for your Nexus 10
Later, when 4.2 hits AOSP, i'll add a guide for building that too
You will need a computer running Linux / OSX to build the kernel, natively, or via a VM.
This guide assumes you’re running any Linux distro.
Getting a toolchain:
You need a toolchain to build the kernel.
The preferred one is Google’s toolchain, the same they use to build AOSP.
In a terminal, type:
Code:
git clone [url]https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/[/url]
export PATH=$PATH:$(pwd)/arm-linux-androideabi-4.6/bin
export CROSS_COMPILE=arm-linux-androideabi-
TIp: paste the export statements in your ~/.bashrc to have them exported each login.
Getting the kernel source:
The kernel source for Nexus devices is available from Google’s servers.
Source : https://android.googlesource.com/kernel/exynos
Github Mirror: https://github.com/chirayudesai/android_kernel_exynos
Open the terminal, and type the below commands to get the kernel source on your computer.
Code:
mkdir -p android/kernel
cd android/kernel
For Nexus 10, we get the exynos kernel sources.
Code:
git clone [url]https://android.googlesource.com/kernel/exynos[/url]
Next, we change our directory to the newly fetched source.
Type
Code:
cd exynos
Figuring out what to build:
Now, we need to figure out which revision to build.
You need to be exactly sure about this, otherwise there are chances that the compiled kernel won’t work.
The commit to build upon can be found by a few ways.
To get the kernel sources matching the device tree, type the below in the device tree.
Code:
git log kernel
Then type the below in the kernel tree
Code:
git checkout <commit>
The commit of the version running on the current review units is 52f6ab1 (probably), which is same as branch android-exynos-manta-3.4-jb-mr1-fr .
Compiling:
Name of defconfig: manta_defconfig
cd to the directory of the kernel source, then type the below in a terminal.
Code:
export ARCH=arm
export SUBARCH=arm
Code:
make <name_of_defconfig>
make
The kernel image will be ready at arch/arm/boot/zImage
To flash it, you need to make it into a boot.img, more on that later. when we have more sources.
Nice work, it's been nice to see some instructions on building additional kernel modules too.
Sent from my GT-I9300 using Tapatalk 2
Great guide! I look forward to seeing your tutorial on compiling 4.2 from source .
Sent from my SCH-I535 using xda premium
Super awesome! I'm currently thoroughly:good: learning the rom building process with my nexus... ill get to this!
looking forward towards the development
Great! This is very helpful and useful
hey man, i got stuck at this point
Code:
git log kernel
it gives me this error
Code:
fatal: ambiguous argument 'kernel': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
didn't really get that point... thanks :good:
matt95 said:
hey man, i got stuck at this point
Code:
git log kernel
it gives me this error
Code:
fatal: ambiguous argument 'kernel': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
didn't really get that point... thanks :good:
Click to expand...
Click to collapse
It has to be typed in the device tree, which hasn't hit AOSP yet, but should soon.
Sent from my GT-P1000
cdesai said:
It has to be typed in the device tree, which hasn't hit AOSP yet, but should soon.
Sent from my GT-P1000
Click to expand...
Click to collapse
oh, now i get this :good:
i was able to make a build tonight from aosp, waiting for my device to arrive & then ill be able to test. but as far as i could tell the output sizes were pretty on compared to the factory image files i extracted http://renzy.me/aoi
...just realized i didnt extract proprietary binaries.
Hello, Cdesai.
Thanks for your guide!
I will do my best to learn it.
so you say that you need to make the zImage into a boot.img (being a noob about this...) on my SGSII, I can flash zImages and boot.img, so I'm confused, lol
jrod091 said:
so you say that you need to make the zImage into a boot.img (being a noob about this...) on my SGSII, I can flash zImages and boot.img, so I'm confused, lol
Click to expand...
Click to collapse
i think it depends on how youre flashing. with the sgsii youre prob using odin/heimdall & it might just overwrite the kernel. flashing with fastboot might require the boot.img cause it contains a ramdisk image after the kernel & is writing a partition. thats just my guess at least, someone else might have a better/more accurate answer for ya
renzyyy said:
i think it depends on how youre flashing. with the sgsii youre prob using odin/heimdall & it might just overwrite the kernel. flashing with fastboot might require the boot.img cause it contains a ramdisk image after the kernel & is writing a partition. thats just my guess at least, someone else might have a better/more accurate answer for ya
Click to expand...
Click to collapse
yeah that's true, but for instance with HTC S-OFFed devices you don't even need to flash the boot.img....
cdesai said:
... To flash it, you need to make it into a boot.img, more on that later. when we have more sources.
Click to expand...
Click to collapse
you can extract the contents from the factory image & use getramdisk.py to get the ramdisk.img out of the current boot.img (or use this ramdisk.img)
then once youve compiled the kernel successfully, use mkbootimg from android_bootimg_tools.tar.gz to repack your boot.img.
if you want to just test...
fastboot boot [new-boot.img]
and flash if satisfied...
fastboot flash boot [new-boot.img]
just tested out if anyone wants some verification... screenshot
@cdesai, shouldn't we be using arm-eabi- instead of arm-linux-androideabi- as CROSS_COMPILE
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
Building with arm-linux-androideabi- causes issues with kernel modules... here's an example of such an issue https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/dzEIOVuxtEo
And the most updated kernel branch is android-exynos-manta-3.4-jb-mr1 not android-exynos-manta-3.4-jb-mr1-fr
Is there any chance of this becoming an OC kernel in the future?
craigacgomez said:
@cdesai, shouldn't we be using arm-eabi- instead of arm-linux-androideabi- as CROSS_COMPILE
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
Building with arm-linux-androideabi- causes issues with kernel modules... here's an example of such an issue https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/dzEIOVuxtEo
And the most updated kernel branch is android-exynos-manta-3.4-jb-mr1 not android-exynos-manta-3.4-jb-mr1-fr
Click to expand...
Click to collapse
Yes, I couldn't get md4 and cifs modules to load with arm-linux-androideabi-4.6:
<3>[ 1250.492203] md4: unknown relocation: 27
<4>[ 1260.230901] cifs: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
However, with this:
git clone https://android.googlesource.com/platform/prebuilt
export PATH=$PATH:$PWD/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export CROSS_COMPILE=arm-eabi-
The modules load okay:
[email protected]:/mnt/shell/emulated/0 # lsmod
cifs 269223 0 - Live 0x00000000
md4 3442 0 - Live 0x00000000
(Now I have to work out why neither mount nor cifsmanager are working as expected...)
sam3000 said:
Yes, I couldn't get md4 and cifs modules to load with arm-linux-androideabi-4.6:
<3>[ 1250.492203] md4: unknown relocation: 27
<4>[ 1260.230901] cifs: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
However, with this:
git clone https://android.googlesource.com/platform/prebuilt
export PATH=$PATH:$PWD/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export CROSS_COMPILE=arm-eabi-
The modules load okay:
[email protected]:/mnt/shell/emulated/0 # lsmod
cifs 269223 0 - Live 0x00000000
md4 3442 0 - Live 0x00000000
(Now I have to work out why neither mount nor cifsmanager are working as expected...)
Click to expand...
Click to collapse
I know the reason... busybox needs to be patched... i guess it's something new in 3.4.5 kernel... I haven't done the patch yet
https://github.com/OpenELEC/OpenELEC.tv/commit/f66041febdb07d13a158dab5da901d208cf4fff9
craigacgomez said:
I know the reason... busybox needs to be patched... i guess it's something new in 3.4.5 kernel... I haven't done the patch yet
https://github.com/OpenELEC/OpenELEC.tv/commit/f66041febdb07d13a158dab5da901d208cf4fff9
Click to expand...
Click to collapse
I had actually just got to the point of realising I could make it work by explicitly setting the unc path in mount command options. The missing patch would explain it.

[SOLVED] concerning zlib and aromafm

@Hazou @ketut.kumajaya
okay so,
my first question is, after building philz and going through static_libraries folder i find libz.a .
is this zlib built static, and if so can i relocate it to aromafm source in place of building zlib?
there seems to be too many dependancies that i'm not sure how to locate/point to that largely
seem to be in my kernel source, [cpuset.c,cpuset.h,adler32.c[x86] ?
if so please explain completely as i am still fairly noobish
getting better though :victory:
aromafm is a must have !
thank you for reading
m
moonbutt74 said:
@Hazou @ketut.kumajaya
okay so,
my first question is, after building philz and going through static_libraries folder i find libz.a .
is this zlib built static, and if so can i relocate it to aromafm source in place of building zlib?
there seems to be too many dependancies that i'm not sure how to locate/point to that largely
seem to be in my kernel source, [cpuset.c,cpuset.h,adler32.c[x86] ?
if so please explain completely as i am still fairly noobish
getting better though :victory:
aromafm is a must have !
thank you for reading
m
Click to expand...
Click to collapse
Aromafm is new for me, i have used it, but never build it in any way.
The zlib u build when buildibng your recovery is static, so it is a static library.
I don't know if u can replace it for the source in aromafm. Aromafm (quick look) uses his own source. But u can alway try. Out comment every line about zlib:
Code:
## ZLIB SOURCE FILES
LOCAL_SRC_FILES := \
libs/zlib/adler32.c \
libs/zlib/crc32.c \
libs/zlib/infback.c \
libs/zlib/inffast.c \
libs/zlib/inflate.c \
libs/zlib/inftrees.c \
libs/zlib/zutil.c
## ZLIB NEON SOURCE
ifeq ($(AROMA_ARM_NEON),true)
LOCAL_SRC_FILES += libs/zlib/inflate_fast_copy_neon.s
endif
and add "libz" after "libc".
Code:
## INCLUDED LIBRARIES
LOCAL_STATIC_LIBRARIES := libm libc libz
I can't find your "dependencies" so quick. Where did u find them? Most off them will probably just work.
Hazou
okay, go !
hazou,
thanks for the speedy reply,
okay so, first, cpuset.c i located in my kernel source, in aroma it's refered to in libs/zlib at
320 # if defined(__i386__) || defined(__x86_64__)
321 # include "x86/cpuset.c" <==== typo in souce said cpudet.c
322 #endif
neither the directory or the file exist in the source as it is.
i mkdir x86 in libs/zlib for libs/zlib/x86 , then searched cm11 from top and located what i can only
assume was the correct file [cpuset.c] in my kernel source and cp > aromafm/libs/zlib/x86 and naturally
now i have to either cp everything jn that chain or, drag my kernel source into aromafm directory.
can i point to an 'off-world' source outside of build directory? if so what does that look like?
as to zlib libz.a, the down side of a static lib is it doesn't necessarily fit to a specific purpose/function right?
thanks for your help as always.
m
moonbutt74 said:
hazou,
thanks for the speedy reply,
okay so, first, cpuset.c i located in my kernel source, in aroma it's refered to in libs/zlib at
320 # if defined(__i386__) || defined(__x86_64__)
321 # include "x86/cpuset.c" <==== typo in souce said cpudet.c
322 #endif
neither the directory or the file exist in the source as it is.
i mkdir x86 in libs/zlib for libs/zlib/x86 , then searched cm11 from top and located what i can only
assume was the correct file [cpuset.c] in my kernel source and cp > aromafm/libs/zlib/x86 and naturally
now i have to either cp everything jn that chain or, drag my kernel source into aromafm directory.
can i point to an 'off-world' source outside of build directory? if so what does that look like?
as to zlib libz.a, the down side of a static lib is it doesn't necessarily fit to a specific purpose/function right?
thanks for your help as always.
m
Click to expand...
Click to collapse
About that zlib. I still don't know if it will work. There may be a call from other files to the zlib files. And if so, i dont think it will work.
As for the cpudet.c, its not a typo. It looks like they were present in the source of zlib. But put outside by the developer because of ARM. U need to find the cpudet.c, put it into the following folder inside the source of aromafm: include/x86/cpudet.c. The same thing goes with: include/x86/adler32.c. But maybe it only works when u have it at aromafm/x86/cpudet.c/aromafm/x86/adler32.c.
I found the zlib variant the developer uses (old one i think, but maybe nessecary) and it includes the missing files, here From Koush
Heee heeee heeee!
hazou,
cool, will check out,
okay so, this is what i did,
forced compile for non neon
replaced uncompiled source for both zlib and libpng and mmm
result aromafm-santos10wifi
flash in recovery and......it works! .......mostly [lag, can i pull libenc trick with this?]
i need to adjust for display and figure out a way to enable/facilitate scrollback in terminal
at terminal #whoami
returns #uid0 :good:
busybox :good:
m
moonbutt74 said:
hazou,
cool, will check out,
okay so, this is what i did,
forced compile for non neon
replaced uncompiled source for both zlib and libpng and mmm
result aromafm-santos10wifi
flash in recovery and......it works! .......mostly [lag, can i pull libenc trick with this?]
i need to adjust for display and figure out a way to enable/facilitate scrollback in terminal
at terminal #whoami
returns #uid0 :good:
busybox :good:
m
Click to expand...
Click to collapse
Nice that it works! The pixelflinger (libenc) trick wont work here. I think that aroma can be enhanced with the libenc trick, but it needs heavy modding on graphical (framebuffer) part. And i don't have the skills to get that sorted.
good deal
Hazou said:
Nice that it works! The pixelflinger (libenc) trick wont work here. I think that aroma can be enhanced with the libenc trick, but it needs heavy modding on graphical (framebuffer) part. And i don't have the skills to get that sorted.
Click to expand...
Click to collapse
hazou,
thanks for the pointer, i wasn't sure of which direction to look. I am starting to get the hang of this stuff. got philz done, getting aromafm done.
thanks so much.
m

[Q] Working & stable SSHD/sftpd for ZE55xML ?

Apologize for possible OT, but I can't find an always working (and stable) SSH daemon app for the Zenfone2's Lollipop
This is what I tried, any of them PAID apps:
QuickSSHd - too old, not even starts
SSHDroid Pro - sometime starts, only first time after reboot, but only without root and higher ports (>1024)
RRooted SSH/SFTP Daemon - always refusing connections
Ssh Server Pro (olive tree) - seems promising, but very poor of binaries
The Dropbear service hanging issue seems the root of this problem
Thanks for any hint
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Blades said:
I can't even find a proper ssh binary. I just tried sshd from an x86 cyanogen port (RAZRi, I think). Got this after loading appropriate library in lib (same as client)
1|[email protected]:/ # sshd
CANNOT LINK EXECUTABLE: could not load library "libssh.so" needed by "sshd"; caused by cannot locate symbol "EVP_ripemd160" referenced by "libssh.so"...
Good luck sir
Click to expand...
Click to collapse
Hi,
I followed the following guide which you can get from googling "Compiling-Dropbear-for-a-Nexus-7-tablet". Sorry, I can't post any links yet as my post counts are still below 10
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Cheers.
wolfdude said:
The difference with the info from the website above is that we don't need to cross compile if you're compiling in a Linux x86-64 system. Just need to make a static binary.
Let me know if you have any questions and I'll try to help out.
Click to expand...
Click to collapse
Thanks for your answer.
Sorry but I can't get the exact entry-point, bypassing all the NDK / X-compiling stuff, as we're on a x86_64 architecture
Referring to the "simplified" version of your link (here: https://nerdoftheherd.com/articles/cross-compiling-dropbear-rsync-android/ ),
how should I compile the Dropbear source ?
Something like this ?
Code:
./configure \
--disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog \
CFLAGS='-Os -W -Wall -fPIE' LDFLAGS='[COLOR="Red"]-static[/COLOR] -fPIE -pie'
... right before make-ing ?
Thanks for any further hint in the right direction
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
From that site, what I did was :-
1) Download dropbear v58 (dropbear-2013.58.tar.bz2). I know this is older but the patch available is based on this version.
2) Download patch (dropbear-patch2) from that site.
3) Apply patch to the original dropbear (v58) source.
4) Run configure :-
./configure --disable-zlib --disable-largefile --disable-loginfunc \
--disable-shadow --disable-utmp --disable-utmpx --disable-wtmp \
--disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
5) Run make :-
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
6) You should end up with "dropbearmulti" which is a static binary that you can then copy over the the phone & go on from there.
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
wolfdude said:
Hi,
I didn't refer to that site you have posted BUT that site does have a link at the bottom to the site where I followed.
[...]
There are some issues with that version of the code (v58+patch). Namely the "scp" doesn't work (but I have found the offending code in scp.c and found a workaround).
Let me know if you need more details. If I have some time, I might look at getting the latest dropbear version & working out a patch for it to get it to work on android x86.
Cheers.
Click to expand...
Click to collapse
Yes of course. The main link you weren't able to post is:
http://blog.xulforum.org/index.php?post/2013/12/19/Compiling-Dropbear-for-a-Nexus-7-tablet
Actually that procedure seemed too complex as mostly dealing with the cross-compiling issue, which didn't apply to x86 case.
So I named the derivative one
Thanks for pointing out the static compiling is done within MAKE and not CONFIGURE phase... I'm quite newbie in those flags so I do appreciate any of your words
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Val3r10 said:
About issues, what about using the latest v67 for Dropbear sources ? (see here)
If the patch doesn't work for such different version, I guessed commenting out the interactive password line would be enough
I'm trying to compile it this way and - for instance - replace the binaries in one of the SSHD packages I named in the OP...
Thank you again for your time
Click to expand...
Click to collapse
Hi,
Yes, the patch for v58 does not work for v67. I think one just have to go through the patch and "adjust" it slightly for the newer v67. Hopefully there isn't much changes from v58 to v67. There may be more than just commenting out the password prompt as there are certain functions that don't work in Android as in *NIX. When I have some time, I will attempt to patch v67 meanwhile, I'm running v58 fine on my ZE550ML so no complains there.
Cheers.
Hi,
I've created a guide on compiling the latest dropbear (2015.67) :-
http://forum.xda-developers.com/zenfone2/general/compiling-dropbear-2015-67-zenfone-2-t3142222
Hope it helps.
Cheers.
wolfdude said:
I've created a guide on compiling the latest dropbear (2015.67)
Click to expand...
Click to collapse
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Val3r10 said:
Thanks a lot.
Do you think the same process (STATIC build, of course, not patching) could be likely used for other small binaries too ?
Click to expand...
Click to collapse
Of course. I've managed to compile tcpdump, iperf, gdbserver, etc... successfully and working fine on the Zenfone 2.
Cheers.
I found that "Servers Ultimate" SSH/SFTP modules work on the Zenfone2 once properly configured. Its not working 100% but its already more then most solutions out there.

Categories

Resources