Develop Bugs

Flashing Galaxy S kernel from update.zip : template update.zip

NEWS :
Koush's bmlunlock (a simple IOCTL send to the bml device) is just out and can replace redbend_ua !
http://github.com/CyanogenMod/android_device_samsung_bmlunlock
Hey
Is Flashing from update.zip the new trend ?
'Don't know but here is how you can do it quite easily using this template.
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
If you target another Galaxy S phone or another version of Android, you'll need to adjust ro.hardware and ro.build.id properties accordingly.
This template is done for Linux/Unixes/OSX.
If Linux cost too much for you or your employer, please contribute by sending a .bat equivalent to the .sh
Of course, you also need to put a valid zImage to replace the template's empty zImage
Feel free to adjust to your needs. License is WTFPL
Note : requirement are Java and Android source repo, already build.

Looks awesome!
I have a question though... why do you need to flash the kernel in an update.zip at boot?
As far as I know, the system will read the kernel at boot up time and load it into ram. It won't access the on-disk file again until the next boot. If that is true, then flashing while running should be 100% safe, right?

RyanZA it's an update.zip, not a ramdisk.
The point is getting an easy flashing method, requiring no computer.
And you don't even need to root your phone !

curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
edit:
sorry for major dumbness, but do you think this could also somehow be used to reflash a nandroid backup?

FadeFx said:
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
Click to expand...
Click to collapse
I don't think the signing tool works on android -- maybe it does? Anyway editing scripts on a phone seems a bit silly!

FadeFx said:
curio, as i see this script is quite simple, so dont u think this all could actually be done on the phone directly? i mean if people cant afford a linux machine...
edit:
sorry for major dumbness, but do you think this could also somehow be used to reflash a nandroid backup?
Click to expand...
Click to collapse
Nope actually this is not dumb at all
Yes the flashing part run in updater-script can be started manually.
In the script :
Code:
"redbend_ua", "restore", "zImage", "/dev/block/bml7"
The update.zip presented here mainly targets custom kernel creators in order to give them another way to distribute their work.
This is a working example of how to use redbend_ua programmatically, hopefully it may help new ideas coming. redbend_ua usage is not limited at all to kernel flashing.
PS : you can use this template with windows as well, you'll just need to translate the ulta-basic .sh to a .bat script, or do the signing part manually.

supercurio said:
Hey
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
Click to expand...
Click to collapse
quick question, the build-update-zip.sh is not a must if i only want to flash zImage, rite?
looks like that, I need to modify updater-script (if needed), as well as putting a zImage into ur zip file, and finally remove the build-update-zip.sh from ur zip attached
then, ur zip file can be used for flashing
is it correct?
thx

So this will let people flash any rom from an update.zip (once the ROM makers take this into account) via RomManager without ever having to use Odin to get off stock?
Awesome!

Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
supercurio said:
Hey
Is Flashing from update.zip the new trend ?
'Don't know but here is how you can do it quite easily using this template.
If you target a GT-I9000 on Eclair, you'll need to customize one thing :
In build-update-zip.sh, set DROID_HOME to the source code path for your local Android repository.
If you target another Galaxy S phone or another version of Android, you'll need to adjust ro.hardware and ro.build.id properties accordingly.
This template is done for Linux/Unixes/OSX.
If Linux cost too much for you or your employer, please contribute by sending a .bat equivalent to the .sh
Of course, you also need to put a valid zImage to replace the template's empty zImage
Feel free to adjust to your needs. License is BSD anyway.
Note : requirement are Java and Android source repo, already build.
I'll add some documentation later.
Click to expand...
Click to collapse

dseo80 said:
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
Click to expand...
Click to collapse
Thats for the updater-script i believe. In most cases, theres a update-script in the zip's as well and the recovery picks that up in which case it doesn't need the binary and hence works.

