Related
Dont have this tap anymore so cant support it anymore !!!
I do things manual as i want to know what has be done !
So every thing below is hardcore installation. This will give you the why and know how of things !!!
About bootimg.cfg
This file is need for creating boot.img
You can find it by unpacking a boot.img,but one is provided already.
The important part of this file is the first and last option.
The first one will say how big the image wil be, and the last is kernel cmdline.
This is also wehre you say loop= for a loop file
Pack or unpack blob files
Code:
cd /tmp
git clone git://github.com/AndroidRoot/BlobTools.git
cd BlobTools
make -j2
sudo cp blobpack /usr/bin/
sudo cp blobunpack /usr/bin/
cd ~
Unpack a boot.img
We create a folder and place a boot.img in it.
Code:
mkdir ~/test
cd ~/test
abootimg -x boot.img
Unpacking a initrd image
Code:
cd ~/test
mkdir ramdisk
cd ramdisk
gzip -dc ../initrd.img | cpio -i
Now you will have a directory with the ramdisk source files in ~/test/ramdisk
to repack it, run
Code:
cd ~/test/ramdisk
find . | cpio -o -H newc | gzip > ../new-initrd.img
for gzip
Code:
find . | cpio -H newc -o | lzma -c > ../initram.lzm
for lzma
This will give you a new-initrd.img file in ~/test/ for you to use............versions<
Go to the folder and select ALL file or folder BUT source and build !!!!
And compres it file wel be made in home.
modules are install in ubuntu in /lib/modules/
About kernel and initrd and boot.img and blob
Kernel = basic hardware installations and setup
initrd = like a ramdisk
boot.img = kernel + initrd
blob = boot.img + TF special header
Blob file you find in cwm.zip like a kernel update for android
boot.img you will find when using nvflash
kernel gets compiled from a git or source
initrd you can make your own or reuse
i will create cwm.zip to do the flashing
To do this i do.
Code:
mkdir ~/test
cd ~/test
cp ~/TF101-GNU-kernel/arch/arm/boot/zImage ~/test/zImage
abootimg --create ./ubuntu.img -f ./bootimg.cfg -k ./zImage -r ./initrd.img
This will give me a ubuntu.img ready for nvflash but i want cwm.
so i do
Code:
./blobpack kernelblob LNX ubuntu.img
(LNX is boot partition dont change this unless you know what your doing)
Now i got a new file kernelblob that i can add to a cmw.zip file
To do this , open !!!! the cmw.zip below and remove and add the file kernelblob.
Thats it, and ready for flashing.
Rootfs
You sould be able to use any rootfs that is for arm.
you can also build a rootfs with rootstock
keep in mind a rootfs kan have diffrent types of names like ( rootfs.img.ext234 or ubuntu,dabian,linux.img.ext234 or evrey name you want it to be its just a name+ext)
If you want to relock it for oem-config ( nice first setup like name location keyboard setup) do
Code:
touch /var/lib/oem-config/run
Ubuntu
Kbuntu
XBMX
So how do we even flash ?
I use nvflash directly or cwm
The easy why is just using Olife.
Keep in mind that i will never use uboot , only original bootloader of android.
So dualboot is what you need.
if you have dualboot flashed, do this.
Replaced (backup!) initrd-2.6.38.img and 2638-zImage in the kernel folder with my files,
and in Olife update your chromium kernel.
For those that want to use a loop file
Just flash this zip file
And copy the rootfs to sdcard (nand) /sdcard/linux/ubuntu.img (more will come, thats why linux/ubuntu.img)
Wifi setup
Wifi simply needs 2 files and you can get them from android space -> then copy them to Ubuntu space to /lib/firmware/
/data/misc/wifi/nvram.txt -> /lib/firmware
/data/misc/wifi/wpa_supplicant.conf -> /etc/wpa_supplicant.conf #optional
just use a root exploror to copy them to sdcard or usb ( this can alo be done when your in Ubuntu space (/system = mmcblk0p1, /data = mmcblk0p7))
and put them on the right place for Ubuntu.
Bluetooth setup
There are 3 file needed from android space, to get this,
Enable bluetooth
Rename you bluetooth name to what ever you want ( once in Ubuntu you cant change this !!!! )
Leave it on !! and boot to Ubuntu
/data/misc/bluetooth/{bcm4329.hcd,mac.txt} -> /lib/firmware
brcm_patchram_plus (lives on the net) -> /usr/sbin/brcm_patchram_plus (already in)
As last edit /etc/init.d/bsp-tf101 and correct your mac adress --bd_addr ***** (replac *** with mac !!!, mac is located in mac.txt)
.
Code:
#! /bin/sh
do_stop(){
#look if Board Support Package is already running
PS=$(ps -A | grep " brcm_patchram_plus\>")
if [ -n "$PS" ]; then
echo "* Stoping Bluetooth Support Package..."
killall brcm_patchram_plus
fi
}
do_start(){
#if already started then stop first
do_stop
#now start all board support binaries
echo "* Starting Bluetooth Support Deamon..."
rfkill unblock 0
modprobe bcm4329
/usr/sbin/brcm_patchram_plus --enable_hci --baudrate 921600 --bd_addr ***** --patchram /lib/firmware/bcm4329.hcd /dev/ttyHS2&
# making sure the nvtegra dev nodes have the correct permissions
echo "* Setting correct permissions on nvtegra device nodes..."
chmod 0666 /dev/nv* /dev/tegra_*
}
case $1 in
start | restart)
do_start
;;
stop)
do_stop
;;
esac
and reboot and your done.
Installing Tegra HEADER files ( needed when building things like XBMC )
Copy as root all folder to /usr/include/
Installing Opengl-ES
Download the Tegra drivers from Nvidia
Once downloaded unpack it and open a cmdline and go to that direction Where those files are and type,
Code:
sudo ./app*.sh --help
-r = your root directeroy whey you want to install this
--abi = witch version of abi your running, to get you version run in ubuntu on TF
Code:
aptitude show xserver-xorg-core | grep abi
So when running this directy on the TF in Ubuntu you wil get this
Code:
sudo ./app*.sh --abi 10 -r /
Get audio working
Code:
sudo usermod -a -G audio
sudo chmod -R 777 /dev/snd/*
Then open alsamixer and enable
playback
Left And Right speaker mixer DACL/R
Set DC input to DMIC
And sound sould work right away.
Install zram
Code:
sudo wget -O /etc/init/zramswap.conf 'https://wiki.ubuntu.com/ARM/TEGRA/AC100?action=AttachFile&do=get&target=zramswap.conf'
Installing XBMC
sudo apt-get install (try installing all dependencies you can in the readme.ubuntu in xbmc folder , some will fail so just remove them) )
Code:
cd ~
git clone git clone git://github.com/xbmc/xbmc.git
cd xbmc
./bootstrap
./configure --enable-tegra --enable-gles --disable-openmax --disable-vdpau --disable-hal --disable-joystick --disable-debug --disable-dvdcss
make -j2
sudo make install
sudo apt-get install libgl1-mesa-swrast
Loop or native parition
in your config (dualboot.cfg)
You kernel cmdline would be
( if you have native root=/dev/mmblk0p8 rw.........)
( for loop support you add loop= ( location of file !!! + root= (the partition where the file is located !!)
root=/dev/mmcblk0p7 rw loop=/xxx/xxx
Default Kernel
files
Support
hdmi ( audio ? )
USB ( full working )
jack ( mic ? )
Opengl-ES
zram ( needs script also a most have beacuse of low ram space )
-more to come
Sources
kernel
Khronos header package
Tegra Opengl-ES drivers
Blobtools
THANKS TO:
Jhinta said:
Supports..
Code:
OpenGL-ES
zram
Wifi
Bluetooth
FB -> half working no txt output
HDMI fully supported
Kexec enabled , dont know if its even working
Not working !!!
Sound
Touchpad
If you want to use this make sure the 3D driver are installed ( no FB !!! ), so install them first !!!!
And add the modules to you rootfs.
And keep in mind unity does not have gles support yet ( kde sould but didnt tryed it yet )
Download
Kernel
Modules
Source
make sound hardware pupup , still no sound
sudo usermod -a -G audio <your username here>
sudo chmod -R 777 /dev/snd/*
Click to expand...
Click to collapse
I will give this a shot tonight and let you know how it goes.
I'm sorry if this is a stupid question but what is FB? I tried searching on the forum and online but the only reference I could find was facebook.
could you use git, or post a .patch for the framebuffer patch because there is no way I am going to spend ages downloading the kernel source from 2shared then having to try and find WTF you did
Ke1evraTi: It just means the framebuffer which is the base graphics support under linux. Basically since it does not work, you won't see much until the X11 drivers kicks in.
lilstevie: Pulling the original kernel from Asus was way slower than 2shared. Also creating the patch was quick. Only a few hundred lines to skim. I have attached it for you or anyone else who is interested. If my diff options do not suit your fancy, kindly suggest different ones and I will re-post.
lilstevie said:
could you use git, or post a .patch for the framebuffer patch because there is no way I am going to spend ages downloading the kernel source from 2shared then having to try and find WTF you did
Click to expand...
Click to collapse
Sorry m8 i didnt had any sleep last two day's i was broke when i uploaded it , was easy for me fast upload thats why. but looking add the path above that sould do it if not ill will send a patch.
? any one tested already?
download link
I coldn't use the download link, the host gives error like "Gateway Timeout". Can you check it please, is it me or the host?
dismis said:
I coldn't use the download link, the host gives error like "Gateway Timeout". Can you check it please, is it me or the host?
Click to expand...
Click to collapse
The server is currently down for maintenance and will be back up in the next few hours
All done now
lilstevie said:
The server is currently down for maintenance and will be back up in the next few hours
All done now
Click to expand...
Click to collapse
lil , look on nvidia git , tty fix maby? i'm add work cant do anything.
Ok. I am running ubuntu on a sbk2 tf101 using the method posted by jozka.1 how do i apply the new kernels like the on posted here to that install? i know that this is a total noob question but i want to try it on my unit. I know that it says that the video acceleration does not work on unity but should work on kde. will it work on gnome?
Sent from my Transformer TF101 using XDA Premium HD app
Sorry, kernel isn't working for me. I installed the latest linux4tegra driver package, added the modules folder posted to /lib/modules and flashed the kernel through CWM, but the GUI fails to load and running startx from the command line does nothing. I'm not sure if this was my mistake, but the modules posted were for the 2.6.39.4 kernel and Jhinta posted a 2.6.36.4 kernel. Where did I mess up?
MrMuffin24 said:
Sorry, kernel isn't working for me. I installed the latest linux4tegra driver package, added the modules folder posted to /lib/modules and flashed the kernel through CWM, but the GUI fails to load and running startx from the command line does nothing. I'm not sure if this was my mistake, but the modules posted were for the 2.6.39.4 kernel and Jhinta posted a 2.6.36.4 kernel. Where did I mess up?
Click to expand...
Click to collapse
ore you flashed the wrong zip file ore the flashes didnt install make sure after cwm you see the blue line going meening its flashing the blob
Yep definitely the right kernel and I did see the blue line afterwards. Just to make sure that I've done this right, so I:
-download linux4tegra package, run: sudo <path-to>/apply_binaries.sh --root /
-run: sudo cp -r <path-to>/2.6.39.4/ /lib/modules/
-reboot to CWM, flash Ubuntu-3D.zip
-reboot.
MrMuffin24 said:
Yep definitely the right kernel and I did see the blue line afterwards. Just to make sure that I've done this right, so I:
-download linux4tegra package, run: sudo <path-to>/apply_binaries.sh --root /
-run: sudo cp -r <path-to>/2.6.39.4/ /lib/modules/
-reboot to CWM, flash Ubuntu-3D.zip
-reboot.
Click to expand...
Click to collapse
thats it, maby i did send a wrong one , any way here it is
Jhinta said:
thats it, maby i did send a wrong one , any way here it is
Click to expand...
Click to collapse
the latest t4l drivers use the 3.1 kernel, so which version of l4t did you use?
Still no luck with the new kernel posted by Jhinta, with the r12beta drivers installed on a sbkv2 device.
Heres the screen I originally get when I boot:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Here's what I get when I run startx:
I'll try it again from scratch, just in case. Let me know if there are any logs or anything you want me to post.
Have you tried maybe sudo depmod -a ? Might fix those module loading issues which could be your problem.
Running lsmod after boot shows that all the modules have loaded. I still get these errors on fully working installs for some reason.
Code:
uname -a
will reveal to you that you are in fact running 2.6.36.4 and not 2.6.39.4 which is jhintas kernel
Proof that I did install Jhinta's kernel:
Results of uname -a:
Look closer
Proof that you did not install Jhinta's kernel:
lilstevie said:
uname -a will reveal to you that you are in fact running ----> 2.6.36.4 <---- and not 2.6.39.4 which is jhintas kernel
Click to expand...
Click to collapse
Results of uname -a:
I've integrated GNU/Linux Debian with Android in a way I've not seen anyone done before. By running Android in a chroot environment below a GNU/Linux Debian installation, I've got the best of both worlds.
This solution is primary intended for the experienced GNU/Linux hacker or app developer wanting full control over the Android device using a standard GNU/Linux environment.
For the novice wanting to run GNU/Linux for the fun of it, there are other less powerful solutions I'd recommend before this one.
A detailed HOWTO at http://whiteboard.ping.se/Android/Debian
Features
Full GNU/Linux Debian (or Debian based such as Ubuntu) installation with lots of apt-get:able packages
Full control of the Android environment from Debian
Simultaneous use of Debian as well as Android
Access the Android file system from your workstation desktop via ssh/sftp
No need to unmount/remount the SDcard accessing it via ssh/sftp
Android system untouched and unaware of any modifications
Android root file system no longer volatile, edits are kept between reboots
Critical file systems kept on SDcard for easy access in case of major f**k up
Graphic X11 Windows user interface, both client and server, local and remote, native, over SSH or VNC
Manage your Android device as any other GNU/Linux system
Architecture
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Running X11 with Gnome via VNC on the ASUS Transformer
Interesting work. Does the Android environment take much of a performance hit running under debian?
fluxist
fluxist said:
Interesting work. Does the Android environment take much of a performance hit running under debian?
Click to expand...
Click to collapse
No performance impact. Running in chroot does not impair the performance, but the boot may take a second or two longer with the extra init scripts. If you move the /system and/or /data partition(s) to the sdcard, the speed of the memory card may affect the performance, but benchmarking a class 10 card and you'll get about the same disk-I/O performance as using the internal nand partitions, take or give. My tests revealed some operations actually was faster to the sdcard compared to the nand - but other slower (e.g. random vs sequential, large blocks vs small etc). Myself I moved /system to the sdcard for safety and /data for more app space, increasing it from 400MB to 4GB on my Xperia. . Only keep in mind Android doesn't like more than four partitions on the sdcard in total.
The ssh server will of course consume some ram (less than 1MB rss for openssh-server, ~300kB for dropbear), but the ease of removing bloatware in this setup more than makes up for this, resulting in a faster phone than before.
Great job man.
Just 3 questions :
1) What's the difference with this project ? Linux on Android Project
2) Your solution has Audio and GPU Acceleration ?
3) Are you planning a "really easy noob-aware stupid-free ONE CLICK" Tool ?
Thanks !
TheMac
themac said:
Great job man.
Just 3 questions :
1) What's the difference with this project ? Linux on Android Project
Click to expand...
Click to collapse
The difference is who's on top. In my solution, the Debian/Ubuntu is on top, owning the Android installation. This way you can use Debian/Ubuntu to access, manage, change anything in the Android world, and the Android world don't even need to be aware of Debian/Ubuntu, and does not need to be rooted or anything. E.g. you can edit the init.rc file from Debian/Ubuntu, save it as any ordinary file, and the next time Android boots, it's still there, your changes included. Or remove bloat-ware, or get file access via ssh/sftp to the entire file system, etc. This is not possible using the other solutions.
themac said:
2) Your solution has Audio and GPU Acceleration ?
Click to expand...
Click to collapse
No. Yes. Well, no. All (local) access to the Debian/Ubuntu uses Android as a front end, and Android still owns all the devices (screen, input methods, audio device etc). If you've got a remote terminal access supporting sound, sure. But I don't think VNC does. I'll answer "no" on this question.
themac said:
3) Are you planning a "really easy noob-aware stupid-free ONE CLICK" Tool ?
Click to expand...
Click to collapse
I don't know if I would be doing the world a favour doing this. Today it requires knowledge in GNU/Linux to install, and a user without knowledge enough can do lots of damage really quick, because of the power to make changes in the Android environment this solution gives. The installation complexity is kind of a safe-guard, I'd say.
Also I find this solution more suitable for the hacker wanting control of his Android, not the person only wants to run GNU/Linux. If all you want to do is run Debian/Ubuntu, I guess the Android-on-top-solution is better. More safe, anyhow.
Since the installation requires a new boot image, it would look more like a custom ROM than a OneClick App anyway. Different images for different phones etc.
themac said:
Thanks !
TheMac
Click to expand...
Click to collapse
You're welcome!
tl;dr
This GNU/Linux integration is:
Good for the GNU/Linux hacker wanting full control of his Android device.
Bad for the mortal user wanting to run GNU/Linux just for fun.
Enviado desde mi GT-N7000 usando Tapatalk 2
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Took me a while to get the proper hardware-specific configuration, but I was able to do it. ^_^
I had to use some of the info here (http://forum.xda-developers.com/showthread.php?t=1516051) - reason: "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
To turn on framebuffer logging (where you see the kernel text scrolling by during initial boot) add this to the kernel cmdline:
console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8
(from http://forum.xda-developers.com/showthread.php?t=829817)
Here's my command line after re-gzipping the modified initramfs:
./mkbootimg-sg2x --kernel boot.img-kernel --ramdisk ramdisk.gz --cmdline "console=tty0,115200 fbcon=rotate:0 fbcon=font:VGA8x16 androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img.new --base 0x40400000 --pagesize 2048
--Weasel5i2
weasel5i2 said:
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Click to expand...
Click to collapse
Neat! Added it the the list of verified devices, linking your post.
Yes, baseaddress and command line parameters can be a bit tricky, but they all are included in the boot.img. Myself I wrote a small hack to reverse the doings of mkbootimg.
$ ./unmkbootimg boot.img
Kernel size 2419636
Kernel address 0x20008000
Ramdisk size 152656
Ramdisk address 0x21000000
Secondary size 0
Secondary address 0x20f00000
Kernel tags address 0x20000100
Flash page size 2048
Board name is ""
Command line "no_console_suspend=1"
Extracting kernel.gz ...
Extracting initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbooting --kernel kernel.gz --ramdisk initramfs.cpio.gz --base 0x20000000 --cmdline 'no_console_suspend=1' -o new_boot.img
---------------
Click to expand...
Click to collapse
This tool can be found in this thread.
weasel5i2 said:
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Took me a while to get the proper hardware-specific configuration, but I was able to do it. ^_^
I had to use some of the info here (http://forum.xda-developers.com/showthread.php?t=1516051) - reason: "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
To turn on framebuffer logging (where you see the kernel text scrolling by during initial boot) add this to the kernel cmdline:
console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8
(from http://forum.xda-developers.com/showthread.php?t=829817)
Here's my command line after re-gzipping the modified initramfs:
./mkbootimg-sg2x --kernel boot.img-kernel --ramdisk ramdisk.gz --cmdline "console=tty0,115200 fbcon=rotate:0 fbcon=font:VGA8x16 androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img.new --base 0x40400000 --pagesize 2048
--Weasel5i2
Click to expand...
Click to collapse
I also follow the same thread default ramdisk offset 0x01000000 while our phone needs 0x01400000.
But I'd like to know where or how to set ramdisk offset( to 0x01400000). Is it hard coded some where?.
And how could we know that each hardware requires different ramdisk offset.
basha.ram said:
I also follow the same thread default ramdisk offset 0x01000000 while our phone needs 0x01400000.
But I'd like to know where or how to set ramdisk offset( to 0x01400000). Is it hard coded some where?.
And how could we know that each hardware requires different ramdisk offset.
Click to expand...
Click to collapse
"base" is the address of the beginning of ram memory your device's board is using, i.e. the hardware design. By supplying this information to mkbootimg, it knows how to layout and where to load the kernel, root ramdisk etc.
I've written quite a lot about how to find out this address, including a tool extrating it from your original boot.img
http://whiteboard.ping.se/Android/Debian#base
http://whiteboard.ping.se/Android/Unmkbootimg
kuisma said:
"base" is the address of the beginning of ram memory your device's board is using, i.e. the hardware design. By supplying this information to mkbootimg, it knows how to layout and where to load the kernel, root ramdisk etc.
I've written quite a lot about how to find out this address, including a tool extrating it from you original boot.img
http://whiteboard.ping.se/Android/Debian#base
http://whiteboard.ping.se/Android/Unmkbootimg
Click to expand...
Click to collapse
Okay, reboot loop
steps:
1. Obtain base address from unmkbootimg
2. repack with mkbootimg
Code:
./mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-boot --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o newBoot.img --base 0x40400000
3. make a tar of new boot img
4. flash via ODIN -> successful
5. device restart-> reboot in a loop.
No Idea what went wrong.. can't even dump logs
basha.ram said:
Okay, reboot loop
steps:
1. Obtain base address from unmkbootimg
2. repack with mkbootimg
Code:
./mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-boot --cmdline "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o newBoot.img --base 0x40400000
3. make a tar of new boot img
4. flash via ODIN -> successful
5. device restart-> reboot in a loop.
No Idea what went wrong.. can't even dump logs
Click to expand...
Click to collapse
You get a boot loop when init terminates. The easiest way to see why, is to follow weasel5i2s example and enable frambuffer logging.
Also look for the file /android/log/boot.log at the SDcard and see if you have any clue there. If this file is non-existent, init terminated before stage two was launched.
As a last resort, after double checking all mount points, execute access (see "Common mistakes" in my HOWTO), and if you are not able to enable logging, you can clock the time it takes for the device to reboot. Then insert a "busybox sleep 30" in the init script and see if the boot loops take 30s longer time. If so, you know everything worked well up to this point, and you can move the sleep forward etc, until you've isolated exactly where it fails.
kuisma said:
You get a boot loop when init terminates. The easiest way to see why, is to follow weasel5i2s example and enable frambuffer logging.
Also look for the file /android/log/boot.log at the SDcard and see if you have any clue there. If this file is non-existent, init terminated before stage two was launched.
As a last resort, after double checking all mount points, execute access (see "Common mistakes" in my HOWTO), and if you are not able to enable logging, you can clock the time it takes for the device to reboot. Then insert a "busybox sleep 30" in the init script and see if the boot loops take 30s longer time. If so, you know everything worked well up to this point, and you can move the sleep forward etc, until you've isolated exactly where it fails.
Click to expand...
Click to collapse
I see in weasel5i2 post using customized version of mkbootimg ( mkbootimg-sg2x ) and reason stated as "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
how do we find that phone needs 0x01400000 as ramdisk offset.
---------- Post added at 04:40 PM ---------- Previous post was at 04:29 PM ----------
weasel5i2 said:
Confirmed working on a T-Mobile variant Samsung Galaxy S II (SGH-T989)!!
Took me a while to get the proper hardware-specific configuration, but I was able to do it. ^_^
I had to use some of the info here (http://forum.xda-developers.com/showthread.php?t=1516051) - reason: "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
To turn on framebuffer logging (where you see the kernel text scrolling by during initial boot) add this to the kernel cmdline:
console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8
(from http://forum.xda-developers.com/showthread.php?t=829817)
Here's my command line after re-gzipping the modified initramfs:
./mkbootimg-sg2x --kernel boot.img-kernel --ramdisk ramdisk.gz --cmdline "console=tty0,115200 fbcon=rotate:0 fbcon=font:VGA8x16 androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4" -o boot.img.new --base 0x40400000 --pagesize 2048
--Weasel5i2
Click to expand...
Click to collapse
Could you please post your .config file enabled with framebuffer logging.. I followed the link in your post but I still see a back screen.
basha.ram said:
I see in weasel5i2 post using customized version of mkbootimg ( mkbootimg-sg2x ) and reason stated as "the default ramdisk offset is 0x01000000 while our phone needs 0x01400000."
how do we find that phone needs 0x01400000 as ramdisk offset.
Click to expand...
Click to collapse
Ah, you used the vanilla mkbootimg? Let's just take weasel5i2's word for it, ok?
In mkbootimg.c you'll find a line;
hdr.ramdisk_addr = base + 0x01000000;
Click to expand...
Click to collapse
Change it to
hdr.ramdisk_addr = base + 0x01400000;
Click to expand...
Click to collapse
... compile, and you've got weasel5i2's customised mkbootimg-sg2x.
kuisma said:
Ah, you used the vanilla mkbootimg? Let's just take weasel5i2's word for it, ok?
In mkbootimg.c you'll find a line;
Change it to
... compile, and you've got weasel5i2's customised mkbootimg-sg2x.
Click to expand...
Click to collapse
Thanks again,
That did the trick, my phone is up and running with custom-built kernel but the ramdisk offset value as 0x01400000 still remains a question?. I've no idea why or on what basis I need to change ramdisk offset.
Do you have any idea on how to find the correct offset value for individual phones.. in fact it was stated under weasel5i2's post which is pointing to anther post in xda.
basha.ram said:
Thanks again,
That did the trick, my phone is up and running with custom-built kernel but the ramdisk offset value as 0x01400000 still remains a question?. I've no idea why or on what basis I need to change ramdisk offset.
Click to expand...
Click to collapse
Great work!
The base supplied to mkbootimg is the address the devices RAM begin. mkbootimg uses this calculating the addresses of the atag area, the kernel image, the ramdisk space, etc. If a manufacturer puts too much goodies into their kernel, it will be too big to fit in the space mkbootimg assigns it by default, hence the need for Samsung here to increase the offset of the ramdisk (as it follows the kernel space).
basha.ram said:
Do you have any idea on how to find the correct offset value for individual phones.. in fact it was stated under weasel5i2's post which is pointing to anther post in xda.
Click to expand...
Click to collapse
Again, use my unmkbootimg on your original boot.img. It will list the individual offsets of the kernel, ramfs etc. Then calculate backwards by subtracting the offsets mkbootimg.c uses. In the Samsung case, you'll notice they don't add up - i.e. subtracting the ramdisk offset from the listed ramdisk address does not give you the same base address as if you would subtract the kernel offset from the kernel address of the same image. Hence you can conclude Samsung must have adjusted the offsets, and with how much.
Maybe I should add support in unmkbootimg for this, doing those calculations for you and issue a warning if a non-standard mkbootimg was and must be used. Send me a link where I can get your original boot.img, and I have something to test it with, when and if I'll decide to do this.
Have you looked at the "Linux on Android!" project: http://forum.xda-developers.com/showthread.php?t=1299962
He, theGanymedes , recompiled libs such as glibc and others to run from within android itself, including apt, Bash, NCurses Library, Readline Library, etc all to run the full versions cross-compiled for android, well arm anyway.
He even was able to utilize the framebuffer directly for enlightenment(17) window manager. No VNC.
With this in mind, I was wondering if it would be possible to blend together that idea and your idea, whereas the android part would just utilize the libs found in the debian part of your project. Eventually merging the two. Prior to the merge it would facilitate smaller ROMs as they would be sharing libs, apps, etc. And the android portion would get access to full blown applications and libs, not to mention apt.
This just seems like the next logical step, at the very least it would allow you to remove the vnc dependency, and draw directly to the FB.
-I take no credit for the "Linux on Android!" project, hell, I take no credit period.
ggolemg said:
Have you looked at the "Linux on Android!" project: http://forum.xda-developers.com/showthread.php?t=1299962
He, theGanymedes , recompiled libs such as glibc and others to run from within android itself, including apt, Bash, NCurses Library, Readline Library, etc all to run the full versions cross-compiled for android, well arm anyway.
[...]
Click to expand...
Click to collapse
Been there, done that. I started out compiling libc (uClibc) for Android, but running two different libc in the same root causes a big mess. The directory structures clashes, requiring either a rewrite of the libc moving e.g. /etc to /usr/etc and so, or the use of an overlay file system. And even if solved, the end result is a big mess with files who knows belonging to what, what program uses which environment etc. So when I realised I could jail the Android environment, I immediate saw how this would resolve all conflicts, creating a clean, simple and yet more powerful and usable solution.
The next project will be a GNU/Linux you can run on your non-rooted Android device, aimed to the user who believes this solution is too complicated.
kuisma said:
Great work!
The base supplied to mkbootimg is the address the devices RAM begin. mkbootimg uses this calculating the addresses of the atag area, the kernel image, the ramdisk space, etc. If a manufacturer puts too much goodies into their kernel, it will be too big to fit in the space mkbootimg assigns it by default, hence the need for Samsung here to increase the offset of the ramdisk (as it follows the kernel space).
Again, use my unmkbootimg on your original boot.img. It will list the individual offsets of the kernel, ramfs etc. Then calculate backwards by subtracting the offsets mkbootimg.c uses. In the Samsung case, you'll notice they don't add up - i.e. subtracting the ramdisk offset from the listed ramdisk address does not give you the same base address as if you would subtract the kernel offset from the kernel address of the same image. Hence you can conclude Samsung must have adjusted the offsets, and with how much.
Maybe I should add support in unmkbootimg for this, doing those calculations for you and issue a warning if a non-standard mkbootimg was and must be used. Send me a link where I can get your original boot.img, and I have something to test it with, when and if I'll decide to do this.
Click to expand...
Click to collapse
Thanks for the pointers.
I've attached stock boot.img and the output of unmkbootimg below.
Code:
Kernel size 4905092
Kernel address 0x40408000
Ramdisk size 893395
Ramdisk address 0x41800000
Secondary size 0
Secondary address 0x41300000
Kernel tags address 0x40400100
Flash page size 2048
Board name is ""
Command line "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4"
Extracting kernel.gz ...
Extracting initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbooting --kernel kernel.gz --ramdisk initramfs.cpio.gz --base 0x40400000 --cmdline 'androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4' -o new_boot.img
one more question, the output line "To recompile this image, use:...mkbooting --kernel...." is based on vanilla version?
basha.ram said:
one more question, the output line "To recompile this image, use:...mkbooting --kernel...." is based on vanilla version?
Click to expand...
Click to collapse
Yes, unmkbootimg is quite literally the inverse of the vanilla mkbootimg. If a non-standard mkbootimg is used to compile the image, the command line unmkbootimg suggests will only work using this modified mkbootimg. But I'll update unmkbootimg informing the user about this, in the case it detects odd offsets, as well as supplying the new offsets needed to modify mkbootimg.c
Hey guys
I've been working on some scripts to automate my work for quite some time now and thought, why not share it?
So that's what I'm gonna do now
For now, we have three scripts: one to build a ROM, one to compile a kernel, to make an anykernel updater zip and to set up and entire build environment on Arch and Ubuntu-based distros (2nd post). The kernel and anykernel scripts, however, are linked, which means the kernel script automatically executes the anykernel script so as soon as you compile a kernel, you get a recovery flashable zip.
A small note: These scripts were made for the LG Optimus 4x HD, but can easily be modified for any other device.
So, you may ask yourself now 'nice, but what do these script do exactly?' well, that's what I'm gonna tell you now
ROM
The ROM build script can be found HERE
This script is made for CM 11, but can be easily modded to be used with other ROMs. I will also add some more scripts to support more ROMs in the future.
In order to make it compatible with your machine and your device, we have several configurable parameters in the beginning of the script:
Code:
# Configurable parameters
ccache_dir=/home/laufersteppenwolf/ccache/CM11
ccache_log=/home/laufersteppenwolf/ccache/CM11/ccache.log
jobs_sync=30
jobs_build=20
rom=cm
rom_version=11
device_codename=p880
If you want to use a special ccache dir, you can define it using the first parameter. Same for ccache's log.
The "jobs_sync" variable defines how many jobs will be running at the same time while running "repo sync" (---> the -j value)
The "jobs_build" variable defines how many jobs will be used for the make command
"rom" defines the ROM you are trying to compile (used in the lunch command, but also for the zip upload command)
"rom_version" defines the version of the ROM. You can change it to 10.2 or any other version depending on the CM version you are compiling.
Last but not least, the devices codename. In my case it's "p880", but you can just change it to your device (mako, hammerhead, maguro,...) and the lunch as well as the upload command will be changed to your device.
About the upload, if you have a goo.im account and also configured it in your ssh_config, you can just leave it the way it is. However, if you use a different file hoster, please edit the last command to your needs
Furthermore, we have some more features. These, however, don't need to be defined inside the script, but added to the execution command.
You can execute the script with the command:
Code:
. build.sh [-h -n -r -c -ncc -d -j #]
But what do these flags do?
Code:
-h | --help
shows a help message and exits the script
Code:
-n | --nosync
skips the "repo sync" command
Code:
-r | --release
uploads the build when it's done
Code:
-c | --clean
executes "make clean" instead of "make installclean"
Code:
-ncc | --no_ccache
disables ccache
Code:
-d | --debug
shows some debug stuff (not really needed for the "normal" user )
Code:
-j #
sets a custom number of jobs for the "make" command
Example:
Code:
. build.sh -c -r
This command syncs the repos, executes "make clean" instead of "make installclean" and uploads the build to the defined file hoster as soon as the build is done.
Kernel
The kernel build script can be found HERE
This script is made for the p880 (aka x3), but can be easily modded to work with your device.
We have 2 configurable parameters in the beginning of the script:
Code:
defconfig=cyanogenmod_x3_defconfig
jobs=32
"defconfig" defines the name of your defconfig to be used
And "jobs" defines the -j value to be used for make
All modules are being copied to ./out/modules/ and the zImage is being copied to ./out/zImage. Which means no more searching for modules inside the various folders, but having everything in one place
If you take a look into the script, the created out dir is after the above command copied to "~/smb/kernel/out". This is where my network drive is mounted. Please change it to a path of your choice.
This folder now needs to have the files from the anykernel folder inside, because the anykernel build script is being executed next. What this script exactly does will be explained later.
When the anykernel updater zip is done, the script cd's back to the place it was initially executed and will then be done.
If you don't want to make an anykernel zip, just remove the commands after
Code:
find -name '*.ko' | xargs -I {} cp {} ./out/modules/
(well, maybe except for the commands that tell you the script it done )
Anykernel updater zip
Wanna know what an anykernel updater zip is?
The anykernel updater zip only replaces the actual kernel (zImage) and not the whole boot.img. This means the ramdisk stays the same, which makes the kernel compatible with every ROM and Android version.
The script and it's needed tools can be found HERE
This script creates an anykernel updater zip from a given zImage and modules. The zImage has to be in the same folder as the script itself. The modules have to be in a folder called "modules", which also should be located in the same folder as the script. In the beginning of the script, you can define the name of the zip:
Code:
zipname="WWJB_v009_anykernel.zip"
IMPORTANT:
Please make sure to edit the updater-script so it is compatible with your device! Otherwise you can (hard) brick your device!
I am not responsible for possibly bricked devices!
Another feature of the anykernel updater is, you can mod the ramdisk while flashing (repacking the boot.img). This can be done inside THIS file. By default it creates an unsecured boot image. But you can edit way, way more using this method. For an example what can be done, you might wanna take a look at THIS file
The signapk.jar and the sign keys were taken from the latest CM11 sources.
You have a question, suggestion, bug report? Please feel free to leave a reply in this thread
Many thanks go to @GermainZ and @doixanh for helping me fighting with bash
Thanks also go to Koush, for "inventing" the anykernel updater
Environment setup script
Who is bored of setting up an entire build environment for Android? I certainly am, which is why I wrote this "tiny" script
This script sets up a complete build environment, so you can directly start to repo sync a ROM after the script is done. And the best thing is, it is extremely customizable without even having to edit the script itself. All done by appending the appropriate flags to the executing command.
A further big advantage of this script is, that it is compatible with the two most common Linux distros Arch Linux and Ubuntu (also including all distros that are based on these 2, like Xubuntu, Lubuntu,....). This compatibility is achieved by detecting the distro in the beginning of the script and then using the appropriate commands (apt-get or pacman).
The script is located HERE and called "setup.sh"
To run the script, cd to the folder the script is located and enter ". setup.sh" and append all desired flags. If you need help, just append the "-h" or "--help" flag and some help will be shown.
So, you may ask yourself now "That's nice, but what the hell does this script install/set up?" and the answer is quite simple: All you need, and (if desired) even more
The "base package" includes:
Ccache
Java
GIT
All needed build tools
Python 2
The Android SDK
Furthermore, you can also choose the "extended package" by appending the flag "-e" or "--extended", which includes:
SSH
iostat
bmon
htop
geany
The dev-host commandline tool by GermainZ
udev-rules (on Arch only)
If this still isn't enough for you, you can also add your own packages. This can be done by either editing the script and entering the packages inside the quotes of the following line:
Code:
extra="" # Add here some extra packages to install
OR
by appending the flag "-s" or "--special" and then listing the packages within quotes, seperated by spaces.
Example:
Code:
. setup.sh -s "package1 package2 package3"
This script is made to perform all actions on its own, however, it will not do so by default. To have it automated, you need to append either "-a" or "--automated". The script will then install the "base package" with all default packages (such as Oracle's JDK 6).
But you can still also append the other flags, like "-e", "-s", "-j",...
Now, let's talk about Java. This script can install 3 Java versions: Oracle's JDK 6, openJDK 6 and openJDK 7. The default version is Oracle's JDK 6. You can change the version by either appending the "-j" or "--java" flag followed by the desired version (1, 2 or 3), or if the -a flag isn't triggered, the script will ask you about it.
What? You don't want to install/change java at all? No problem! Just append "--no-java" and Java will get completely skipped.
The same thing also happens to the SDK when appending "--no-sdk".
The script has been tested on (X)ubuntu 13.10 and 14.04 by @nilse and me, and on Arch Linux by @SMillerNL and me. However, I have only tested Oracle's JDK 6, no other java versions but according to the wiki pages, it should work just fine
You have suggestions, feedback, improvements? Shoot! Just let me know and I'll do my best to include it
A big thanks goes to my testers @nilse and @SMillerNL who also made some nice suggestions. But also to @GermainZ for his dev-host commandline tool
Furthermore to @eagleeyetom for giving me the idea
Thanks awesome work it will be helpfull i was looking for such thing yesterday XD you're best @laufersteppenwolf
The anykernel script doesn't work on newer devices with zImage-dtb right?
Doesn't look like it based on the script, but I've had trouble with the M8 DTB so figured I'd ask.
u saved my life thanks buddy i will try it !!!
Hi
Fits ics?
xboxfanj said:
The anykernel script doesn't work on newer devices with zImage-dtb right?
Doesn't look like it based on the script, but I've had trouble with the M8 DTB so figured I'd ask.
Click to expand...
Click to collapse
To be honest, I have no idea
I have only tested it on the 4x HD myself, but if you use all the same commands as the the ROM build process does (maybe also grab the needed files) it should work. I mean, it does exactly the same thing as when the ROM build packs the boot image, it puts the zImage and ramdisk into one file. Only anykernel does this on the device itself, rather than on your PC.
If you want, we can take a look into it together
Marília de Oliveira said:
Fits ics?
Click to expand...
Click to collapse
Sure, should work with all ROMs, just edit some stuff (like rom_version=11 to rom_version=9 when compiling CM) and it should work just fine
laufersteppenwolf said:
To be honest, I have no idea
I have only tested it on the 4x HD myself, but if you use all the same commands as the the ROM build process does (maybe also grab the needed files) it should work. I mean, it does exactly the same thing as when the ROM build packs the boot image, it puts the zImage and ramdisk into one file. Only anykernel does this on the device itself, rather than on your PC.
If you want, we can take a look into it together
Sure, should work with all ROMs, just edit some stuff (like rom_version=11 to rom_version=9 when compiling CM) and it should work just fine
Click to expand...
Click to collapse
How do I edit? Can you explain me better .. Thanks
Thanks a lot @lauferstppenwolf
Really takes the stress out of executing commands during my kernel compiles.
Marília de Oliveira said:
How do I edit? Can you explain me better .. Thanks
Click to expand...
Click to collapse
open in notepad or gedit or whatever and edit what u want
BTW does -j number of jobs should be for example "-j6" or "-j 6"?
Marília de Oliveira said:
How do I edit? Can you explain me better .. Thanks
Click to expand...
Click to collapse
It's quite simple, open the script with an editor (I personally like Geany) and edit the following lines:
Code:
ccache_dir=/home/laufersteppenwolf/ccache/CM11
ccache_log=/home/laufersteppenwolf/ccache/CM11/ccache.log
jobs_sync=30
jobs_build=20
rom=cm
rom_version=11
device_codename=p880
example:
You want to compile CM9 for the Nexus 5 (codename hammerhead) on a dual core CPU and your username (on your PC) is username:
Code:
ccache_dir=/home/[COLOR="Red"]username[/COLOR]/ccache/CM11
ccache_log=/home/[COLOR="red"]username[/COLOR]/ccache/CM11/ccache.log
jobs_sync=[COLOR="red"]5[/COLOR]
jobs_build=[COLOR="red"]3[/COLOR]
rom=cm
rom_version=[COLOR="red"]9[/COLOR]
device_codename=[COLOR="red"]hammerhead[/COLOR]
and you're already done Your script can now compile CM9 for the Nexus 5
laufersteppenwolf said:
It's quite simple, open the script with an editor (I personally like Geany) and edit the following lines:
Code:
ccache_dir=/home/laufersteppenwolf/ccache/CM11
ccache_log=/home/laufersteppenwolf/ccache/CM11/ccache.log
jobs_sync=30
jobs_build=20
rom=cm
rom_version=11
device_codename=p880
example:
You want to compile CM9 for the Nexus 5 (codename hammerhead) on a dual core CPU and your username (on your PC) is username:
Code:
ccache_dir=/home/[COLOR="Red"]username[/COLOR]/ccache/CM11
ccache_log=/home/[COLOR="red"]username[/COLOR]/ccache/CM11/ccache.log
jobs_sync=[COLOR="red"]5[/COLOR]
jobs_build=[COLOR="red"]3[/COLOR]
rom=cm
rom_version=[COLOR="red"]9[/COLOR]
device_codename=[COLOR="red"]hammerhead[/COLOR]
and you're already done Your script can now compile CM9 for the Nexus 5
Click to expand...
Click to collapse
I have done everything ... where else do I put the script?
Marília de Oliveira said:
I have done everything ... where else do I put the script?
Click to expand...
Click to collapse
just put it inside the root of your sources (the place where you have initiated the repo) and then run it using ". build.sh [flags]"
laufersteppenwolf said:
just put it inside the root of your sources (the place where you have initiated the repo) and then run it using ". build.sh [flags]"
Click to expand...
Click to collapse
Thanks ... Worked in xperia mini pro with ics :good:
gerciolisz said:
open in notepad or gedit or whatever and edit what u want
BTW does -j number of jobs should be for example "-j6" or "-j 6"?
Click to expand...
Click to collapse
Sry for the late reply, haven't seen it at all
it's "-j x", as it only listens to the things behind the actual flag
laufersteppenwolf said:
Sry for the late reply, haven't seen it at all
it's "-j x", as it only listens to the things behind the actual flag
Click to expand...
Click to collapse
thx after reading that script i know now i thought it is same like brunch/lunch -jx
Alright guys, a big update just found its way to github: a script to set up a complete build environment on Ubuntu and Arch-based distros.
If you want me to add support for another distro, please contact me either via PM or via IRC (#TeamFun or #p880-dev) and give me details on what must be changed (install command, packages, ...)
Also the kernel script got some updates, to abort the script if the kernel didn't compile and to copy the anykernel zip directly to dropbox to share it with your testers
Cheers
laufersteppenwolf said:
You want to compile CM9 for the Nexus 5 (codename hammerhead) on a dual core CPU and your username (on your PC) is username:
Code:
ccache_dir=/home/[COLOR="Red"]username[/COLOR]/ccache/CM11
ccache_log=/home/[COLOR="red"]username[/COLOR]/ccache/CM11/ccache.log
jobs_sync=[COLOR="red"]5[/COLOR]
jobs_build=[COLOR="red"]3[/COLOR]
rom=cm
rom_version=[COLOR="red"]9[/COLOR]
device_codename=[COLOR="red"]hammerhead[/COLOR]
Click to expand...
Click to collapse
couldnt you make the script universal by using $HOME?
Wow! Great job and well written... I'll be trying this on my old archserver box that I thought I would have to convert to Ubuntu because I couldn't get all the required packages configured correctly. Looking over your scripts you've touched it all!
Thanks a bunch for the scripts, especially the env-setup one. I'll test it one of these days in Manjaro.
However, env-setup/setup.sh has a small bug: after running the script in LM16 (build environment already set up) it wants to reinstall Java no matter which flag is given.
Also, it doesn't detect installed SDK for some reason.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
[SIZE="+1"]What is a Cross-Compiler?[/SIZE]
A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. Cross compiler tools are used to generate executables for embedded system or multiple platforms. It is used to compile for a platform upon which it is not feasible to do the compiling, like microcontrollers that don't support an operating system. From wikipedia
Click to expand...
Click to collapse
[SIZE="+1"]How is that connected with an Android?[/SIZE]
In order to create a native C/C++ binary for an Android, you must firstly compile the source code. Usually you can't do so on an Android itself due to lack of proper tools and environment, or hardware barriers, especially amount of RAM. This is why you should learn how to cross-compile, to create a binary on your PC, that your ARM-based Android will understand.
[SIZE="+1"]Why do I need it?[/SIZE]
You need to learn cross-compiling technique if you want to run native C/C++ programs on an Android. Actually, if you've already built your own custom ROM from AOSP sources (i.e. CyanogenMod), then you used cross-compiling tools and methods even without noticing .
Building an AOSP ROM is fairly easy, there's one command like brunch, which does the job. However, what if you want to compile a custom, not natively included binary? This is the purpose of this tutorial.
[SIZE="+1"]What I will learn from this guide?[/SIZE]
How to properly set C/C++ building environment
How to build a native C/C++ application for Android device
How to optimize native binaries for my device
[SIZE="+1"]Step 1 - The Beginning[/SIZE]
You should start from installing any Linux-based OS, I highly suggest trying a Debian-based distro (such as Ubuntu), or even Debian itself, as this tutorial is based on it .
In general, I highly suggest to compile an AOSP ROM (such as CyanogenMod) for your device firstly. This will help you to get familiar with cross-compiling on Android. I also suggest to compile one or two programs from source for your Linux, but if you're brave enough to learn cross-compiling without doing any of these, you can skip those suggestions .
[SIZE="+1"]Step 2 - Setting up[/SIZE]
Firstly you should make sure that you have all required compile tools already.
[email protected]:~# apt-get update && apt-get install checkinstall
Click to expand...
Click to collapse
This should do the trick and install all required components.
I suggest creating a new folder and navigating to it, just to avoid a mess, but you can organize everything as you wish.
Start from downloading NDK from here.
The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++.
Click to expand...
Click to collapse
[email protected]:~# wget http://dl.google.com/android/ndk/android-ndk-r9d-linux-x86_64.tar.bz2
[email protected]:~# tar xvf android-ndk-r9d-linux-x86_64.tar.bz2
[email protected]:~# mv android-ndk-r9d ndk
Click to expand...
Click to collapse
Now you should make a standalone toolchain, navigate to root of your ndk (this is important) and then build your toolchain:
[email protected]:~# cd ndk/
[email protected]:~/ndk# build/tools/make-standalone-toolchain.sh --toolchain=arm-linux-androideabi-4.8 --platform=android-18 --install-dir=/root/ndkTC
Copying prebuilt binaries...
Copying sysroot headers and libraries...
Copying libstdc++ headers and libraries...
Copying files to: /root/ndkTC
Cleaning up...
Done.
Click to expand...
Click to collapse
You should edit bolded variables to your preferences. Toolchain is the version of GCC you want to use, 4.8 is currently the newest one, in the future it may be 4.9 and so on. Platform is a target API for your programs, this is important only for android-specific commands, such as logging to logcat. When compiling a native Linux program, this won't matter (but it's a good idea to set it properly, just in case). Install dir specifies destination of your toolchain, make sure that it's other than ndk (as you can see I have ndk in /root/ndk and toolchain in /root/ndkTC).
Now you need to download my exclusive cc.sh script from here and make it executable.
[email protected]:~# wget https://dl.dropboxusercontent.com/u/23869279/Files/cc.sh
[email protected]:~# chmod 755 cc.sh
Click to expand...
Click to collapse
This script is a very handy tool written by me to make your life easier while cross-compiling. Before running it make sure to edit "BASIC" options, especially NDK paths. Apart from that it's a good idea to take a look at DEVICEFLAGS and setting them properly for your device, or clearing for generic build. You don't need to touch other ones unless you want/need them.
Just for a reference, I'll include currently editable options:
#############
### BASIC ###
#############
# Root of NDK, the one which contains $NDK/ndk-build binary
NDK="/root/ndk"
# Root of NDK toolchain, the one used in --install-dir from $NDK/build/tools/make-standalone-toolchain.sh. Make sure it contains $NDKTC/bin directory with $CROSS_COMPILE binaries
NDKTC="/root/ndkTC"
# Optional, may help NDK in some cases, should be equal to GCC version of the toolchain specified above
export NDK_TOOLCHAIN_VERSION=4.8
# This flag turns on ADVANCED section below, you should use "0" if you want easy compiling for generic targets, or "1" if you want to get best optimized results for specific targets
# In general it's strongly suggested to leave it turned on, but if you're using makefiles, which already specify optimization level and everything else, then of course you may want to turn it off
ADVANCED="1"
################
### ADVANCED ###
################
# Device CFLAGS, these should be taken from TARGET_GLOBAL_CFLAGS property of BoardCommonConfig.mk of your device, eventually leave them empty for generic non-device-optimized build
# Please notice that -march flag comes from TARGET_ARCH_VARIANT
DEVICECFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp"
# This specifies optimization level used during compilation. Usually it's a good idea to keep it on "-O2" for best results, but you may want to experiment with "-Os", "-O3" or "-Ofast"
OLEVEL="-O2"
# This specifies extra optimization flags, which are not selected by any of optimization levels chosen above
# Please notice that they're pretty EXPERIMENTAL, and if you get any compilation errors, the first step is experimenting with them or disabling them completely, you may also want to try different O level
OPTICFLAGS="-s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing"
# This specifies extra linker optimizations. Same as above, in case of problems this is second step for finding out the culprit
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections"
# This specifies additional sections to strip, for extra savings on size
STRIPFLAGS="-s -R .note -R .comment -R .gnu.version -R .gnu.version_r"
# Additional definitions, which may help some binaries to work with android
DEFFLAGS="-DNDEBUG -D__ANDROID__"
##############
### EXPERT ###
##############
# This specifies host (target) for makefiles. In some rare scenarios you may also try "--host=arm-linux-androideabi"
# In general you shouldn't change that, as you're compiling binaries for low-level ARM-EABI and not Android itself
CONFIGANDROID="--host=arm-linux-eabi"
# This specifies the CROSS_COMPILE variable, again, in some rare scenarios you may also try "arm-eabi-"
# But beware, NDK doesn't even offer anything apart from arm-linux-androideabi one, however custom toolchains such as Linaro offer arm-eabi as well
CROSS_COMPILE="arm-linux-androideabi-"
# This specifies if we should also override our native toolchain in the PATH in addition to overriding makefile commands such as CC
# You should NOT enable it, unless your makefile calls "gcc" instead of "$CC" and you want to point "gcc" (and similar) to NDKTC
# However, in such case, you should either fix makefile yourself or not use it at all
# You've been warned, this is not a good idea
TCOVERRIDE="0"
# Workaround for some broken compilers with malloc problems (undefined reference to rpl_malloc and similar errors during compiling), don't uncomment unless you need it
#export ac_cv_func_malloc_0_nonnull=yes
Click to expand...
Click to collapse
As you can notice, my magic script already contains bunch of optimizations, especially device-based optimizations, which are the most important. Now it's the time to run our script, but in current shell and not a new one.
[email protected]:~# source cc.sh
Done setting your environment
CFLAGS: -O2 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp -s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing -DNDEBUG -D__ANDROID__
LDFLAGS: -Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections
CC points to arm-linux-androideabi-gcc and this points to /root/ndkTC/bin/arm-linux-androideabi-gcc
Use "$CC" command for calling gcc and "$CCC" command for calling our optimized CC
Use "$CXX" command for calling g++ and "$CCXX" for calling our optimized CXX
Use "$STRIP" command for calling strip and "$SSTRIP" command for calling our optimized STRIP
Example: "$CCC myprogram.c -o mybinary && $SSTRIP mybinary "
When using makefiles with configure options, always use "./configure $CONFIGANDROID" instead of using "./configure" itself
Please notice that makefiles may, or may not, borrow our CFLAGS and LFLAGS, so I suggest to double-check them and eventually append them to makefile itself
Pro tip: Makefiles with configure options always borrow CC, CFLAGS and LDFLAGS, so if you're using ./configure, probably you don't need to do anything else
Click to expand...
Click to collapse
Command "source cc.sh" executes cc.sh and "shares" the environment, which means that any exports will be exported to our current shell, and this is what we want. It acts the same as AOSP's ". build/envsetup.sh", so you can also use . instead of source.
As you can see above, my script should let you know if it properly set everything, especially if $CC points to our ndkTC. It also set a generic "$CCC" and "$CCXX" commands, which are optimized versions of standard $CC. $CC points to our cross-compiler, $CCC points to our cross-compiler and also includes our optimization flags.
[email protected]:~# echo $CC
arm-linux-androideabi-gcc
[email protected]:~# echo $CCC
arm-linux-androideabi-gcc -O2 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp -s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing -DNDEBUG -D__ANDROID__ -Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections
Click to expand...
Click to collapse
[SIZE="+1"]Step 3 - Cross-Compiling[/SIZE]
Now we'll compile our first program for Android!
Create a new file hello.c, and put inside:
Code:
#include <stdio.h>
int main (void)
{
puts ("Hello World!");
return 0;
}
Now you compile and strip it:
[email protected]:~# $CCC hello.c -o hello && $SSTRIP hello
Click to expand...
Click to collapse
Remember that $CCC and $SSTRIP command will only work if you source'd cc.sh script explained above. $CCC command compiles source code to a binary with already optimized flags (device flags, optimization level, optimization flags, linker flags), while $SSTRIP command strips "bloat" from output binary, such as comments and notices. The purpose is to make a binary smaller and faster.
You can check if your binary has been compiled properly through readelf command.
[email protected]:~# readelf -A hello
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM v7"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
Click to expand...
Click to collapse
As you can see, I've compiled a binary optimized for ARM v7, with THUMB-2 instructions and NEON support. How nice! Is it because of device-specific flags? Let's check what happens if we use $CC instead of $CCC:
[email protected]:~# readelf -A hello2
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Speed
Tag_DIV_use: Not allowed
Click to expand...
Click to collapse
As you can see, if you do not specify flags, you'll lose major portion of optimizations. Of course binary will work properly, hence it has been cross-compiled for ARM, but we can always make it smaller and faster!
[SIZE="+1"]Step 4 - Testing[/SIZE]
A favourite part of everything, tests!
[email protected]:~/shared# adb shell
[email protected]:/ # sysrw
[email protected]:/ # exit
[email protected]:~/shared# adb push hello /system/bin/hello
95 KB/s (5124 bytes in 0.052s)
[email protected]:~/shared# adb shell
[email protected]:/ # chmod 755 /system/bin/hello
[email protected]:/ # chown root:system /system/bin/hello
[email protected]:/ # exit
Click to expand...
Click to collapse
In above example I pushed my binary straight to /system/bin directory, which is in the Android's PATH. If you don't have rooted device that's not a problem, you can use /data/local directory or /storage/sdcard0. You can also upload your binary anywhere you want and download it as any other file, then run from /storage/sdcard0/Download, this way doesn't require even working ADB . Just don't forget about setting proper permissions afterwards!
Now let's try to run it!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If your binary is not in the PATH, you should write full path to your binary of course. As I pushed my binary to /system/bin, I don't need to do so.
If everything finished successfully and you got your very first Hello World response as above, congratulations. You've just compiled and ran your first native C/C++ program on Android device.
[SIZE="+1"]What to do next?[/SIZE]
In theory, you can now compile anything you want. Here are some apps that I'm using in my ArchiDroid ROM:
Pixelserv
Haveged
Dnsmasq
DNRD
Rinetd
These are only a few examples. You can compile anything you want, or even write your own native applications. Good luck!
JustArchi said:
[SIZE=+1]What is a Cross-Compiler?[/SIZE]
[SIZE=+1]How is that connected with an Android?[/SIZE]
In order to create a native C/C++ binary for an Android, you must firstly compile the source code. Usually you can't do so on an Android itself due to lack of proper tools and environment, or hardware barriers, especially amount of RAM. This is why you should learn how to cross-compile, to create a binary on your PC, that your ARM-based Android will understand.
[SIZE=+1]Why do I need it?[/SIZE]
You need to learn cross-compiling technique if you want to run native C/C++ programs on an Android. Actually, if you've already built your own custom ROM from AOSP sources (i.e. CyanogenMod), then you used cross-compiling tools and methods even without noticing .
Building an AOSP ROM is fairly easy, there's one command like brunch, which does the job. However, what if you want to compile a custom, not natively included binary? This is the purpose of this tutorial.
[SIZE=+1]What I will learn from this guide?[/SIZE]
How to properly set C/C++ building environment
How to build a native C/C++ application for Android device
How to optimize native binaries for my device
[SIZE=+1]Step 1 - The Beginning[/SIZE]
You should start from installing any Linux-based OS, I highly suggest trying a Debian-based distro (such as Ubuntu), or even Debian itself, as this tutorial is based on it .
In general, I highly suggest to compile an AOSP ROM (such as CyanogenMod) for your device firstly. This will help you to get familiar with cross-compiling on Android. I also suggest to compile one or two programs from source for your Linux, but if you're brave enough to learn cross-compiling without doing any of these, you can skip those suggestions .
[SIZE=+1]Step 2 - Setting up[/SIZE]
Firstly you should make sure that you have all required compile tools already.
This should do the trick and install all required components.
I suggest creating a new folder and navigating to it, just to avoid a mess, but you can organize everything as you wish.
Start from downloading NDK from here.
Now you should make a standalone toolchain, navigate to root of your ndk (this is important) and then build your toolchain:
You should edit bolded variables to your preferences. Toolchain is the version of GCC you want to use, 4.8 is currently the newest one, in the future it may be 4.9 and so on. Platform is a target API for your programs, this is important only for android-specific commands, such as logging to logcat. When compiling a native Linux program, this won't matter (but it's a good idea to set it properly, just in case). Install dir specifies destination of your toolchain, make sure that it's other than ndk (as you can see I have ndk in /root/ndk and toolchain in /root/ndkTC).
Now you need to download my exclusive cc.sh script from here and make it executable.
This script is a very handy tool written by me to make your life easier while cross-compiling. Before running it make sure to edit "BASIC" options, especially NDK paths. Apart from that it's a good idea to take a look at DEVICEFLAGS and setting them properly for your device, or clearing for generic build. You don't need to touch other ones unless you want/need them.
Just for a reference, I'll include currently editable options:
As you can notice, my magic script already contains bunch of optimizations, especially device-based optimizations, which are the most important. Now it's the time to run our script, but in current shell and not a new one.
Command "source cc.sh" executes cc.sh and "shares" the environment, which means that any exports will be exported to our current shell, and this is what we want. It acts the same as AOSP's ". build/envsetup.sh", so you can also use . instead of source.
As you can see above, my script should let you know if it properly set everything, especially if $CC points to our ndkTC. It also set a generic "$CCC" and "$CCXX" commands, which are optimized versions of standard $CC. $CC points to our cross-compiler, $CCC points to our cross-compiler and also includes our optimization flags.
[SIZE=+1]Step 3 - Cross-Compiling[/SIZE]
Now we'll compile our first program for Android!
Create a new file hello.c, and put inside:
Code:
#include <stdio.h>
int main (void)
{
puts ("Hello World!");
return 0;
}
Now you compile and strip it:
Remember that $CCC and $SSTRIP command will only work if you source'd cc.sh script explained above. $CCC command compiles source code to a binary with already optimized flags (device flags, optimization level, optimization flags, linker flags), while $SSTRIP command strips "bloat" from output binary, such as comments and notices. The purpose is to make a binary smaller and faster.
You can check if your binary has been compiled properly through readelf command.
As you can see, I've compiled a binary optimized for ARM v7, with THUMB-2 instructions and NEON support. How nice! Is it because of device-specific flags? Let's check what happens if we use $CC instead of $CCC:
As you can see, if you do not specify flags, you'll lose major portion of optimizations. Of course binary will work properly, hence it has been cross-compiled for ARM, but we can always make it smaller and faster!
[SIZE=+1]Step 4 - Testing[/SIZE]
A favourite part of everything, tests!
In above example I pushed my binary straight to /system/bin directory, which is in the Android's PATH. If you don't have rooted device that's not a problem, you can use /data/local directory or /storage/sdcard0. You can also upload your binary anywhere you want and download it as any other file, then run from /storage/sdcard0/Download, this way doesn't require even working ADB . Just don't forget about setting proper permissions afterwards!
Now let's try to run it!
If your binary is not in the PATH, you should write full path to your binary of course. As I pushed my binary to /system/bin, I don't need to do so.
If everything finished successfully and you got your very first Hello World response as above, congratulations. You've just compiled and ran your first native C/C++ program on Android device.
[SIZE=+1]What to do next?[/SIZE]
In theory, you can now compile anything you want. Here are some apps that I'm using in my ArchiDroid ROM:
Pixelserv
Haveged
Dnsmasq
DNRD
Rinetd
These are only a few examples. You can compile anything you want, or even write your own native applications. Good luck!
Click to expand...
Click to collapse
[Mod Edit: Please don't quote the whole OP]
Fricking awesome. Worked perfect on my builduntu running in VirtualBox
dicksteele said:
Fricking awesome. Worked perfect on my builduntu running in VirtualBox
Click to expand...
Click to collapse
I'm very glad it worked for you .
Maybe you happen to know which packages checkinstall depends on? I want to run this on Arch - pun not intended - and pacman doesn't exactly talk with debs.
(Przy okazji, świetny tutorial c: )
Dragoon Aethis said:
Maybe you happen to know which packages checkinstall depends on? I want to run this on Arch - pun not intended - and pacman doesn't exactly talk with debs.
(Przy okazji, świetny tutorial c: )
Click to expand...
Click to collapse
Checkinstall makes sure that you have all required packages installed. You can achieve nearly the same by installing "build-essential, gcc, g++, make", and that should be enough I guess .
Also, big kudos to @willverduzco for featuring my guide on XDA portal!
I would like to see a guide for llvm/ clang.
Sent from my GT-I9000 using xda app-developers app
maybe a bit irrelevant... but i wanted to learn how to cross compile/port a binary (for example "applypatch") for cygwin... any link to guide will be helpful
Thank You
DerRomtester said:
I would like to see a guide for llvm/ clang.
Sent from my GT-I9000 using xda app-developers app
Click to expand...
Click to collapse
When making standalone toolchain you should use clang instead of gcc. You should also study my cc.sh script and adapt to your own. After that, steps are nearly the same.
EnerJon said:
maybe a bit irrelevant... but i wanted to learn how to cross compile/port a binary (for example "applypatch") for cygwin... any link to guide will be helpful
Thank You
Click to expand...
Click to collapse
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
JustArchi said:
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
Click to expand...
Click to collapse
Actually i was making a tool for windows to generate/apply OTA for Android ROMs... i wanted to compile/port "IMGDIFF2" and "applypatch" from android sources...
EnerJon said:
Actually i was making a tool for windows to generate/apply OTA for Android ROMs... i wanted to compile/port "IMGDIFF2" and "applypatch" from android sources...
Click to expand...
Click to collapse
Then you should find your sources for IMGDIFF2 and applypatch and compile from source for Android, just like example hello.c above.
@JustArchi I saw this guide mentioned on the portal and read through it. Very interesting stuff. Great work explaining. I've got several questions, however, perhaps you can elaborate on.
My primary PC OS is Gentoo Linux (I've been using it for 10 years), in patricular ~amd64 which is the equivalent of Debian unstable. In Gentoo, all packages are compiled from the sources. I have a very up to date complete toolchain already installed and functioning properly as part of the native package installation system which uses portage for maintaining and updating.
I've already compiled CM and AOSP for my device, but I can't for the life of me understand why when setting up my build environment using either Google or CM tools several much older versions of GCC and GLIBC are installed into my source repos and used to build the ROM when the prerequisites for building the environment already require a working toolchain on the host build box?
Isn't there a way to just use the native toolchain from the host? Ideally, I'd love to free up the space used by these extra compilers and libraries for sources instead. Additionally, since my toolchain is much newer (gcc-4.8.2, glibc-2.19, etc) and optimized for my hardware than these generic prebuilt binaries, my ROM builds would compile faster and more optimized if I could use it instead.
The big question I ask is would you know what I'd have to do to setup my native environment to build Android? I'd truly love to be able to get rid of these other toolchains and free up the space on my harddrive. Any help would be greatly appreciated. TIA
JustArchi said:
When making standalone toolchain you should use clang instead of gcc. You should also study my cc.sh script and adapt to your own. After that, steps are nearly the same.
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
Click to expand...
Click to collapse
I try this. I would like to cross compile a kernel with clang. Hopefully i get it working.
Odysseus1962 said:
@JustArchi I saw this guide mentioned on the portal and read through it. Very interesting stuff. Great work explaining. I've got several questions, however, perhaps you can elaborate on.
My primary PC OS is Gentoo Linux (I've been using it for 10 years), in patricular ~amd64 which is the equivalent of Debian unstable. In Gentoo, all packages are compiled from the sources. I have a very up to date complete toolchain already installed and functioning properly as part of the native package installation system which uses portage for maintaining and updating.
I've already compiled CM and AOSP for my device, but I can't for the life of me understand why when setting up my build environment using either Google or CM tools several much older versions of GCC and GLIBC are installed into my source repos and used to build the ROM when the prerequisites for building the environment already require a working toolchain on the host build box?
Isn't there a way to just use the native toolchain from the host? Ideally, I'd love to free up the space used by these extra compilers and libraries for sources instead. Additionally, since my toolchain is much newer (gcc-4.8.2, glibc-2.19, etc) and optimized for my hardware than these generic prebuilt binaries, my ROM builds would compile faster and more optimized if I could use it instead.
The big question I ask is would you know what I'd have to do to setup my native environment to build Android? I'd truly love to be able to get rid of these other toolchains and free up the space on my harddrive. Any help would be greatly appreciated. TIA
Click to expand...
Click to collapse
You need special compiler capable of compiling for specific architecture, this is not the same as native GCC toolchain for amd64. When you're using native compiler, output is always designed for amd64 or i386, when using cross-compiler, output is always designed for ARM, or other specific architecture.
JustArchi said:
You need special compiler capable of compiling for specific architecture, this is not the same as native GCC toolchain for amd64. When you're using native compiler, output is always designed for amd64 or i386, when using cross-compiler, output is always designed for ARM, or other specific architecture.
Click to expand...
Click to collapse
Thanks for the quick response. I'm a bit disappointed, but I'm still wondering that there has to be some way for me to utilize the ARM toolchain I currently have installed to cross-compile from the sources a more updated optimized toolchain for me to build with. Unfortunately (for me), that Gentoo is more of a niche Linux distro so finding help in their forums for working with ARM is difficult. As it is, it took much effort and trial and error to setup my current configuration to build with since nearly everything on the net is geared towards Ubuntu / Debian (both of which I feel are loaded with useless cruft and dependencies for things I have never and will never use).
Anyhow thanks again for this great guide, and for your continued work here helping us all.
Ciao
Dropbox link is down
Inviato dal mio GT-I9300 utilizzando Tapatalk
Code:
#!/bin/bash
# _ _ _ _ _
# | |_ _ ___| |_ / \ _ __ ___| |__ (_)
# _ | | | | / __| __| / _ \ | '__/ __| '_ \| |
# | |_| | |_| \__ \ |_ / ___ \| | | (__| | | | |
# \___/ \__,_|___/\__/_/ \_\_| \___|_| |_|_|
#
# Copyright 2014 Łukasz "JustArchi" Domeradzki
# Contact: [email protected]
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#############
### BASIC ###
#############
# Root of NDK, the one which contains $NDK/ndk-build binary
NDK="/root/ndk"
# Root of NDK toolchain, the one used in --install-dir from $NDK/build/tools/make-standalone-toolchain.sh. Make sure it contains $NDKTC/bin directory with $CROSS_COMPILE binaries
NDKTC="/root/ndkTC"
# Optional, may help NDK in some cases, should be equal to GCC version of the toolchain specified above
export NDK_TOOLCHAIN_VERSION=4.8
# This flag turns on ADVANCED section below, you should use "0" if you want easy compiling for generic targets, or "1" if you want to get best optimized results for specific targets
# In general it's strongly suggested to leave it turned on, but if you're using makefiles, which already specify optimization level and everything else, then of course you may want to turn it off
ADVANCED="1"
################
### ADVANCED ###
################
# Device CFLAGS, these should be taken from TARGET_GLOBAL_CFLAGS property of BoardCommonConfig.mk of your device, eventually leave them empty for generic non-device-optimized build
# Please notice that -march flag comes from TARGET_ARCH_VARIANT
DEVICECFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp"
# This specifies optimization level used during compilation. Usually it's a good idea to keep it on "-O2" for best results, but you may want to experiment with "-Os", "-O3" or "-Ofast"
OLEVEL="-O2"
# This specifies extra optimization flags, which are not selected by any of optimization levels chosen above
# Please notice that they're pretty EXPERIMENTAL, and if you get any compilation errors, the first step is experimenting with them or disabling them completely, you may also want to try different O level
OPTICFLAGS="-s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing"
# This specifies extra linker optimizations. Same as above, in case of problems this is second step for finding out the culprit
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections"
# This specifies additional sections to strip, for extra savings on size
STRIPFLAGS="-s -R .note -R .comment -R .gnu.version -R .gnu.version_r"
# Additional definitions, which may help some binaries to work with android
DEFFLAGS="-DNDEBUG -D__ANDROID__"
##############
### EXPERT ###
##############
# This specifies host (target) for makefiles. In some rare scenarios you may also try "--host=arm-linux-androideabi"
# In general you shouldn't change that, as you're compiling binaries for low-level ARM-EABI and not Android itself
CONFIGANDROID="--host=arm-linux-eabi"
# This specifies the CROSS_COMPILE variable, again, in some rare scenarios you may also try "arm-eabi-"
# But beware, NDK doesn't even offer anything apart from arm-linux-androideabi one, however custom toolchains such as Linaro offer arm-eabi as well
CROSS_COMPILE="arm-linux-androideabi-"
# This specifies if we should also override our native toolchain in the PATH in addition to overriding makefile commands such as CC
# You should NOT enable it, unless your makefile calls "gcc" instead of "$CC" and you want to point "gcc" (and similar) to NDKTC
# However, in such case, you should either fix makefile yourself or not use it at all
# You've been warned, this is not a good idea
TCOVERRIDE="0"
# Workaround for some broken compilers with malloc problems (undefined reference to rpl_malloc and similar errors during compiling), don't uncomment unless you need it
#export ac_cv_func_malloc_0_nonnull=yes
############
### CORE ###
############
# You shouldn't edit anything from now on
if [ "$ADVANCED" -ne 0 ]; then # If advanced is specified, we override flags used by makefiles with our optimized ones, of course if makefile allows that
export CFLAGS="$OLEVEL $DEVICECFLAGS $OPTICFLAGS $DEFFLAGS"
export LOCAL_CFLAGS="$CFLAGS"
export CXXFLAGS="$CFLAGS" # We use same flags for CXX as well
export LOCAL_CXXFLAGS="$CXXFLAGS"
export CPPFLAGS="$CPPFLAGS" # Yes, CPP is the same as CXX, because they're both used in different makefiles/compilers, unfortunately
export LOCAL_CPPFLAGS="$CPPFLAGS"
export LDFLAGS="$LDFLAGS"
export LOCAL_LDFLAGS="$LDFLAGS"
fi
if [ ! -z "$NDK" ] && [ "$(echo $PATH | grep -qi $NDK; echo $?)" -ne 0 ]; then # If NDK doesn't exist in the path (yet), prepend it
export PATH="$NDK:$PATH"
fi
if [ ! -z "$NDKTC" ] && [ "$(echo $PATH | grep -qi $NDKTC; echo $?)" -ne 0 ]; then # If NDKTC doesn't exist in the path (yet), prepend it
export PATH="$NDKTC/bin:$PATH"
fi
export CROSS_COMPILE="$CROSS_COMPILE" # All makefiles depend on CROSS_COMPILE variable, this is important to set"
export AS=${CROSS_COMPILE}as
export AR=${CROSS_COMPILE}ar
export CC=${CROSS_COMPILE}gcc
export CXX=${CROSS_COMPILE}g++
export CPP=${CROSS_COMPILE}cpp
export LD=${CROSS_COMPILE}ld
export NM=${CROSS_COMPILE}nm
export OBJCOPY=${CROSS_COMPILE}objcopy
export OBJDUMP=${CROSS_COMPILE}objdump
export READELF=${CROSS_COMPILE}readelf
export RANLIB=${CROSS_COMPILE}ranlib
export SIZE=${CROSS_COMPILE}size
export STRINGS=${CROSS_COMPILE}strings
export STRIP=${CROSS_COMPILE}strip
if [ "$TCOVERRIDE" -eq 1 ]; then # This is not a a good idea...
alias as="$AS"
alias ar="$AR"
alias gcc="$CC"
alias g++="$CXX"
alias cpp="$CPP"
alias ld="$LD"
alias nm="$NM"
alias objcopy="$OBJCOPY"
alias objdump="$OBJDUMP"
alias readelf="$READELF"
alias ranlib="$RANLIB"
alias size="$SIZE"
alias strings="$STRINGS"
alias strip="$STRIP"
fi
export CONFIGANDROID="$CONFIGANDROID"
export CCC="$CC $CFLAGS $LDFLAGS"
export CXX="$CXX $CXXFLAGS $LDFLAGS"
export SSTRIP="$STRIP $STRIPFLAGS"
echo "Done setting your environment"
echo
echo "CFLAGS: $CFLAGS"
echo "LDFLAGS: $LDFLAGS"
echo "CC points to $CC and this points to $(which "$CC")"
echo
echo "Use \"\$CC\" command for calling gcc and \"\$CCC\" command for calling our optimized CC"
echo "Use \"\$CXX\" command for calling g++ and \"\$CCXX\" for calling our optimized CXX"
echo "Use \"\$STRIP\" command for calling strip and \"\$SSTRIP\" command for calling our optimized STRIP"
echo
echo "Example: \"\$CCC myprogram.c -o mybinary && \$SSTRIP mybinary \""
echo
echo "When using makefiles with configure options, always use \"./configure \$CONFIGANDROID\" instead of using \"./configure\" itself"
echo "Please notice that makefiles may, or may not, borrow our CFLAGS and LFLAGS, so I suggest to double-check them and eventually append them to makefile itself"
echo "Pro tip: Makefiles with configure options always borrow CC, CFLAGS and LDFLAGS, so if you're using ./configure, probably you don't need to do anything else"
Temporary replacement for cc.sh, as dropbox will be up soon.
Hi!
Great info.
To cross compile some packages with autotools (./configure; make; make install) it's needed to export the SYSROOT path ($ndkTC/sysroot) and include the option --sysroot=$SYSROOT on CFLAGS. Some need too --with-sysroot=$SYSROOT as configure option. This way the configure script and linker can find the libraries.
If i'm building a library that must be used as dependence to other program I use to include --static to build a static library and --prefix=$SYSROOT/usr on configure options to install the lib on toolchain sysroot folder...
Thanks.
sfortier said:
Hi!
Great info.
To cross compile some packages with autotools (./configure; make; make install) it's needed to export the SYSROOT path ($ndkTC/sysroot) and include the option --sysroot=$SYSROOT on CFLAGS. Some need too --with-sysroot=$SYSROOT as configure option. This way the configure script and linker can find the libraries.
If i'm building a library that must be used as dependence to other program I use to include --static to build a static library and --prefix=$SYSROOT/usr on configure options to install the lib on toolchain sysroot folder...
Thanks.
Click to expand...
Click to collapse
Hey.
Nice to know, I'll update my script with that. Thanks!
My last attempt to cross compile something was qemu (i'm was thinking on run windows on my tablet... )
I needed to build glib, pixmap, libpng, zlib, libjpeg-turbo, libiconv, libffi, libintl. Now I have my toolchain with all these usefull static (I prefer static libs to simplify binary installation) libs installed!
To research a way to "Run a Linux distro natively" on the Galaxy Tab3 10.1.
XDA:DevDB Information
Run a Linux distro natively, Tool/Utility for the Samsung Galaxy Tab 3 10.1
Contributors
r2d23cpo, CalcProgrammer1, moonbutt74, Angel_666
Version Information
Status: Testing
Created 2015-01-21
Last Updated 2015-02-08
reserved
Wao I wrote a nice introduction and posted on first post and after I edited the project every is gone. So I will post down here something again.
For now I will research the possibility of adapting Kexecboot to our X86 device.
Kexecboot is a program that implements a second-stage bootloader using a stripped-down Linux and the 'kexec' feature to boot into the final running Linux image.
Click to expand...
Click to collapse
Please do search in youtube for kexecboot there are a number of short videos.
h__p://kexecboot.org link not working today
Did some search for you and here are the top ones on XDA.
Kexecboot on the TF700t(TF700t-AKBI v2.6.5) by @workdowg
http://forum.xda-developers.com/showthread.php?t=2387133
[BOOT] Kexecboot / CM-Recovery by @threader
http://forum.xda-developers.com/showthread.php?t=2520663
[DEV/WIP] Kexecboot Bootloader for Galaxy Note 3 N900T - Boot Multiple Kernels by @CalcProgrammer1
http://forum.xda-developers.com/not.../dev-wip-kexecboot-bootloader-galaxy-t2864109
[BOOTLOADER]KexecBoot - A graphical kernel bootloader[Ver: 14Nov2014] by @apapousek
http://forum.xda-developers.com/ico...ootloader-kexecboot-graphical-kernel-t2937006
Improve kexecboot
http://elinux.org/Improve_kexecboot
Now I had started to search and I think I found that Tasssadar/multirom is base in kexecboot. This could be even better, maybe we can convince @Tasssadar to help us create Multirom for the TAB3!
So here is a link to his thread
[MOD][JAN 15] MultiROM v30 [email protected]
http://forum.xda-developers.com/showthread.php?t=2011403
Hopefully the see their mention here and give us a hand by pointing us out where to start.
Step one is to get a kexec-capable kernel working. Kexecboot is just a frontend for kexec. There are two options - normal kexec and kexec-hardboot. I managed to make hardboot work with the Note 1 using some patches but haven't been successful with either on the Note 3. I don't know about this device but if it is x86 then hardboot is likely out as it has ARM-only patches. Then again, if it's x86 you may be able to use GRUB or something. Reading the GSMArena page for the Tab3 says Marvell ARM7 with PowerVR though. In that case you can forget GPU acceleration ever being an option as right now there is no X11/Mesa capable PowerVR driver nor is there a development effort for one.
@CalcProgrammer1 and others
I do really appreciate your comments. Please forgive my ignorance in this area. I am about to say some stupiditty. jijijiji. I see you have point some concerned about " PowerVR" and "GPU acceleration". I just want to boot into Linux Distro as best at it can. Acceleration of any kind is not a priority. But if any driver limitation prevent us from displaying in a std mode then that can be a show stop.
I understood you say
Code:
Step one is to get a kexec-capable kernel working. Kexecboot is just a frontend for kexec..
1-Our Samsung Tab3 10.1 "OS Open source" is incomplete, that is why CM11 has been to slow on release. Still guys at "[SIGNUP] [DEVELOPMENT] signup sheet for aosp build team" had work hard to produce a pre-alpha.
2-Good news is that Open Source for the Kernel works fine.
So can you pointing me in the right direction. How to build this " kexec-capable kernel". I had play with kernel build and even added some missing modules to have CIFS capability. SO compiling Kernel should not be hard for me.
Clearly adding "kexec" may not bee that easy. I am hoping to see an option in the building process.
Code:
kexec is a system call that enables you to load and boot into another kernel from the currently running kernel.
I had played some what with boot.img initramfs and hacked /init to do perform similar task.
Code:
!/sbin/busybox sh
# initramfs pre-boot init script
# Mount the /proc and /sys filesystems
/sbin/busybox mount -t proc none /proc
/sbin/busybox mount -t sysfs none /sys
/sbin/busybox mount -t tmpfs none /dev
# Something (what?) needs a few cycles here
/sbin/busybox sleep 1
# Populate /dev
/sbin/busybox mdev -s
# Mount the root filesystem, second partition on micro SDcard
/sbin/busybox mount -t ext4 -o noatime,nodiratime,errors=panic /dev/mmcblk1p2 /data/local/mnt/ubuntu
# Clean up
/sbin/busybox umount /proc
/sbin/busybox umount /sys
/sbin/busybox umount /dev
# Transfer root to SDcard
[COLOR="Red"]exec[/COLOR] /sbin/busybox [COLOR="Red"]switch_root[/COLOR] /data/local/mnt/ubuntu /etc/init.stage1]
This is a C& P from =>
As you see I take the second partition in External SDCARD "/dev/mmcblk1p2" and mounted in "/data/local/mnt/ubuntu" and transfer to a secondary init in Ubuntu with "exec switch root".
Code:
[COLOR="Red"]exec[/COLOR] /sbin/busybox [COLOR="Red"]switch_root [/COLOR]/data/local/mnt/ubuntu /etc/init.stage1
I guess this exec switch root is performing similar function as "kexec"
Can we work with this? -> Edited: I had already compile kexec in kernel.
Any help will be really really appreciated. Thanks.
@CalcProgrammer1
Ok
First step DONE!
I had compiled a new kernel with kexec. kexec stock from Kernel, just enabled. Do not know about hardboot but willing to see the patch!.
Listen Arm/mips/x86 should be the same kernel(clearly on same kernel number!). So, arm should not matter. Any way the code for kexec seems small enogth to compare with yours.
One thing I have to mention I am working with 4.2.2 since it is less molested by SELinux protection.
What is next step? Pleaseeeeeee.
@JoinTheRealms @cogano @jcfunk any kexec help or advice for these guys?
@workdowg @JoinTheRealms @cogano @jcfunk
Wao pretty nice string of mention jijiji. Do not feel obligated, but any help really appreciated.
Listen guys do not feel ignore but since @CalcProgrammer1 first approach me, I am trying to follow his work at [UTIL] Kexecboot Bootloader for Galaxy Note i717 - Boot Multiple Kernels. Still I you point me to another one I will gladly read on it.
So I build a kernel with kexec enabled! Will that maters or I need to compile one kexec from source?
Next I had downloaded your kernel_kexecboot_quincyatt_v2.zip and open the initramfs. Also compare it to your source. Looks similar. I see I need the following files:
Code:
ramdisk/bin/busybox need to veryfy my busybox compitibility but ok in general
ramdisk/bin/[COLOR="Blue"]kexecboot[/COLOR]
ramdisk/bin/[COLOR="Blue"]lvm[/COLOR]
ramdisk/bin/sh->busybox should be ok
ramdisk/bin/[COLOR="Blue"]tssrv[/COLOR]
ramdisk/sbin/kexec
ramdisk/sbin/[COLOR="Blue"]refresh[/COLOR]
ramdisk/init -> it is a sh script ok
So assuming my enabled kexec is ok for now, I also need to compiled kexecboot, lvm, tssrv, refresh but I have no source for lvm, tssrv, refresh.
Where can I get sources for: lvm, tssrv, refresh? I will check if lvm and tssrv may be part of any busybox, toolbox or recovery I have around.
Files from CalcProgrammer1 project "[UTIL] Kexecboot Bootloader for Galaxy Note i717 - Boot Multiple Kernels."
h__ps://github.com/CalcProgrammer1/kernel_quincyatt_kexec
h__ps://mega.co.nz/#F!0ct3EaTD!wHWnGo1M_2smyKdzGMIYmw
r2,
chroot to your distro and run in terminal
apt-get update
apt-get install gcc gcc-4.7
check /etc/apt/sources.list to see if you have source repositories entries, for example [in debian]
deb-src http://ftp.us.debian.org/debian/ wheezy main
your distro will vary, then
apt-cache search lvm <-----and so forth for every package you need from [src] and compile right on your tab natively
i've been doing this on arm, the end/native result should be similar. Be aware you may need to establish a repository locally for your
kernel source in case you need to generate headers for your toolchain
cd [kernel-source-$TOP]
make mrproper
make ARCH=x86 [correct_defconfig]
make ARCH=x86 headers_check
make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install
with your mount points correct for your ubuntu project you should be able to do all that via terminal.
m
r2d23cpo said:
So assuming my enabled kexec is ok for now, I also need to compiled kexecboot, lvm, tssrv, refresh but I have no source for lvm, tssrv, refresh.
Where can I get sources for: lvm, tssrv, refresh? I will check if lvm and tssrv may be part of any busybox, toolbox or recovery I have around
Click to expand...
Click to collapse
You don't need them. My sloppy work is showing lol. I took most of that from another kexecboot from the HP TouchPad. Chances are your Tab3 doesn't use LVM, though the TouchPad did so that's where that came from. You can remove it.
The tssrv binary is the userspace HP TouchPad touchscreen driver. Most tablets and phones have a kernelspace touchscreen driver, so you can just remove this (plus kexecboot isn't touch driven anyways).
Refresh was something I was testing for my Note 3, as it uses a software-refreshed panel. If your Tab3 uses a video mode panel you won't need a software refresher but if it does, well, you may run into an issue that I don't know about as refreshing seems SoC-specific and I'm only used to Qualcomm chips. Remove it for now as well.
Wao spent over 18 consecutive hours, I had to sleep. I had trouble always with this so call automatic makefile that never work!! It is simpler to create my own makefile and adjust, ad subtract commands as it show error.
So I am working. just having some programing issues that do not let me go at a better speed. See you latter friends.
IMPORTANT:
PLEASE if you downloaded the zimage I have previously gave link, DO NOT USED IT.
Yes it has KEXEC Enabled 100%. BUTTTTT, I did something wrong in the selection that prevent WIFICommunication!!! You been warned. If you had such an accident, Use Odin To reinstall a good Booot Image or a zip package using the External SDCARD. If You need help please ask. But As I said I am going to sleep now.
r2d23cpo said:
Wao I wrote a nice introduction and posted on first post and after I edited the project every is gone. So I will post down here something again.
For now I will research the possibility of adapting Kexecboot to our X86 device.
Please do search in youtube for kexecboot there are a number of short videos.
h__p://kexecboot.org link not working today
Did some search for you and here are the top ones on XDA.
Kexecboot on the TF700t(TF700t-AKBI v2.6.5) by @workdowg
http://forum.xda-developers.com/showthread.php?t=2387133
[BOOT] Kexecboot / CM-Recovery by @threader
http://forum.xda-developers.com/showthread.php?t=2520663
[DEV/WIP] Kexecboot Bootloader for Galaxy Note 3 N900T - Boot Multiple Kernels by @CalcProgrammer1
http://forum.xda-developers.com/not.../dev-wip-kexecboot-bootloader-galaxy-t2864109
[BOOTLOADER]KexecBoot - A graphical kernel bootloader[Ver: 14Nov2014] by @apapousek
http://forum.xda-developers.com/ico...ootloader-kexecboot-graphical-kernel-t2937006
Improve kexecboot
http://elinux.org/Improve_kexecboot
Now I had started to search and I think I found that Tasssadar/multirom is base in kexecboot. This could be even better, maybe we can convince @Tasssadar to help us create Multirom for the TAB3!
So here is a link to his thread
[MOD][JAN 15] MultiROM v30 [email protected]
http://forum.xda-developers.com/showthread.php?t=2011403
Hopefully the see their mention here and give us a hand by pointing us out where to start.
Click to expand...
Click to collapse
Congratulations, it´s a very useful idea and i hope it gets developed Good luck!
Good morning Folks! It is 12:07AM in the Atlantic Zone with a nice star sky.
So after 322 views and 11 replys @rjmm13 is our first non-developer that had show and post interest. Congratulations! [Applause ]
And we are ready do some more tests today.
To my friends with the right knowledge I need the full kexec instruction I will use to boot Ubuntu. From the Ubuntu manuals it seems some thing like:
Code:
kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd
For now I am using @CalcProgrammer1 work on Galaxy Note i717. init shows he mounted proc, sys & dev. I had place or should I say extracted Ubuntu in my 2nd ext4 partition on the external SdCard or partition "/dev/mmcblk1p2" So I guess my command should look like
Code:
kexec -l /boot/vmlinux --append=root=/dev/mmcblk1p2 --initrd=/boot/initrd
But I wonder, that partition is not mounted!!!! Or I am wrong.
My other Option will be to mount mmcblk1p2 in /data/local/mnt/ubuntu
Then partial code may looks like:
Code:
busybox mount -t ext4 /dev/block/mmcblk1p2 /data/local/mnt/ubuntu
kexec -l /boot/vmlinux --append=root=/data/local/mnt/ubuntu --initrd=/boot/initrd
So witch one is the good command sequence?
------------------------------------------------------------------------------
Edited.
To @moonbutt74 I have not ignored you in try to build on same TAB3 device. But If I do then I will have to worry about backing up every time I have to do test on TAB3!!
Listen I am having troubles compiling automated makefiles. So I recall your comments. And I am up to building kexec-tools with same Ubuntu deb packages. That should be pretty easy.
I have Ubuntu amd64 desktop but I will try to install i386 debs for maximum compatibility! Just as a test.
Code:
apt-get update
apt-get install kexec-tools_2.0.2-3ubuntu4_i386
Do you know if there is a way to then force my out kernel source to used Ubuntu Desktop files? I know may sound stupid.
Now regards
Code:
cd [kernel-source-$TOP]
make mrproper
make ARCH=x86 [correct_defconfig]
make ARCH=x86 headers_check
make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install
What "make mrproper" commads do?
What "correct_defconfig" do you used?
"make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install" I do not recalled doing this And I compiled it ok. What the kernel sources ask was to edit a config file and add my tool location?
Thanks body. Take your time I know you are busy in your own projects.
I am doing it again, making a full conversation my self! jijijiji
@moonbutt74 you are genius, if I run Ubuntu in a VNC server in TAB3, I can work in my PC. And walaaaaa! I am in fact running from external sdcard partition. I do not have to worry about backup!!! As always you are the man.
With the advantage that the code generated by Ubuntu should be 100% compatible with TAB310.1 x86.
In the future I do really have to look more deep in your comments.
I will test to see how it goes.
I waist 7 hours doing some needed backup, my desktop was getting low in memory. Almost lost my files due to corruption. But I am back.
So I tested leaving the tablet as Ubuntu VNC Server and works but I still think is slow. But I do not need VNC.!!! Nor the GUI.
I had recall installing "shh" previously in my Ubuntu, So I can just do Putty "shh" in Win7 and it works much better!!! In fact I can just use WinSCP also to even load or take files easily from the TAB3 Ubuntu system file. Thanks body for the Idea.
Now then I will start doing what you did a week ago, Installing inside the Tab310.1 the SDK toolchain, platform and the Kernel source just in case I need it. I know I am continue wasting more time without doing real-work on kexecboot. But if it works I will improve my developing speed in the future. I hope to report soon.
r2d23cpo said:
Code:
kexec -l /boot/vmlinux --append=root=/dev/mmcblk1p2 --initrd=/boot/initrd
But I wonder, that partition is not mounted!!!! Or I am wrong.
My other Option will be to mount mmcblk1p2 in /data/local/mnt/ubuntu
Then partial code may looks like:
What "make mrproper" commads do?
What "correct_defconfig" do you used?
"make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install" I do not recalled doing this And I compiled it ok. What the kernel sources ask was to edit a config file and add my tool location?
Thanks body. Take your time I know you are busy in your own projects.
Click to expand...
Click to collapse
1. The root= option will automatically mount that given device as the root partition (aka /). If you use root= you do not need an initramfs at all, because the kernel will mount the partition and run the /init script automatically. If you don't use a root= command or wish to run more complex boot sequences, then you will need an initramfs. In that case, the initramfs gets mounted as / and then must do its own work to mount the real root partition and do switch_root to replace the temporary initramfs root with the new proper root partition.
2. "make mrproper" is a better version of "make clean". It basically resets your entire kernel build to a clean state. Do this if you want to make sure your build is pure rather than reusing already-compiled temporary files.
3. You must create your own defconfig since you're using a new device. Use make menuconfig to edit your .config file to how you like it, then copy it to arch/<architecture>/configs/your_defconfig_name and then you will be able to use make your_defconfig_name to setup your .config file each time you want to rebuild it. I think x86 is "i386" in the tree, ARM is "arm".
4. If you're building for an x86 device on another x86 device you should just be able to make without the ARCH or CROSS_COMPILE flags. If you're using an x86_64 machine you'll want to set up a 32-bit chroot or something though if you want to build a 32-bit kernel. If you're building for ARM on an x86/amd64/anything-else-not-arm machine then you have to do ARCH=arm CROSS_COMPILER=name-of-your-arm-toolchain- so it builds it with the cross compiler.
@CalcProgrammer1
The following Is NOT a correction Nor disputing your comments. Please continue helping. If I write is to clarify what is my understanding.
I am lost in #1. I bet you are trying to explain what my options are by using "root=". Still it get me confuse. But listen what I need is the following. We has said that Kexecboot is a front end of kexec. So what I want is to test kexec first ALONE so see how it behaves. For that I need the correct kexec construction sentence to call Ububtu in the secon partiyion of the SDCARD. So I look in the kexec manual an I got what I wrote before. Now I am asking you if you know or you can look at your Kexec config file for that sentence. I hope you understand me now.
#2 is a nice explanation. I see. Thanks
#3 Open Source instruction said to use "android_santos10_open_r00_user_defconfig" But I agree with you, So what I did I use instead was "make ARCH=i386 android_santos10_open_r00_eng_defconfig" Then "make menuconfig" and went and try to enable what I needed. Basically verify the kexec was enabled, and that my CIFS was also enabled. Still I learn to copy ".config" and place it a my future config with a different name. Thanks.
#4 I tend to agree with you some what in that the x86 binary code of my Ubuntu Desktop may work in the x86 tablet. Well that is almost the case. As an example I downloaded the Open Office Ubuntu deb package for x86 desktop and then installed in the tablet. 100% working. But some of binary code compiled not always work. Yes my Ubuntu Desktop is x86 64. And I bet you that if the code gets generated for 64 bit I am not sure is it will work. Then the other factor I think is the possibility of missing libraries that Ubuntu desktop my have against Android minimal system.
Now You raise a good point, I could run a chroot Ubuntu x86 ( not 64). But then again It is simpler to have another partition and run Grub2 with Ubuntu x86 without any chroot. That is what I did normally. But I have 1.5 tetra of garbage. I am in the process of backing up, so that I can liberate HD space.
Regards "CROSS_COMPILER" jijiji yes it seems funny. But the real answer is that it is false that the process do "CROSS_COMPIling". That statement just select the toolchain to use. It does not matter if it is mips, arm or Intel. Just point to the place of the toolchain. The the output clearly is going to be the output for what the toolchain was build for.
So Can you look at your kexecboot config and tell me if the command is there.
By the way The Documentation for Kexecboot at "http://kexecboot.org" is no longer available. It seem that the site is dead. In fact many others related to kexecboot are dead too!!. So I ask you for any chance did you save that documentation? Can I have it?
Thanks body I really appreciate your
PD, I am Create a kernel in my desktop (i7 8core), but I have to mention that I did not include V8, so I guess it used 1 or 2 cores only. It took 25 minutes. I am compiling the kernel also in my Tab3. It has pass 1 hour and I guess is half way!!
But, I had 2 outages of electrical power! My Tab3 is unaffected to outages of power jijijiji. This is why I want to have Linux natively. This is weird It never happens. I guess there have to be a construction near by that require the cut of power.
hey guys,
just a quick note in reference to,
4. If you're building for an x86 device on another x86 device you should just be able to make without the ARCH or CROSS_COMPILE flags.
Click to expand...
Click to collapse
that is true if you are building/compiling natively on this tab. However if you are compiling on a pc [x86][x86_64} you do need to cross compile and pass flags.
The reason is you need to link [for some reason] with ld.gold for the binary to execute else you get the bad/incorrect/invalid magic error.
If building on pc for this tab through buildroot set arch for i386 and arch variant for i686. for building through gcc on your own makefile recipe
you will need to pass the following flags for CFLAGS , CXXFLAGS and LDFLAGS ; -m32 -static, and pass/export ARCH=x86,this goes for building on 32bit or 64bit pc.
m
moonbutt74 said:
...If building on pc for this tab through buildroot set arch for i386 and arch variant for i686. for building through gcc on your own makefile recipe you will need to pass the following flags for CFLAGS , CXXFLAGS and LDFLAGS ; -m32 -static, and pass/export ARCH=x86,this goes for building on 32bit or 64bit pc....
Click to expand...
Click to collapse
Nicessss, I was looking for that. So it does not requires the "toolchain" other that really compiling on a desire vesrion number. Did I understood correct or I need to setup toolchain some where? What about gcc on the Ubuntu?
What I do is create my own Makefile like
Code:
NDKROOT=/home/<username>/bin/androidndk
NDKSYSROOT=$(NDKROOT)/platforms/android-8/arch-x86
TOOLCHAIN := $(NDKROOT)/toolchains/x86-4.6/prebuilt/linux-x86
CC := $(TOOLCHAIN)/bin/i686-linux-android-gcc
#INCLD_DIR := $(TOOLCHAIN)/usr/include
INCLD_DIR := $(TOOLCHAIN)/include
LIB_DIR := $(TOOLCHAIN)/lib
#LIBS = -L$(LIB_DIR)
TARGET := kexecboot
#CFLAGS := -Wall
CFLAGS = -DNO_MNTENT -UHAVE_ICONV -DNO_MALLINFO=1 \
--sysroot=$(NDKSYSROOT) \
-isystem $(NDKSYSROOT) \
-I$(NDKSYSROOT)/usr/include \
-mandroid \
-D_GNU_SOURCE=1 \
-L$(NDKSYSROOT)/usr/lib
# -I$(NDKSYSROOT)/usr/include/sys \
# -I$(NDKSYSROOT)/usr/include/linux \
LDFLAGS := -L$(TOOLCHAIN)/lib -Wl,-rpath-link $(TOOLCHAIN)/lib
SRCS := $(TARGET).c util.c cfgparser.c devicescan.c evdevs.c fb.c gui.c \
menu.c xpm.c rgb.c tui.c fstype/fstype.c machine/zaurus.c
OBJS := $(TARGET).o util.o cfgparser.o devicescan.o evdevs.o fb.o gui.o \
menu.o xpm.o rgb.o tui.o fstype.o
#OBJS := util.o cfgparser.o devicescan.o evdevs.o fb.o gui.o \
# menu.o xpm.o rgb.o tui.o fstype.o zaurus.o
LIBS := -L$(LIB_DIR)
#-lutil -lpthread
$(TARGET): $(OBJS)
# $(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) $(LIBS) $(TARGET).c -o $(TARGET)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) $(LIBS) -o $(TARGET)
$(TARGET).o: $(TARGET).c $(TARGET).h
$(CC) $(CFLAGS) -c $(TARGET).c
util.o: util.c util.h
$(CC) $(CFLAGS) -c util.c
cfgparser.o: cfgparser.c cfgparser.h
$(CC) $(CFLAGS) -c cfgparser.c
devicescan.o: devicescan.c devicescan.h
$(CC) $(CFLAGS) -c devicescan.c
evdevs.o: evdevs.c evdevs.h
$(CC) $(CFLAGS) -c evdevs.c
fb.o: fb.c fb.h
$(CC) $(CFLAGS) -c fb.c
gui.o: gui.c gui.h
$(CC) $(CFLAGS) -c gui.c
menu.o: menu.c menu.h
$(CC) $(CFLAGS) -c menu.c
xpm.o: xpm.c xpm.h
$(CC) $(CFLAGS) -c xpm.c
rgb.o: rgb.c rgb.h
$(CC) $(CFLAGS) -c rgb.c
tui.o: tui.c tui.h
$(CC) $(CFLAGS) -c tui.c
fstype.o: fstype/fstype.c fstype/fstype.h
$(CC) $(CFLAGS) -c fstype/fstype.c
#zaurus.o: machine/zaurus.c machine/zaurus.h
# $(CC) $(CFLAGS) -c machine/zaurus.c
clean:
rm -f *.o *~ $(TARGET)
By the way, my Kernel Build took 2 hours on the TAB310.1. Now I need to test it.
r2,
hi,
if compiling on the tab for the tab [natively through tab's ubuntu distro], compile straight and you should be good to go.
if compiling outside the tab [host/build] for the tab [target] [cross compile], then yes you need to pass flags and such.
For my experiments when i had the tab, i first built my toolchain through the 32bit version of android ndk and geared to
jellybean api.
In my makefile the flags i included were
CFLAGS := -m32
LDFLAGS := -static <------this is/can be optional, i like static binaries for portability reasons.
on -Wall , i usually leave that on.
on -werror, i usually turn that off.
m
Wao still tryint to leave the Starting Line but one after the other. jijiji
But Good news. To strip out all problems I decided to start from scrach. And after loking at the config as it is I found that kexec was set to enable from the beguining.
hsbadr said in his thread [KERNEL] [KEXEC] Kernel EXECution for locked devices [N900V] [WIP] to check kexec by doing cat /proc/kallsyms | grep kexec
and here is the output of the system calls:
Code:
[email protected]:/ # cat /proc/kallsyms | grep kexec
00000000 t machine_kexec_page_table_set_one
00000000 t machine_kexec_free_page_tables
00000000 T machine_kexec_prepare
00000000 T machine_kexec_cleanup
00000000 T machine_kexec
00000000 T log_buf_kexec_setup
00000000 W compat_sys_kexec_load
00000000 t kexec_crash_loaded_show
00000000 t kexec_loaded_show
00000000 t kexec_crash_size_store
00000000 t kexec_crash_size_show
00000000 T kexec_should_crash
00000000 T sys_kexec_load
00000000 T crash_kexec
00000000 T kernel_kexec
00000000 d kexec_loaded_attr
00000000 d kexec_crash_loaded_attr
00000000 d kexec_crash_size_attr
00000000 d event_exit__kexec_load
00000000 d event_enter__kexec_load
00000000 d __syscall_meta__kexec_load
00000000 d kexec_mutex
00000000 d types__kexec_load
00000000 d args__kexec_load
00000000 t __event_exit__kexec_load
00000000 t __event_enter__kexec_load
00000000 t __p_syscall_meta__kexec_load
00000000 B in_crash_kexec
00000000 B kexec_crash_image
00000000 B kexec_image
[email protected]:/ #