Okay !
Answers hour
ykk_five said:
quick question, the build-update-zip.sh is not a must if i only want to flash zImage, rite?
looks like that, I need to modify updater-script (if needed), as well as putting a zImage into ur zip file, and finally remove the build-update-zip.sh from ur zip attached
then, ur zip file can be used for flashing
Click to expand...
Click to collapse
When you run ./build-update-zip.sh,
- it produce a temp zip file containing appropriate files in it.
- then there'is the signature part, building another .zip, ready to be used.
- this "final" update.zip is put in the same current directory and you can use it as it is.
No further complication
Brantyr said:
So this will let people flash any rom from an update.zip (once the ROM makers take this into account) via RomManager without ever having to use Odin to get off stock?
Awesome!
Click to expand...
Click to collapse
Yes, to flash a complete ROM (several partitions) one more thing is needed.
On command line, redbend_ua accept only one command.
In order to run several commands successively (ie flash multiple partition like Odin does), you'll need to write them in a file.
The file /cache/ota/command should do the trick, but it's untested right now.
There may be other method to prevent rebooting after flashing (hacking the redbend_ua binary, finding the appropriate command line option or removing the reboot command temporary)
dseo80 said:
Thanks for the update script curio! this looks great.
One quick question - ive noticed several update.zip scripts for the galaxy S
have update-binary included.
Does anyone know what that does?? where did you get yours?
ive had success in using update.zips without that file at all.
Could anyone post information on what that binary is/does?
Click to expand...
Click to collapse
Right, many update.zip done today are made without knowing anything about how it really works
I studied a bit before creating mine, here is a walk-through this fairly undocumented process :
- recovery mounts /sdcard/
- recovery search for a default file named : META-INF/com/google/android/update-binary in the zip and runs it : see the source in bootable/recovery/install.c
- update-binary is actually updater in sources
- updater looks into the zip file to the script file named updater-script, update-script is obsolete
- updater then runs the commands listed in updater-script : here is the list of commands.
- then reboot
The only documentation I know for this command is the recovery/updater/install.c file itself

supercurio said:
When you run ./build-update-zip.sh,
- it produce a temp zip file containing appropriate files in it.
- then there'is the signature part, building another .zip, ready to be used.
- this "final" update.zip is put in the same current directory and you can use it as it is.
Click to expand...
Click to collapse
ok,thx
but one more thing i want to know is, u said the path must be changed to the android repo, so do u mean the source code for the kernel like linux-xxx-2.xxx dir?
Thx

@ykk_five
Content of build-update-zip.sh v1 :
Code:
#!/bin/sh
DROID_HOME="/home/curio/dev/mydroid"
zip -r /tmp/update.zip META-INF/ redbend_ua zImage
java -jar \
$DROID_HOME/out/host/linux-x86/framework/signapk.jar \
$DROID_HOME/build/target/product/security/testkey.x509.pem \
$DROID_HOME/build/target/product/security/testkey.pk8 \
/tmp/update.zip update.zip
rm /tmp/update.zip
adb push update.zip /sdcard/
DROID_HOME="/home/curio/dev/mydroid" : you set here the directory of your Android AOSP directory.
See : http://source.android.com/source/download.html
Create an empty directory to hold your working files:
$ mkdir mydroid
$ cd mydroid
Run "repo init" to bring down the latest version of Repo with all its most recent bug fixes. You must specify a URL for the manifest:
$ repo init -u git://android.git.kernel.org/platform/manifest.git
* If you would like to check out a branch other than "master", specify it with -b, like:
$ repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
Click to expand...
Click to collapse
This is this mydroid directory
The one that contains Android git source home directory, and compiled files in the out/ subdir

many thx for ur detailed explanation, supercurio!

Thanks curio,
very helpful explanation!

Thanks supercurio for the template!
However, there is no need to spend many hours (depending on hardware and bandwidth) pulling down 100s of megabytes of source and compiling it all if all you want is to sign an update.zip with test keys (if you already have the zImage)!
Just google around for "signapk.jar test keys" and you will get there.
BTW: I know that koush, leshak and wesgamer have Samsung Galaxy S trees up at Github but are they fully merged with AOSP yet?
I'm planning to go build my own kernel for this beast to try to solve the mono FM radio mystery, but last time I checked around it was said that the SGS tree required the use of a custom toolchain to get it to work at all.
Any comments on this?

Hey miki4242 !
Good to know that signapk.jar doesn't require hundred of megs of dependencies
About toolchain, you can use the one indicated by Samsung (CodeSourcery) but you'll face the big and ugly WakeLag.
I recommend you crosstool-ng or buildroot to build toolchains, with gcc 4.3.x march=arm mcpu=cortex-a8 mtune=cortex-a8 (no 4.4.x with march=armv7-v)
The building tutorial will be a part of the documentation I'll publish with my lagfix opensource release
Right now these info are too hard to find.
PS : I send you a mail with attached .config for ct-ng !

supercurio said:
Hey miki4242 !
Good to know that signapk.jar doesn't require hundred of megs of dependencies
Click to expand...
Click to collapse
supercurio said:
PS : I send you a mail with attached .config for ct-ng !
Click to expand...
Click to collapse
Thanks for the info !

Sorry for my ignorance, but does this mean someone can package Froyo in an update.zip and we could update it directly on our phone without needing Samsung Kies or Odin?

@supercurio:
Thanks for this well working template.
In updater-script:
Code:
line 17: package_extract_dir("zImage", "zImage");
should be
Code:
package_extract_file("zImage", "zImage");
But it did work with package_extract_dir, for some reason, too.
Btw, could you send me the config for ct-ng ?
I'm also struggling with this wakelag.

[KITCHEN] Minimal kernel building VM with scripts

I added some convenience scripts to the config. Read the new tutorial here
The old one still works:
I put together a small virtualbox vm with a very minimal debian config with which I was able to compile a working kernel. This is for all the people who are running Windows, and want to try modifying kernels/initramfs's. As this is a minimal config there are some drawbacks (like it doesn't have a graphical interface), but you can always install additional packages, if you want to.
The VM includes: debian, build essentials, git, vb guest additions, mc, vim and codesourcery 2010q1 gnu-eabi. (it's larger than the simple eabi version, but can be used to compile non-kernel applications too)
First of all I hate both SunOracle VirtualBox and debian, but VB is free, and debian is lean, so they'll do the job.
To get the image running do the following:
First download and install VirtualBox
Next download the VM image: http://android.sztupy.hu/dl/KernelCompilerVM-1.1.7z and extract it. (it's a large download. If you can please put it up a mirror)
Mirrors: (thanks to the people mirroring it)
- http://www.multiupload.com/THJV19BJ9X
- http://bote.ro/sztupy/KernelCompilerVM-1.1.7z
After this run virtualbox, and import this VM.
Run the VM. The username/passwords are: root/root and kernel/kernel. Login with kernel. (you can always switch to root using sudo)
Next choose what kernel/initramfs you want to compile.
Here are some links to kernels:
The original sources can be found at supercurio's git:
Code:
git://github.com/project-voodoo/linux_gt-i9000.git
froyo-samsung branch
The kernel of the voodoo project can be found at the same place:
Code:
git://github.com/project-voodoo/linux_gt-i9000.git
froyo-voodoo branch
The ULTK kernel can be found at my account:
Code:
git://github.com/sztupy/universal_lagfix_kernel.git
Here are some links to initramfs files:
The original froyo initramfs can be found at supercurio's git page:
Code:
http://github.com/project-voodoo/samsung_ramdisks.git
afaik the voodoo initramfs is build using scripts from these images, so you have to apply them.
The ULTK initramfs can be found here:
Code:
git://github.com/sztupy/universal_lagfix_kernel_initramfs.git
For the rest of the tutorial I'll be showing how to compile ULTK:
First get the kernel sources using git:
Code:
git clone git://github.com/sztupy/universal_lagfix_kernel.git kernel
Unfortunately no copy-paste function is available, so you have to write this manually...
Next get the initramfs using git:
Code:
git clone git://github.com/sztupy/universal_lagfix_kernel_initramfs.git initramfs
If everything goes well you'll have two directoryes, called kernel and initramfs. Next we have to modify some values in the kernel configs.
Nano, mcedit and vim are installed, use the one that suits you best. (mcedit is the most user friendly)
Switch to the kernel directory and edit the Makefile there:
Code:
cd kernel
nano Makefile
Find the row that says
Code:
CROSS_COMPILE ?= some value
Replace it to
Code:
CROSS_COMPILE ?= /home/kernel/arm-2010q1/bin/arm-none-linux-gnueabi-
(if using nano make sure it won't add a line break into the row)
Next load the default config:
Code:
make aries_eur_defconfig
And edit it:
Code:
nano .config
We have to supply the directory of the initramfs. Search for the line:
Code:
CONFIG_INITRAMFS_SOURCE=some value
and replace it to
Code:
CONFIG_INITRAMFS_SOURCE=/home/kernel/initramfs/out
(this is for the ULTK. For voodoo the initramfs locations are "froyo-xxjp6" and "froyo-xxjpm" instead of "out")
if you've managed to do that too, let's compile the kernel:
Code:
make
If everything goes fine after a while you will have your shiny new kernel. Now let's get it to your computer, so it can be flashed:
First, you have to create a shared folder in VirtualBox. Simply create a directory somewhere on your computer, and add it as a shared folder in virtualbox. The name of the shared folder should be simple, for example "shr".
Next, you have to mount that directory inside the VM. To do this enter:
Code:
sudo mount -t vboxsf shr ~/share
After it has been mounted you can copy the fresh kernel to your host OS:
Code:
cp arch/arm/boot/zImage ~/share
If everything goes well you have a zImage ready at the folder you've just shared. TAR it, fire up odin, and flash.
---------------------------------
Now that you've succesfully compiled a working kernel try to modify it. You can use "make menuconfig" in the kernel directory to switch some kernel functions (like filesystem supports) on and off. You can edit .config by hand to add or remove some configuration values. And you can edit the files in the initramfs directory. After modifications you only have to enter "make" in the kernel directory to get your kernel inside the "arch/arm/boot/zImage" dir ready.
You can also copy files from your host OS, to the guest OS, by putting the file inside the shared folder and copying it:
Code:
cp ~/share/thefile ~/initramfs/copyithere
Hope this guide was useful.

Impressive, thanks. Even a noob like me can try this.

Oh god, not only a talented developer, but a community helper!
STICKY!!
Gonna try it laters <3

oh yea, nice!

DocRambone said:
Impressive, thanks. Even a noob like me can try this.
Click to expand...
Click to collapse
If you're a noob, then I'm a baby

Darkyy said:
If you're a noob, then I'm a baby
Click to expand...
Click to collapse
high time you start compiling kernels

tnx
its very usefull

Magnificent!
I just came to take a quick look, but the thread deserves a closer one.
Thank you for sharing knowledge.

Worthy of a sticky.
Hopefully this will solve all those "I want this in a kernel but not that" scenarios.

This is VERY nice for the devs.. but.. i think this will make this forum spammed with 69 diff kernels with just minor changes.. as with the roms

Its better to let other people brick their phone than you brick your own
Just kidding! I for one will try and compile different versions with different lag-schemes to find the fastest combination. Including /system with fastest reading. I think I will add a benchmark to the recovery menu directly. Benchmarking each mount for read and for write speeds. Maybe I can use backup/restore code and just time it without writing (cp to null). Lets get to work
Thanks sztupy!
Sent from my GT-I9000 using XDA App

_JKay_ said:
Its better to let other people brick their phone than you brick your own
Just kidding! I for one will try and compile different versions with different lag-schemes to find the fastest combination. Including /system with fastest reading. I think I will add a benchmark to the recovery menu directly. Benchmarking each mount for read and for write speeds. Maybe I can use backup/restore code and just time it without writing (cp to null). Lets get to work
Thanks sztupy!
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
You cannot brick your phone with a bad kernel

@sztupy
I am impressed how productive master mind and kind person you are sharing all your knowledge and developments with us.
Congratulation, with you contributions you push Android Development forward.
Thank you

this is really cool, if i need minimal GUI, what would you suggest? xfce ? or there is something smaller and lighter? thx again.

avary said:
this is really cool, if i need minimal GUI, what would you suggest? xfce ? or there is something smaller and lighter? thx again.
Click to expand...
Click to collapse
Fluxbox/Openbox. However I don't see the need for one, if you're running the machine just for compiling.
Also, shouldn't gpm+guest additions solve the copy-paste problem?
E: Apparently not. Meh, stupid virtualbox.. sshd+putty then!

Awesome! Thanks for this sztupy! The more people we can get involved in this stuff, the better the end result will be. Always!

aziztcf said:
Fluxbox/Openbox. However I don't see the need for one, if you're running the machine just for compiling.
Also, shouldn't gpm+guest additions solve the copy-paste problem?
E: Apparently not. Meh, stupid virtualbox.. sshd+putty then!
Click to expand...
Click to collapse
actullay i was looking for something light and minimal (with GUI, or at least something like PCman FM and gedit or kedit, im not good with emac, vi ) to play and compile AOSP, for now i do this with Kubuntu dual boot on my laptop. if i put a litghweight desktop on top of szytup's image and use it with VB, that would be great.
thank you !

avary said:
actullay i was looking for something light and minimal (with GUI, or at least something like PCman FM and gedit or kedit, im not good with emac, vi ) to play and compile AOSP, for now i do this with Kubuntu dual boot on my laptop. if i put a litghweight desktop on top of szytup's image and use it with VB, that would be great.
thank you !
Click to expand...
Click to collapse
I'd use a shared folder+IDE/editor/whatever on windows. But that's just because I have so awful experiences about X in VMs, things might be better nowadays

Thanks a lot sztupy, will try it now. Sunday is enough time for testing
Each morning i have a look at XDA and you have brought out a new very helpfully posting, kernel, rom or else!
So let me ask you one question: when do YOU sleep?

avary said:
actullay i was looking for something light and minimal (with GUI, or at least something like PCman FM and gedit or kedit, im not good with emac, vi ) to play and compile AOSP, for now i do this with Kubuntu dual boot on my laptop. if i put a litghweight desktop on top of szytup's image and use it with VB, that would be great.
thank you !
Click to expand...
Click to collapse
The advantage of using X is that afaik guest additions has copy-paste support, that would make modifying easier.
I also plan on making some simple scripts inside the default home directory one can run to communicate with the shared folder. After that we could provide simple scripts that you only have to put inside the shared folder, which will download, modify and run the compilation.

FTDI kernel module unknown relocation

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...

[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.

Include an individual file in the lineage sources

Hello folks,
I am a beginner. Sorry if it's a stupid question.
I want to include a file when compiling a custom rom with Lineage OS. It should be under "/sys/module/dwc3/parameters", named "aca_enable" and contain a "Y".
How can I build this into the sources so that it is already there after flashing?
I've already searched the web, but couldn't find anything.
Thanks for replies in advance!

This is not a normal file. Kernel modules expose flags under /sys/module/<module-name> which can be changed by file operations. Pretty common under linux to have such interfaces (e.g. procfs).
I can't give you a complete answer, but can probably point you in the right direction: You need to do some research on init.rc. Basically you need to set a rule in an .rc file in /system/etc/init. (Or compile a new kernel / the dwc3 module and set a new default value)

sn00x said:
This is not a normal file. Kernel modules expose flags under /sys/module/<module-name> which can be changed by file operations. Pretty common under linux to have such interfaces (e.g. procfs).
I can't give you a complete answer, but can probably point you in the right direction: You need to do some research on init.rc. Basically you need to set a rule in an .rc file in /system/etc/init. (Or compile a new kernel / the dwc3 module and set a new default value)
Click to expand...
Click to collapse
Hello, many thank you for the answer!
Yes I understand. These files are created and modified at runtime. Then I know where to look. An example would be best. "Copy and Paste" is a popular method. ;-)

First try - quick and dirty - did not work.
I put the following lines into the system/core/rootdir/init.usb.rc (lineageos sources):
# Set /sys/module/dwc3/parameters/aca_enable to "Y"
write /sys/module/dwc3/parameters/aca_enable Y
After compiling the ROM, flashing it on the device and boot the device the file /sys/module/dwc3/parameters/aca_enable contain a "N".
On the Spartphone the file /etc/init/hw/init.usb.rc contains the modified lines.
In the modified file dwc3_otg.c i can't find anything that write a "N".
Maybe someone has an idea or an alternative?
(Here is the source code of dwc3_otg.c https://github.com/sollapse/opo_dwc3_otg/)

Well, just change 0 to 1 in line 42.

sn00x said:
Well, just change 0 to 1 in line 42.
Click to expand...
Click to collapse
Hello, oh yes - I had tomatoes on my eyes. Thank you very much for the tip!

sn00x said:
Well, just change 0 to 1 in line 42.
Click to expand...
Click to collapse
It works!
Thank you so much for making the effort.
fyi: Another option would be here.