Those who read Phoronix might already know, but Olof Johansson from kernel.org is working on official support for Samsung Galaxy S smartphone.
Most probably, for XDA, they are a bit late to the party, but it still might be fun for tinkerers who'd want to run a Linux distro (any dev still here?).
Now, I'm not an owner/user of I9000 anymore (it was broken by a child I borrowed it to, just for 24h [driven over by bike - WTF], and lies in the closet, due to the sentiment - I've learned a lot of Linux stuff with this phone and I can't part with it), but I'm moved by the fact that there will be official support. This feels so awesome that I'm sad my old brick isn't working anymore ?
I can see the place isn't as lively as I remember, but if there any of you left, then best of luck playing with it ?
Source:
https://www.phoronix.com/scan.php?page=news_item&px=Samsung-Galaxy-S-DT-Linux-4.19
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/commit/?h=for-next&id=85b40cf3a868361fed3122a503469f3be7a38b97
PS. Graphics device would still be a problem (SGX540, if I remember?). It's blobbed, so it sucks.
devloz said:
Those who read Phoronix might already know, but Olof Johansson from kernel.org is working on official support for Samsung Galaxy S smartphone.
Most probably, for XDA, they are a bit late to the party, but it still might be fun for tinkerers who'd want to run a Linux distro (any dev still here?).
Now, I'm not an owner/user of I9000 anymore (it was broken by a child I borrowed it to, just for 24h [driven over by bike - WTF], and lies in the closet, due to the sentiment - I've learned a lot of Linux stuff with this phone and I can't part with it), but I'm moved by the fact that there will be official support. This feels so awesome that I'm sad my old brick isn't working anymore
I can see the place isn't as lively as I remember, but if there any of you left, then best of luck playing with it
Source:
https://www.phoronix.com/scan.php?page=news_item&px=Samsung-Galaxy-S-DT-Linux-4.19
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/commit/?h=for-next&id=85b40cf3a868361fed3122a503469f3be7a38b97
PS. Graphics device would still be a problem (SGX540, if I remember?). It's blobbed, so it sucks.
Click to expand...
Click to collapse
Giving proper credits is very important.
Obviously, when you submit patches to the linux kernel, somebody (from the kernel's team) has to review them, and merge them if they look good.
That 'somebody' in this case is Olof Johansson. The process is called code-review.
The actual developers are PabloPL and @xc-racer99
source code: https://github.com/PabloPL/linux
further proof: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=paweł+chmiel
status: https://github.com/PabloPL/linux/wiki (this is slightly outdated, you can follow the github issues for current status)
P.S: Graphics won't be a problem as desktop environments like MATE and xfce work well even with software rendering.
Thanks for putting this up here, it's possible someone else might notice and help out There's also an associated u-boot port at https://github.com/xc-racer99/u-boot-galaxys4g/wiki
If anyone is interested, I can give instructions on how to boot a basic Debian or Arch Linux installation.
Yep, that's correct that the SGX 540 is blobbed. There's an in-kernel driver, but it's mostly a shim for the proprietary blob which implements the windowing system (surfaceflinger for Android, X for Linux). It would probably be possible to re-used the Pandaboard X window system blobs, but 3D acceleration is a ways off.
xc-racer99 said:
If anyone is interested, I can give instructions on how to boot a basic Debian or Arch Linux installation.
Click to expand...
Click to collapse
Yes, please. That would be very useful!
MYEUHD said:
Yes, please. That would be very useful!
Click to expand...
Click to collapse
Alright, here goes. This is assuming you have all data backed up to somewhere safe.
1) Clone the u-boot port from https://github.com/xc-racer99/u-boot-galaxys4g/ - the v2018.05-aries branch is probably best
Code:
git clone https://github.com/xc-racer99/u-boot-galaxys4g -b v2018.05-aries
cd u-boot-galaxys4g
2) Build u-boot:
Code:
export ARCH=arm CROSS_COMPILE=/path/to/arm/cc
make s5p_aries_defconfig
make -j6
3) The resulting u-boot.bin is the u-boot file to flash:
Code:
heimdall flash --KERNEL u-boot.bin
4) Clone the linux kernel. You can use a variety of branches - linus' branch (aka v4.19 stable), any of the ones from https://github.com/PabloPL/linux/branches - note that I recommend the for-upstream/aries-patches-v2 branch as a base and cherry-pick the commits from the other branches for peripherals you want to use
Code:
git clone https://github.com/PabloPL/linux -b for-upstream/aries-patches-v2
cd linux
5) Build linux. First, make sure that the correct debug uart is defined in the defconfig
Code:
sed -i -- 's/CONFIG_DEBUG_S3C_UART1/CONFIG_DEBUG_S3C_UART2/g' arch/arm/configs/s5pv210_defconfig
export ARCH=arm CROSS_COMPILE=/path/to/arm/cc
make s5pv210_defconfig
make
6) Create the u-boot uImage. Replace fascinate4g.dtb with galaxys.dtb if not using an SGH-T959V/SGH-T959W/SGH-T959P. Note that if not using the i9000 or one of the above models, there could be some minor incompatabilities.
Code:
cat arch/arm/boot/zImage arch/arm/boot/dts/s5pv210-fascinate4g.dtb > zImage-dtb
mkimage -A arm -T kernel -a 30008000 -e 30008000 -O linux -d zImage-dtb -C none uImage
7) Flash the u-boot boot image. This could also be placed in a different place that u-boot knows how to boot from (mmc partition 1/2, sd card partition 1/2)
Code:
heimdall flash --RECOVERY uImage
---------- Post added at 09:45 AM ---------- Previous post was at 09:26 AM ----------
Installing a Linux distro
1) Format the first partition on your SD card as a Linux-compatible filesystem (eg ext4)
2) Arch Linux
a) Download the ARMv7 multi-platform zip from https://archlinuxarm.org/about/downloads
b) Extract the ArchLinuxARM-armv7-latest.tar.gz to the first partition on your SD card
3) Debian
a) From a Debian host, install debootstrap and qemu-arm-static
Code:
# apt install qemu-arm-static debootstrap
b) Bootstrap the system
Code:
# mkdir debian_armhf_stretch
# qemu-debootstrap --arch armhf stretch debian_armhf_stretch http://deb.debian.org/debian/
c) Enter the chroot and configure it
Code:
# chroot debian_armhf_stretch
i) Set password
Code:
passwd <your new password for user root here>
ii) Install any desired packages, eg xfce4
Code:
apt install xfce4
d) Exit the chroot
Code:
exit
e) Copy the contents of debian_armhf_stretch to your SD card. Alternatively, you could have run qemu-debootstrap to setup directly on the SD card
4) Stick your SD card into your phone and boot!
Arch Linux is a minimal, non-GUI install while Debian can be customized as desired. I personally use Debian. Note that if using some things such as wifi or bluetooth, you may need some firmware and/or some of the kernel modules to be copied to their required places.
Update
The aries-patches-v2 branch doesn't have the touchscreen enabled. You'll need to merge the commits from https://github.com/PabloPL/linux/commits/for-upstream/atmel-mxt-fixes
You'll also probably want to follow the instructions in the answers in https://askubuntu.com/questions/369621/how-to-get-the-onscreen-keybord-appear-on-login to install an on-screen keyboard. Make sure when you're running the commands that you're in the debian chroot.
Do I need a serial console to enter the password and login?
Edit: I disabled the password login by following https://superuser.com/questions/969923/automatic-root-login-in-debian-8-0-console-only#970013
But still, debian doesn't boot to xfce4.
Wich dependancies is required for building with ubuntu? The command make -j6 give me 2 errors
MYEUHD said:
Do I need a serial console to enter the password and login?
Edit: I disabled the password login by following https://superuser.com/questions/969923/automatic-root-login-in-debian-8-0-console-only#970013
But still, debian doesn't boot to xfce4.
Click to expand...
Click to collapse
Shouldn't need a serial console to login, although that's how I've been doing it lately. What's the last screen you see? Is it flashing a few different ones (I think this was just when DMA was enabled, I need to check when I get the chance though) or just stuck at the lightdm screen? Come to think of it, the aries-patches-v2 branch doesn't have the touchscreen enabled, so you'll need to manually merge the patches from the branch https://github.com/PabloPL/linux/commits/for-upstream/atmel-mxt-fixes and then you'll need to enable the on-screen keyboard based on the answers in https://askubuntu.com/questions/369621/how-to-get-the-onscreen-keybord-appear-on-login
laharl_22 said:
Wich dependancies is required for building with ubuntu? The command make -j6 give me 2 errors
Click to expand...
Click to collapse
You should just need an ARM cross compiler (eg gcc-6-arm-linux-gnueabihf-base) and possibly build-essential. U-Boot does need a relatively new cross compiler IIRC so the Android GCC 4.8/4.9 based ones probably don't work.
Exactly the sames errors after installing the libs im on ubuntu 18.04 lts amd64 the error text
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h
CFG u-boot.cfg
GEN include/autoconf.mk.dep
GEN include/autoconf.mk
CHK include/config/uboot.release
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
CHK include/config.h
CFG u-boot.cfg
CHK include/generated/version_autogenerated.h
CC lib/asm-offsets.s
CC arch/arm/lib/asm-offsets.s
cc1: error: bad value (‘armv5’) for ‘-march=’ switch
cc1: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse
---------- Post added at 07:37 PM ---------- Previous post was at 06:44 PM ----------
how to fix the bad value please ?
---------- Post added at 08:18 PM ---------- Previous post was at 07:37 PM ----------
anyone can compile tested with 3 version of cross compiler always the sames error
laharl_22 said:
Exactly the sames errors after installing the libs im on ubuntu 18.04 lts amd64 the error text
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/config.h
CFG u-boot.cfg
GEN include/autoconf.mk.dep
GEN include/autoconf.mk
CHK include/config/uboot.release
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
CHK include/config.h
CFG u-boot.cfg
CHK include/generated/version_autogenerated.h
CC lib/asm-offsets.s
CC arch/arm/lib/asm-offsets.s
cc1: error: bad value (‘armv5’) for ‘-march=’ switch
cc1: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse
---------- Post added at 07:37 PM ---------- Previous post was at 06:44 PM ----------
how to fix the bad value please ?
---------- Post added at 08:18 PM ---------- Previous post was at 07:37 PM ----------
anyone can compile tested with 3 version of cross compiler always the sames error
Click to expand...
Click to collapse
Doesn't look like you've properly setup the cross compiler. Have you run
Code:
export ARCH=arm CROSS_COMPILE=</path/to/cc>
where </path/to/cc> is the arm cross compiler toolchain? Note that in my case (Debian Stretch) that is /usr/bin/arm-linux-gnueabi- note that arm-linux-gnueabi- part (including the dash) are required, so the actual gcc path would be /usr/bin/arm-linux-gnueabi-gcc
The error you're getting shows you're trying to use a x86 toolchain to build for an ARM machine.
xc-racer99 said:
Shouldn't need a serial console to login, although that's how I've been doing it lately. What's the last screen you see? Is it flashing a few different ones (I think this was just when DMA was enabled, I need to check when I get the chance though) or just stuck at the lightdm screen? Come to think of it, the aries-patches-v2 branch doesn't have the touchscreen enabled, so you'll need to manually merge the patches from the branch https://github.com/PabloPL/linux/commits/for-upstream/atmel-mxt-fixes and then you'll need to enable the on-screen keyboard based on the answers in https://askubuntu.com/questions/369621/how-to-get-the-onscreen-keybord-appear-on-login.
Click to expand...
Click to collapse
Lightdm wasn't even showing up, all I got was the same non-GUI login that you'd find in Arch.
Surprisingly, when I set autologin-guest to true in lightdm's configuration, it shows up and I can type my username and password to enter xfce4 (using on-screen keyboard).
Thank you for the instructions!
Edit: I just disabled autologin-guest to confirm the issue. Yet, lightdm showed up.
Very wierd...
Edit2: Check the following post for the solution.
If someone is having issues with Lightdm e.g getting a non-GUI login screen, or the phone looping between a black screen (~3s) and u-boot's graphical menu(~0.5s) instead of showing Lightdm,
type the following in the Debian chroot:
Code:
dpkg-reconfigure lightdm
About touchscreen patches
It turns out that those patches (from for-upstream/atmel-mxt-fixes) are not needed to enable touchscreen on Aries phones.
Just look here https://github.com/PabloPL/linux/co...7ff#diff-a55548a61205e9ebe52d79c1251eb46cR361
So like @xc-racer99 said, the best will be to use for-upstream/aries-patches-v2 branch
About compilation problems:
You can try to take toolchain from https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/ (i'm using it during development on my ubuntu 16.04).
anyone have the compiled files please?i have tested all i have command not found on cross compiler
laharl_22 said:
anyone have the compiled files please?i have tested all i have command not found on cross compiler
Click to expand...
Click to collapse
Frankly, and with no offense meant, the state of the project is such that if you are unable to compile it on your own, then you probably shouldn't be running it as the potential for messing up your device and hard-bricking it is relatively high (ie I screwed up once and had to apply the unbrickable mod on my device to save it). As well, it's only really useful right now as a development project for someone with time on their hands
If it ever gets to point where it becomes usable, precompiled binaries with instructions on how to flash them will be provided. Don't hold your breath on getting to this point soon (or maybe even ever...)
Related
Kernel compile :
Do it on user not root :
1. Make sure you have an appropriate environment to get the source (git) and to compile the kernel. Install git, gcc, make and libncurses5-dev at least. For Ubuntu based distributions.
apt-get install git-core build-essential libncurses5-dev
2. Create a directory to hold the kernel sources
mkdir ~/htcleo
3. Download the kernel source
cd ~/htcleo
git clone git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git
cd kernel
git checkout -b htc-qsd8k-2.6.29 origin/htc-qsd8k-2.6.29
4. Download and decompress the arm toolchain (64mb)
cd ~/htcleo
wget http://www.codesourcery.com/gnu_too...-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
5. Generate the default .config for the kernel(ARCH is case sensitive)
cd kernel
make htcleo_defconfig ARCH=arm
6. Compile
export PATH=~/htcleo/arm-2008q1/bin:$PATH
make Image ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Find your kernel Image in /htcleo/kernel/arch/arm/boot/
Now you can configure your proper kernel :
mousepad (Xfce) or gedit (Gnome) ~/htcleo/kernel/arch/arm/configs/htcleo_defconfig
cd ~/htcleo/kernel
make mrproper
make htcleo_defconfig ARCH=arm
export PATH=~/htcleo/arm-2008q1/bin:$PATH (must need once time)
make Image ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Use git pull in ~/htcleo/kernel to update file and recompile to have the last modified on development
Initrd compile :
Need to be root !
1. Download initrd.gz from other HTC compiled
mkdir initrd (or anything else in propely folder nothing else on)
cd initrd (put your initrd.gz here)
gzip -dc initrd.gz | cpio -id
Now you have all file and folder you can touch and modified
Use mousepad or gedit on root
2. Recompile proper
rm initrd.gz (before do a copy for other instance)
find (all name of folder and file) | cpio --create --format='newc' > initrd
Compile source for Arm :
(root user)
On source folder :
#export ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- PATH=(your path)/arm-2008q1/bin:$PATH
#CC=arm-none-linux-gnueabi-gcc ./configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi
# make
For who want to take time to test and finaly make Android works on HTC Leo.
I thinks all members hav's HTC Leo !!
hey guys..
i really want to use android on my new HD2!
i'm a little-medium (^^) n00b, but spent a lot of time in android on my kaiser.. so i'm not a totally noob, i think.
i can help testing files for you.
so, what do the dev's think, how long did it take to use android on our phones?
greetings
Thanks for the tip, will try it tomorrow and report what I see
wget http://www.codesourcery.com/gnu_tool...ux-gnu.tar.bz2 -O arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
Click to expand...
Click to collapse
On the wget command supplied you have to right click and copy link location and paste that as the wget url or it wont work, the forum has truncated the text with ... in the middle . use the -O afterwards as shown
1. Download initrd.gz from other HTC compiled
Click to expand...
Click to collapse
Im also not quite understanding this, what is other HTC compiled ? Another set of sources with Android?
Thread Edit
You can take any one initrd.gz and modified script on it.
HTC Vogue initrd.gz its the better.
Tigrouzen said:
Thread Edit
You can take any one initrd.gz and modified script on it.
HTC Vogue initrd.gz its the better.
Click to expand...
Click to collapse
Thanks for fixing the wget ..
Cool so i already have another initrd and i hang at the freeing 104k init error .. Are you able to get past this ?
Nice job writing that up.
Personally I use a different toolchain, but if the toolchain you mention works without a problem, then all is well When I used a toolchain from codesourcery I somehow got compile errors as there was no VFP support (maybe I just took the wrong binary).
The toolchain i'm using is in this git repo: http://android.git.kernel.org/?p=platform/prebuilt.git;a=summary and under linux-x86/toolchain/arm-eabi-4.4.0
NetRipper said:
Nice job writing that up.
Personally I use a different toolchain, but if the toolchain you mention works without a problem, then all is well When I used a toolchain from codesourcery I somehow got compile errors as there was no VFP support (maybe I just took the wrong binary).
The toolchain i'm using is in this git repo: http://android.git.kernel.org/?p=platform/prebuilt.git;a=summary and under linux-x86/toolchain/arm-eabi-4.4.0
Click to expand...
Click to collapse
This toolchain works, compiles fine but fails on boot at the 104k error for me .. Not sure how to progress this without further info / debug ..
NetRipper said:
Nice job writing that up.
Personally I use a different toolchain, but if the toolchain you mention works without a problem, then all is well When I used a toolchain from codesourcery I somehow got compile errors as there was no VFP support (maybe I just took the wrong binary).
The toolchain i'm using is in this git repo: http://android.git.kernel.org/?p=platform/prebuilt.git;a=summary and under linux-x86/toolchain/arm-eabi-4.4.0
Click to expand...
Click to collapse
Yes cause you use 2009q3 arm-eabi not contain VFP support maybe not important.. i try with your toolchain and 2008q1 binary
This is one worked with 2008q1 binary
Nice work! When do you think Android will be avaible on HD2?
How should I format the micro SD Card ?
Do I have to create two partitions (one eith FAT to boot and another ext3 to filesystem ?)
Does anyone have a tutorial to configure the sd card ?
My experience format SD card make some mistake and brick some SD card on linux. For now dont do that cause no way and ist not ready to work.
But Android porting hardware its now everything ok, just wait some moment maybe one or two month to see it on HD2.
This test just need put haret, default.txt based on Leo, initrd.gz and Image on sdcard root and executed haret
If you have drivers to every piece of hardware then tell me how did you managed to detect the SD card reader. Because I simply can't.
The developer find right interrupt for hardware on Leo but we dont have definitively realized driver, this is a problem to communicate right with Leo hardware.
If we have main console work then its ok!!
Now just have boot working and freez.
We need wait.
You can maybe look in this thread Martijn Stolk works, 38hours ago he add some instruction on kernel, then its signified we advanced to make Android works.
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-qsd8k-2.6.29
I think 2 months later if everything ok.
Now you dont need formating your sd card just put file on root.
What's about other non-Leo QSD8x50 devices? I tried some of previous NetRipper's kernels, but they didn't work... As I'm completely next to nothing in ARM kernel development, I take someone should port IRQ and GPIO map (If I remember correctly) of respective devices (e.g. neoTouch, Expo, TG01 etc), isn't it?
Or is the kernel universal?
I thinks HTC take's other hardware way and this hardware doesn't have any driver on linux.
HTC just make's driver for Windows mobile and then have realy code source to ported on linux and android.
Or maybe system locked protection !! Like's Archos 5 IT code secure implentation !!
Maybe HTC do it protection hardware cause Microsoft ask him to not porting it on Android !!!
Or marketing way not arrenged HTC to sell HTC Supersonic simillar hardware with Android !!
I hope its not this way, cause no way to ported Android or linux on Leo..
Last issue if there no protection just wait for HTC Supersonic and porting in Leo.
Tigrouzen said:
Last issue if there no protection just wait for HTC Supersonic and porting in Leo.
Click to expand...
Click to collapse
Would love it, with DualBoot in more
I'll donate for Android, I am really excited to get it on our device !
Thank you to all developpers who take time for us !
See you.
Edit : Use "git pull" to update automatically file modified on development
Thanks for developers.
Edit : compile source for Arm
The following contains binaries, and instructions for use of an experimental newer toolchain than those included in the android pre-built package.
This is provided to allow existing linux kernel developers experiment with the updated version of GCC (besides the complicated building instructions the code just has a small patch for a known issue with android and 4.6.* otherwise is directly from GNU (see build information below)
The packages I'm also providing to help developers current on windows (With cygwin but no other virtual environment) to start exploring android Linux kernel development for their devices. (In addition to a OSX toolchain for more advanced mac users)
due to the slight differences between kernels on different devices this How To is intended to be used for advanced users who can adjust for the differences required for the devices specific kernel.
I may add additional guides to this thread if I find a need for them.
[size=+1]Binary Toolchains[/size]
I have two versions of a GCC-4.6.3 toolchain
1) For x86 linux: toolchain-4.6.3.tar.bz2 (Sha1: c8c57aba6ad92e9acddf29ba8620ba880be09a81)
2) For Cygwin (windows): toolchain-4.6.3.cygwin.tar.bz2 (Sha1: 6947e1c1ba95195019f542eb8ba0708667b63eca)
3) For OSX (mac/darwin): toolchain-4.6.3.darwin.tar.bz2 (Sha1: 9a977f0672863fdd9501383a6ad1e30723281f68)
[size=-1]> The linux version was built via this script: http://pastebin.com/b2dZ8YtG (or in the included toolchain_notes.txt)
> The cygwin/darwin version uses the same source however has a slightly modified script (see the included toolchain_notes.txt for the updated script)[/size]
[size=+1]System Requirements[/size]
Note I have a 64bit debian linux box, and a 64bit version of WIndows7 Pro running cygwin, while I believe these binaries ought to be compatible with all x86 linux and cygwin installs these have not been tested by a wide number of people yet.
> Linux users: If you have a working android build environment likely no additional requirements are needed. In addition you must build any kernel/android utilities from a case sensitive filesystem or disk image.
> OSx users: the cygwin packages will give you an idea of what is required, please also see the README in the tar.bz2 about manually installing elf.h
> Cygwin users: as its unlikely you have compiled a kernel with cygwin up to this point you may wish to ensure the following packages are installed (as well as any cygwin recommends to be used with them):
vim
vim-common
make
cmake
lzop
gcc
gcc-core
gcc-g++
wget
git
git-compleation
libncurses-devel
python
Cygwin users must also set their NTFS file partition to allow case sensitive files:
To do this open regedit and change:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
to 0
after this reboot and the NTFS kernel will allow cygwin to use case sensitive files (ie 'AbC' and 'aBc' as two different files)
[size=+1]Advanced Kernel Building Guide[/size]
Since may devices are slightly different this can only be a high level kernel building guide
Please ask for any specific directions from the current kernel maintainer.
To most people who have built kernels before this will look familiar, the most important part is preparing your local environment to use the new toolchain,
1) If you have not already download the tar.bz2 above, (pick the one for the computer you are preparing to build kernels on)
2) extract the file (for the sake of this guide I will assume it is extracted into a ~/android directory)
ie on cygwin you might:
mkdir -p ~/android
cd ~/android
tar -xjvf toolchain-4.6.3.cygwin.tar.bz2
Note: steps one and two are just properly installing the toolchain, you will not need
to repeat them to build a different kernel.
2.b) OSX Only: check elf.h
open ~/android/toolchain-4.6.3/README in a text editor and check if elf.h is installed, otherwise manually install it as per the readme
3) fetch your kernel source into the ~/android directory and change into the
source codes root directory
(this can be via a git repo or tarball)
example if you wanted my ACER a100/a500 source you might run:
git clone git://github.com/ezterry/AcerTabKernel.git
cd AcerTabKernel
change this to match the source you are fetching
4) In the root directory of the kernel source (~/android/AcerTabKernel in the about a100/a500 example) update the environment for the cross compiler
add the toolchain to your path:
export PATH=$HOME/android/toolchain-4.6.3/bin:$PATH
set the cross compile:
export ARCH=arm
export CROSS_COMPILE=arm-linux-androideabi-
export KERNEL_DIR=`pwd`
(this will need to be done once for each terminal you use to run any of the following make commands)
5) Grab your configuration
From the device:
adb pull /proc/config.gz
gzip -dc config.gz > .config
or from a prepared configuration if it's included in your code base by running
make _defconfig
example for the a100/a500 code base is 'make vangogh_defconfig' for the a100 and 'make picasso_defconfig' for the a500
6) Customize configuration
just run menuconfig and use the UI to update settings
make menuconfig
7) building the kernel (zImage)
This is normal at this point with 'make -j'
so for a quad core CPU you can run
make -j5
(note: the wrong number in the -j argument will not harm the build but may slow down the building process by either using too few threads or needing to keep track of too many)
8) If it worked you will now have the kernel in arch/arm/boot/zImage
this can be injected into the boot.img (as the kernel, using an existing ramdisk) as is
If it failed for your kernel your kernel source may need one of the common patches
9) Building modules
the following will prepare the modules in subdirectory mod:
make modules
rm -rf mod
mkdir mod
cp `find ./ | grep .ko$` modules.order mod/
After these commands [if no errors] you can simply copy the contents of mod/ to /system/lib/modules on your device, note it is recommended usually to remove the existing contents of /system/lib/modules unless there is a closed source module required from the previous build despite the new kernel.
[size=+1]Common Patches Required[/size]
If your kernel has not been built for the new toolchain or on cygwin before you may require some of these common patchs: (I've thus far only tested this on my Acer A100/A500 source)
wireless/bcm4329 for GCC-4.6.3:
https://github.com/ezterry/AcerTabKernel/commit/123f32e27e2c74f1c1789ae5d6d5a1c04e1e264c
linux kernel module patch for cygwin (broken elf.h):
https://github.com/ezterry/AcerTabKernel/commit/220db49593cf6b9f3b556e2f4b75b2f6d3ff556c
Error compiling security/smc/bridge_pub2sec.S (I required the cygwin elf patch and this patch to build the Franco galaxy nexus kernel)
0001-Fix-build-error-with-4.6.3-toolchain-smc-0.patch
(use 'git am 0001-Fix-build-error-with-4.6.3-toolchain-smc-0.patch' to apply)
OSX stat patches (fixes errors between GNU and BSD stat):
https://github.com/ezterry/AcerTabKernel/commit/0c49df3cc1a05a0ccd98201511cdc0534aaeb35a
Errors loading newly built modules (modules appear to build cleanly but wont install):
simply add -fno-pic to CFLAGS_MODULE
https://github.com/ezterry/AcerTabKernel/commit/c5ed0fcb014d36936a86ad253f15af43de2f644a
(I can add others here if highlighted to me, and as I find them)
[size=+1]Other Toolchain uses[/size]
The linux toolchain can be used to build android components, however this requires various manipulation to the android /build git repository as currently various other toolchains have hard coded paths into the prebuilt repo. If you intend to incorporate this into your build it may be best to inject the toolchain into your prebuilt repo rather than expect your users to download the links above, ensure to keep the compile notes as it explains how to get the source code to the toolchains)
On cygwin/osx it may also be possible to build android applications however I've not yet tested this as the scripts to make a proper build are complex when attempted outside the android build tree.
Excellent!!! thanks Man!!! Has been looking for one of these
Added in the OSX version of the toolchain (and some related patches)
Also if you are having problems with your modules built with this toolchain a CFLAG fixes it. (see note in common patches)
FINALLY!!! Great Instructions followed them to the T and BAM got my kernel compiled!!!
wow your toolchain is so small, many thanks, just compiled a kernel for my LG P500 gonna test it, thanks again
Bookmarked for testing when I wake up...
I can almost put: "Building under Windows is not currently supported." (quote from google), unofficially at least, out of my mind...
I have been spoiled by Windows for far too long I fear, my attempt for this last week at getting Linux setup and building CM9 has been nothing but a complete FAILURE, too many single line entrys for different distributions/package combo's, commands I dont know and cant find because of wildcard portions of them and lack of understanding, and not enough scripts like the wonderful Compile CM9 script someone put up (cant run it because all the pre-req's arent setup).
Good god Ill be jumping for joy if this works tomorrow on WinBlows!
EDIT: never mind, problem solved, what I need to know now won't be solved here
I wish i knew how to go about doing this..
Thanks
Thanks For ........... i Really need It .........
Hammerfest said:
Bookmarked for testing when I wake up...
I can almost put: "Building under Windows is not currently supported." (quote from google), unofficially at least, out of my mind...
I have been spoiled by Windows for far too long I fear, my attempt for this last week at getting Linux setup and building CM9 has been nothing but a complete FAILURE, too many single line entrys for different distributions/package combo's, commands I dont know and cant find because of wildcard portions of them and lack of understanding, and not enough scripts like the wonderful Compile CM9 script someone put up (cant run it because all the pre-req's arent setup).
Good god Ill be jumping for joy if this works tomorrow on WinBlows!
Click to expand...
Click to collapse
If you succeed tell me how to do it in a more familiar way
I get errors regading the processor not being supported?
brfield said:
I get errors regading the processor not being supported?
Click to expand...
Click to collapse
Sorry I can't support devs that have not learned cut copy and paste.
You probably forgot to export some of the environment variables or are just trying to run a arm binary on your PC and or a x86 binary on your arm device.
But why am I guessing? Why don't we know what you tried to run and what the actual text of the error was.. what type of kernel you tried to build, what you are running?
These packages are for developers if you feel like using them its time to learn to how to trouble shoot a problem and write a ticket to explain said problem clearly to others with at least some information to give us a chance to understand.
Sent from my Galaxy Nexus using Tapatalk 2
Great guide. Have the bcm4329 wireless module, so followed the tips and everything compiled and works!
Thanks!
one question,how to compiled android kernel with -O3 optimization?
jxxhwy said:
one question,how to compiled android kernel with -O3 optimization?
Click to expand...
Click to collapse
Um, in general its recommended you don't:
-O3 is not recommended for the kernel as many low level parts require the assembly code generated to remain as is and not be optimized as will be by some of the options -O3 enables thus likely reducing the stability of your kernel.
---
That said the menuconfig has an option to optimize for size (-Os) if enabled else -O2
For other optimization (including tuning for your cpu) you can add them to the CFLAGS_KERNEL/CFLAGS_MODULE in the make file.)
For -O3 like functionality you could add the increment to the line:
-finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftreel-vectorize, -ftree-partial-pre and -fipa-cp-clone
-Ofast is -O3 with -ffast-math as well
If you do build with all the -O3 or-Ofast options ensure you test the kernel for stability and run some benchmarks. (as it may not actually be faster depending on the cache misses)
The first option I'd start pruning was the one mentioned in my reference below -fgcse-after-reload.
If you really insist on -O3 rather than just adding the optimization you want that are not in O2,it can be added also in the Makefile where the configure flag is checked and its added to KBUILD_CFLAGS
Obviously all and any of this is at your own risk, anything that breaks you have to find a way to fix it.
Reference:
Gcc optimize options:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Talk of O3 and the kernel (not android specific)
http://unix.stackexchange.com/questions/1597/compiling-gnu-linux-with-o3-optimization
ezterry,thank you very much!
I want to build cm9 kernel using toolchain 4.6.3.
How to replace the default GCC 4.4.3 to 4.6.3 version?
BTW,I use the way -- make bootimage
jxxhwy said:
ezterry,thank you very much!
I want to build cm9 kernel using toolchain 4.6.3.
How to replace the default GCC 4.4.3 to 4.6.3 version?
BTW,I use the way -- make bootimage
Click to expand...
Click to collapse
If you are asking in a cm9 build tree.. its a pain, best is to update the cm kernel makefile to point the build chain temporarily.
If you mean just to compile by hand as described in the op
Once the kernel is compiled find an anykernel update.zip or manually use mkbootimg or fastboot to merge it with the ram disk. Cm9 targets mkbootimg and unpackbootimg (if I'm not mistaken) will build the applications to unpack your current (or the default cm9) boot image and re-create them with your custom kernel built from hand.
Now,I runing script file:
#Let's make sure the environment is clean and ready to compile the kernel
echo "Cleaning house!!"
make mrproper
echo "House cleaned, lets build a kernel!!!"
#
# Lets set the kernel defconfig
echo "defconfig = cyanogenmod_iprj_defconfig"
make ARCH=arm cyanogenmod_iprj_defconfig
#
# Let's build a kernel
echo "Now compiling kernel, go get a soda! "
ARCH=arm CROSS_COMPILE=~/Android/sourcecm9/cm9/toolchain-4.6.3/bin/arm-linux-androideabi- make zImage -j4
#
if [ -f arch/arm/boot/zImage ]; then
echo "Plague has been compiled!!! You can find it in arch/arm/boot/zImage"
else
echo "Kernel did not compile, please check for errors!!"
fi
but,I got some error output:
/home/xxx/cm9/toolchain-4.6.3/bin/arm-linux-androideabi-ld: cannot find usr/initramfs_data.o: No such file or directory
thanks again!!!
I think that means there is an issue with your config..
Most android kernels require initramfs, but don't specify a file, as its provided by the bootloader.. However in your case it is trying to embed it into the kernel.
Sent from my A500 using Tapatalk 2
ezterry said:
I think that means there is an issue with your config..
Most android kernels require initramfs, but don't specify a file, as its provided by the bootloader.. However in your case it is trying to embed it into the kernel.
Sent from my A500 using Tapatalk 2
Click to expand...
Click to collapse
issue has been resolved by myslef.Thanks for your time.
This will not be worked on any longer thanks to Huawei's incompetence. I'm glad my main phone isn't by them. I leave my 0.2 diff attached (which did make my phone faster FWIW - and has fsync() control. Not of use to me, but people who use a modified libsqlite would like it...). Feel free to apply it and see if you can somehow fix dhd.ko loading.
Hi,
Not one for names, so this shall be known as "OC kernel" This is built from the ICS U8800pro source that Huawei put out.
Install at your own risk; I take no responsibilty for any damage that may occur through the usage of this kernel.
Features:
ADB as root
Overclocking enabled (thanks to genokolar)
Undervolting interface added (from genokolar, who took it from a SE kernel modder somewhere) - I think SetXperia can use it
SIO I/O scheduler added
SmartassV2 cpufreq scheduler (AnDyX mod) - although I think ondemand does a bit better IMO
sysfs entry to turn off keypad lights (I wrote an applet for this some time back, I'll dig it out later)
Logcat is always enabled now as the ServiceMenu toggle doesn't work anymore
Minimum display backlight is set to 15, but I think Android needs a framework change to use it. You could try RootDim
Kernel actually builds (and Bluetooth works)
ZRAM (+ swap) support. ZRAM is optimized for Android (taken from Siyah kernel). I'll write up the instructions on enabling this later
CIFS as module
Extras:
Change schedulers and phone speed:
Use a tool like No Frills CPU or SetCPU.
Turn off button lights:
Install the ButtonLight widget and add it to your main screen. I've published the source before in another thread; seek it out if you're after its (bad) code.
It's buggy the first few times you run it, but works fine after that.
Dim screen to 14:
The minimum backlight level is now set to 15. RootDim from the Play Store lets you set it to that.
Mount Windows shares:
Grab CifsMounter and point it to the cifs.ko in /system/lib/modules. You may also need to insmod nls_utf8.ko and md4.ko.
Enable ZRAM (taken from Siyah kernel):
(Note I've not used ZRAM so I have nothing to say on its stability, good or bad)
Grab a BusyBox binary from somewhere
Run the following commands:
Code:
echo 90 > /proc/sys/vm/swappiness #You must set the swappiness high to ensure that the compressed RAM is accessed first!
echo $SIZE > /sys/devices/virtual/block/zram0/disksize #Set size to whatever you wish. 100MB is 104857600 = 100 * 1024 * 1024
busybox mkswap /dev/block/zram0
busybox swapon /dev/block/zram0
Dump the lines in install-recovery.sh if you want to be ZRAMMed every time you boot the phone (although in that case, make sure you have
Code:
busybox swapoff /dev/block/zram0 > /dev/null 2>&1 #Use > /dev/null 2>&1 for every busybox command in install-recovery.sh as it will discard any messages outputted
echo 1 > /sys/devices/virtual/block/zram0/reset
before the lines above)
Install:
Flash the attached ZIP in CWM recovery. You should backup your original boot.img and /system/lib/modules first
Source:
Take http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDY3NTU= and apply attached diff
at last..xaaxxaa!!but why with modules too???whats their use?
pikachukaki said:
at last..xaaxxaa!!but why with modules too???whats their use?
Click to expand...
Click to collapse
'cause I add a new module - cifs (used by CifsMounter if you want to mount Windows shares) - and because the modules that are originally in /system/lib/modules need to be replaced so that they can load with this kernel (I don't know what those modules do, but I'd rather play it safe)
qwerty12 said:
'cause I add a new module - cifs (used by CifsMounter if you want to mount Windows shares) - and because the modules that are originally in /system/lib/modules need to be replaced so that they can load with this kernel (I don't know what those modules do, but I'd rather play it safe)
Click to expand...
Click to collapse
Boot normally change io to sio and smartassv2...1500mhz lets check..good work..i envy you and i want your guide on compiling...xaaxax im off to bed!!
fps is locked!!xaaxax
pikachukaki said:
Boot normally change io to sio and smartassv2...1500mhz lets check..good work..i envy you and i want your guide on compiling...xaaxax im off to bed!!
fps is locked!!xaaxax
Click to expand...
Click to collapse
I'll write it up sometime - but bear in mind I'm not an expert at this
Regarding FPS: do the install-recovery.sh trick
Only thing I modify in initramfs is the ro.secure setting so that ADB can be ran as root
qwerty12 said:
I'll write it up sometime - but bear in mind I'm not an expert at this
Regarding FPS: do the install-recovery.sh trick
Only thing I modify in initramfs is the ro.secure setting so that ADB can be ran as root
Click to expand...
Click to collapse
You did a great job i couldnt even compile the kernel without changes!!you did great!!
the difference is obvious !!
Sent from my U8800Pro using xda premium
Pika When U add This Kernet To ur ROM?
As expected from qwerty12!
Great job!
I'll also request a guide on how to build the kernel like pika asked.
Hope you continue to improve the kernel! A thanks is simply not enough to thank you for your work, but thanks again
husen4u said:
Pika When U add This Kernet To ur ROM?
Click to expand...
Click to collapse
I wont!just d/w it and flash it!simple!
Sent from my U8800Pro using xda premium
Now what you suggest oc ics or kalo gb?
Sent from my U8800pro using xda app-developers app
husen4u said:
Now what you suggest oc ics or kalo gb?
Sent from my U8800pro using xda app-developers app
Click to expand...
Click to collapse
From now on i wont ever go back to GB ever again! if our luck changes and someone release cm9 i will forget what gb is!! there are some small bugs but the rom is usable for everyday!!
Moihack said:
As expected from qwerty12!
Great job!
Click to expand...
Click to collapse
Thank you
I'll also request a guide on how to build the kernel like pika asked.
Click to expand...
Click to collapse
Certainly, sir.
Hope you continue to improve the kernel! A thanks is simply not enough to thank you for your work, but thanks again
Click to expand...
Click to collapse
Unfortunately I won't be working on this anymore unless Huawei get back to my request for the source to the the dhd.ko module (which they may not have to comply with because the license for the module states "Unless you and Broadcom execute a separate written software license agreement governing use of this software" so the U8800pro version may not be under GPL). I made (well, found on the Internet) more optimizations but the Wi-Fi refuses to turn on because the dhd.ko module refuses to load. Only way I can get something working is to build the source that Huawei give or attempt to force other versions of the bcm source to load, but it's unlikely that would work.
--
Anyway, a small guide.
I used an x86_64 laptop running (X)ubuntu 12.04.1 to follow these steps. This page was a great resource.
Prerequisites:
A computer running GNU/Linux (a Mac should work in theory - the same toolchain we use is built for it, too, but I have no idea how OS X works)
git installed (apt-get install --no-install-recommends git-core is enough under Ubuntu)
sudo apt-get install flex bison gperf build-essential libncurses5-dev zlib1g-dev ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib abootimg
Getting ADB working
One of the best things to do is getting ADB set up, as you then have easy communication with the device. It's not essential but you'll just end up wasting time transferring files through other, longer means.
Grab the Linux platform tools ZIP from here: http://www.hariadi.org/android/manually-download-of-android-sdk-tools-and-sdk-platform-tools/. Extract the adb binary from the zip file, preferably to somewhere in your $PATH. chmod 755 it. chown, if necessary.
Next, open http://aur.archlinux.org/packages/an/android-udev/android-udev.tar.gz and, doing all this as root (sudo in Terminal etc.), place 51-android.rules in /lib/udev/rules.d/ (not the best place - but it works), chmod 644 it and chown root:root it.
Next, execute /usr/sbin/groupadd adbusers, followed by gpasswd -a USERNAME adbusers, USERNAME being the user you normally log on with.
Restart (while you can force Linux to see the new group through the, well, newgrp command udev will not "see" the new rule, despite how much you try with udevadm).
That should be ADB set up (give it a test, remembering to enable USB debugging mode on the phone first!).
On to preparing your workarea.
--
Create a new folder in your home folder and cd to it. This folder will house the prebuilt folder of toolchains and other stuff, and the kernel source in a folder of its own.
In this folder, execute git clone --depth 1 https://android.googlesource.com/platform/prebuilt.git and move onto the next step, since the download takes a while. That command grabs the prebuilt toolchain from Google using Git, but doesn't obtain a deep history for each file to make the download quicker.
Open http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDY3NTU= and save the source to your Downloads directory. After git has finished running, still in the folder with the "prebuilt" folder, execute tar jxf ~/Downloads/HUAWEI_U8800pro<tab - as in actually press tab> and you should have a kernel folder alongside the prebuilt one.
Building the kernel
cd to this new kernel folder.
First things first: make sure that Bluetooth is properly enabled by editing the Makefile. Find the line #ifeq ($(ENABLE_BTLA_VER30),true) and comment out every line in that section except for KBUILD_CFLAGS += -DHUAWEI_BT_BTLA_VER30 so you end up with this:
Code:
#/* < DTS2012020604357 zhangyun 20120206 begin */
# Add Huawei Marco for different BT chip
#ifeq ($(ENABLE_BTLA_VER30),true)
KBUILD_CFLAGS += -DHUAWEI_BT_BTLA_VER30
#endif
#ifeq ($(ENABLE_BLUEZ_VER30),true)
#KBUILD_CFLAGS += -DHUAWEI_BT_BLUEZ_VER30
#endif
#/* DTS2012020604357 zhangyun 20120206 end > */
Commenting out the offending code leaves you with a kernel that builds but a Bluetooth module that won't start up - the same also applies if you try to build with the other define.
You can also make things easier for yourself by replacing the following
Code:
ARCH ?= $(SUBARCH)
CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%)
with
Code:
ARCH ?= arm
CROSS_COMPILE ?= ../prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
else you will have to put "ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-" after "make" each time. Remember this as I'll be assuming that you went for the option to edit the Makefile. I also assume that the prebuilt folder is above the kernel one. Adjust CROSS_COMPILE if necessary.
The ARCH variable is self-explanatory, but the CROSS_COMPILE variable (and the toolchain that it's pointing to) need to be set because the standard GNU development tools that apt installs don't produce output that an ARM processor can understand. So you cross-compile: the tools are for the X86 architecture but produce ARM output. 4.4.3 is chosen because the stock kernel is compiled with GCC 4.4.3 (if you run "adb shell cat /proc/version" you'll see). The arm-eabi-4.4.3 folder is chosen over arm-linux-androideabi-4.4.x because it specifies that magic "3" (I know, bad way to decide but it works), and over i686-android-linux-4.4.3 because we don't want to produce code for the PC.
Get the current configuration in use by the stock kernel (as that's a good point to start from - a known working configuration): http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source#Configure_the_Build
I'd also recommend placing a copy of .config as arch/arm/configs/<your funky name here> so that if .config gets deleted (make clean etc.) you can run make <the name you gave to the file in arch/arm/configs> and have .config come back again.
(cp arch/arm/configs/<the name you gave to the file> .config if you didn't modify the Makefile to specify the ARM arch.)
Run make oldconfig (not always necessary - generally it's invoked if you've applied a patch that introduces a new config option and the option then needs to go into your .config. Run make menuconfig afterwards and customize away.
When you're done, run make -jX - X as in the number of cores you have + 1. So, in my case, with a quad-core processor and HyperThreading enabled on all of them, "make -j9" works for me. If the compile went OK, you'll be left with a message saying that arch/arm/boot/zImage is ready. If not, run "make" without the -jX argument and make should stop where the error occurs. Have fun fixing the error!
Assuming that you have a new, shiny zImage, it's now time to put it into your boot.img.
Updating your boot.img:
Google have tools for this purpose but I've never used them so I don't know how they work. abootimg works fine for this, however.
Pull the current boot.img off your phone: adb pull /.cust_backup/image/boot.img.. I'd recommend creating a backup somewhere.
Create a new directory to store the boot.img in on your computer and run abootimg -x boot.img (if you had fun enabling every option in the kernel, you'll see why I'm telling you to use the -x option first rather than directly use the -u option). Now run abootimg -u boot.img -k <path to your newly built zImage>.
If this succeeds, yay! If not and you're told it's too big for the boot image, then don't worry. Take the size it's saying that the zImage is and convert that number into hex. Edit bootimg.cfg and change the value of the bootsize setting into the number you just converted into hex. We'll now repack again, but this time running abootimg -u boot.img -f bootimg.cfg -k <path to your newly built zImage>. This should work.
Sending the boot.img to the phone
If your ADB is already running as root, you can do the following to upload the new bootimg:
Code:
adb shell mount -o remount,rw /.cust_backup
adb push boot.img /.cust_backup/image/
adb reboot
If not, just reboot into pink screen mode and copy and paste.
Check System Settings and the version number should've changed. Congratulations!
Extras
Installing the modules:
OK, so you decided to build parts of the kernel as a module and you want to actually, y'know, have the modules present on the device. After building the kernel, execute:
make INSTALL_MOD_STRIP=1 modules_install INSTALL_MOD_PATH=<any folder name here>
If you look in that folder, you'll find the modules neatly wrapped up in folders, along with other text files. These text files are useless on a stock ROM because there's no modprobe - you need BusyBox for that. And since we don't want to have them seperated in folders (this is how the stock kernel does it), the files would be wrong, anyway. If you want to use modprobe and have BusyBox installed, you can run depmod on the phone after transferring the modules.
To get the modules into one folder make the directory "modules" in a folder higher-up to where the modules are stored, and then run for i in `find . | grep ko`; do mv "$i" ../modules/; done to move them into that folder.
At this point, I'd just recommend using my OC_Kernel.zip and replacing the modules in that. Or you can adb push them over to the /system/lib/modules folder (after issuing an "adb remount" - assuming that ADB is running as root in the first place).
Making ADB run as root:
As root on your computer, (we want to preserve permissions) use abootimg to split the boot image and extract the contents of the initrd:
abootimg -x boot.img && mkdir newramdisk && cd newramdisk && zcat ../initrd.img | cpio -i --no-absolute-filenames (--no-absolute-filenames is important! I trashed a Ubuntu install by leaving it out - the initrd contains ARM binaries of core Linux programs and if the initrd.img contains an absolute path of "/" then these files will get placed in /)
Make any changes you desire to the initrd. To have adb run as root, just edit /default.prop and set ro.secure to 0. Make sure that the editor you used didn't leave any backup files.
When you're done, run find . -print | cpio -o -H newc | gzip -n -9 > ../initrd.img and this will put the modified initrd folder back into initrd.img.
After that run cd .. ; abootimg -u boot.img -r initrd.img to actually put the initrd.img back into the boot.img.
If you run into a space error, you can do one of three things:
if you only made a single change (like enabling ADB), check to see that there is no backup file (default.prop~) littered about
you can remove the lengthy comments and copyright notices from the files to make space
you can use the trick we used earlier with abootimg to increase the size number in bootimg.cfg for the initrd
Overclocking:
Just look at the acpuclock C file (and possibly relevant cpufreq changes - but I can't remember) in my "OC kernel" diff. Make sure that the option in the kernel config is selected to limit the speeds to the U8800pro's native 1GHz, otherwise the phone will boot at 2GHz!
Rebuilding the Wi-Fi module:
I hope to be able to write this one since it's apparently needed in some cases, but it depends on if Huawei come through
any idea about this error?
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
matteof93 said:
any idea about this error?
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
Click to expand...
Click to collapse
Honestly, I have no idea. What toolchain are you using and where was your .config obtained from? Even when the Bluetooth thing was giving me errors, I never once saw that
same toolchain you have used. i have tried with ubuntu 12.04 x64 and ubuntu 10.04 x86 but same problem.....i have obtained my config from my phone using adb command
matteof93 said:
same toolchain you have used. i have tried with ubuntu 12.04 x64 and ubuntu 10.04 x86 but same problem.....i have obtained my config from my phone using adb command
Click to expand...
Click to collapse
I don't know why the same toolchain works on my laptop but not yours :\
Someone with a similar problem (same?) solved it by using an older toolchain: http://forum.xda-developers.com/showpost.php?p=27294383&postcount=7157
thanks thanks thanks.....i saw that post this morning but i did not noticed the post with the solution
UPDATE: NOW KERNEL COMPILED CORRECTLY....this means that tomorrow i know what to do
ZRAM (+ swap) support. ZRAM is optimized for Android (taken from Siyah kernel). I'll write up the instructions on enabling this later
qwerty your owning us some instructions!!xaaxxa
pikachukaki said:
qwerty your owning us some instructions!!xaaxxa
Click to expand...
Click to collapse
Done, check the first post
I also won't be working on this. My email (which does clearly state what I want, even if it's long-winded):
Dear Sir/Madam,
I recently built a kernel for my U8800pro from your sources and it
works fine, except that the Wi-Fi will not start because the dhd.ko
module that comes with the B928 firmware refuses to load into my
modified kernel. After looking around, the bcm4329 source is what I
need to build (usually distributed outside of the kernel); however, it
seems that the U8800pro uses a customized version. After looking at
the strings of the dhd.ko on the B928 firmware, I have seen many
strings that are present in that dhd.ko binary do not appear in:
* bcm_4.218.248.6_7x25_wifi_driver.tar from the Huawei Device website,
despite it having the same version number
* the bcm4329 source in the Qualcomm CodeAurora Git repository
* the bcm4329 source on the NyVIDIA Tegra Git repository
Furthermore, the strings also do not appear in the ICS kernel nor the
Gingerbread one. I can only conclude that Huawei have their own
specialized version of the bcm4329 4.218.248.6 source for the U8800pro
that is distributed outside the kernel. I understand that Qualcomm
allow the option to let the vendor arrange to have the code
distributed under a different license provided that the vendor makes
an agreement beforehand with Qualcomm. Otherwise it becomes GPLed by
default. If Huawei chose to make an agreement, then I have no right to
ask. However, I believe it is still licensed under the GPL for two
reasons:
* Running modinfo on the dhd.ko from the B928 firmware says this:
"license: GPL v2
* Both bcm_4.218.248.6_7x25_wifi_driver.tar.gz and
[S7][SoftWare]S7_Broadcom_BCM4329_4.218.205.0_Open_Source are under
the GPL
I would like to request the source code, please, of the bcm4329
4.218.248.6 source that is modified for the U8800pro if the code is
under the GPL
Best regards
Click to expand...
Click to collapse
was met with the following generic response:
Dear Customer,
Thank you for contacting Huawei device.
This is our website link http://www.huaweidevice.com/worldwide/searchResult.
do?method=execute&searchString=U8800pro where you can download the secure
code for U8800pro to you.
Once again thank you for contacting Huawei device.
Best Regards.
Huawei Device Customer Care Team.
Click to expand...
Click to collapse
Since my U8800pro is not my main phone anymore, I do not have the energy to fight. Nor do I want to work on Huawei's kernel, where you have to be careful about what you change or the Wi-Fi module won't load (and Huawei won't give you the source - which they should do since I'm sure it's under GPL). matteof93 will most likely produce something better or when everyone starts producing their own kernels and make enough improvements to be hit with the same issue as I, they'll start to get more emails and listen
@qwerty at the last command it said that device is busy...also is there any way that you can make it for init.d so it will be easier??thx!!
Hi all!
Many of us are dreaming of having a real native desktop operating system on Galaxy Note 10.1 as a second system. Of course, the software there is not touch-optimized, but you can attach keyboard and mouse via USB-OTG and Bluetooth and imagine it's a netbook
exception13 showed us that it's possible and shared his work on in a forum and repo. X-Stranger could use it and shared compiled images of ArchLinux. But what if you want to do something more specific for your own needs and you are not such a great developer as both of them are?
My project is for all of you who want to have native GNU/Linux, who want to participate but don't know how yet. It's a guide how to build it from scratch. The problem is - I am not a superdev too and I couldn't do many things. Frankly speaking, all the remaining things seem to be small but I don't know how to overcome them. Maybe it's because I'm studying economics but not programming
Link to the guide.
I need help from anyone who knows how to overcome any of the problems on every step! Everything I managed to do by myself is already written there and currently I have a compiled kernel which is booting a partition on external SD but it freezes there.
If you have any ideas - you can just make a pull request out of Github's webinterface, if you don't know how to edit this html but know something about building Linux - you are welcome to open an issue or write it here and I will include it in the guide.
Let's make our Galaxy Note 10.1 better together!
,I just got my Note 101.1 earlier today. I'll look into the missing information and add to the webpage. Is there anything that you think I should look into first?
I actually had a question.
Looks like you have the section "Harder Way - how to prepare binaries" split into Ubuntu and Arch. Instructions for compiling the kernel are the same.
I guess my question is why the choice to show the arch kernel being compiled under arch?
Might be easier to read the guide with all the kernel compiling done in Ubuntu.
**Edit**
What I didn't originally mention is that i really like it. Hoping to help contribute as well.
darksabre_x said:
I actually had a question.
Looks like you have the section "Harder Way - how to prepare binaries" split into Ubuntu and Arch. Instructions for compiling the kernel are the same.
I guess my question is why the choice to show the arch kernel being compiled under arch?
Might be easier to read the guide with all the kernel compiling done in Ubuntu.
**Edit**
What I didn't originally mention is that i really like it. Hoping to help contribute as well.
Click to expand...
Click to collapse
Good question. The reason for that are that despite how close Arch Linux and Ubuntu are, the environments are different. Ubuntu usually has some sort of bash completion enabled by default whereas Arch Linux doesn't and of course each of them requires diferent packages installed to perform the same functions. I believe thermatk did each distro separately as to make things simpler for the end user. Pick a distro and go as each distro's guide can be tuned independent of the others.
Soul_Est said:
Good question. The reason for that are that despite how close Arch Linux and Ubuntu are, the environments are different. Ubuntu usually has some sort of bash completion enabled by default whereas Arch Linux doesn't and of course each of them requires diferent packages installed to perform the same functions. I believe thermatk did each distro separately as to make things simpler for the end user. Pick a distro and go as each distro's guide can be tuned independent of the others.
Click to expand...
Click to collapse
Doesn't really answer my question considering the end kernel will be the same regardless of the distro being used. I think you took my question as "Why are there 2 options for kernel compilation?", which wasn't what I was asking.
Looks like thermatk actually addressed the question with a page update.
It now gives separate options depending on which distro you want to end up with on your Note 10.1, in addition to separate kernel compilation options.
What I was referring to was when it was Ubuntu only instructions from kernel compilation all the way to deployment on the tablet and Arch only instructions. The kernel and linux image instructions weren't independent of each other, as they currently are.
Update
I'm really happy to hear that someone else wants to use it and contribute! :victory:
darksabre_x, you are right I separated the guide into parts yesterday because the system where you compile kernel doesn't really affect anything on the tablet.
Soul_Est, thank you for helping with questions in the thread :good:
Now I understand that tabs are not the best way to do it, will start this day from trying to rewrite this to a navbar constantly on top which lets you choose options from a dropdown.
Also yesterday got the guide to the point when one path through can get ypu to a bootable distro! You can compile kernel wherever you want, you should be on stock based rom and choose to install Arch on separate partition which probably will be a partition on SD. What you have to add at the end is
Code:
pacman -S lxde
and copy xorg.conf from X-Stranger's post. Once rebooted, you will be able to enter android:changeme and
Code:
sudo lxdm
and the gui will start if you don't have USB-OTG and keyboard you won't be able to enter password but you can poweroff from the interface's right corner :good: Attention: if gui says that it has no permissions to write logs do
Code:
sudo mount -n -o remount, rw /
and retry but do not forget to write here about it!
What are the current problems:
Why exception13 and X-Stranger both hardcoded the whole cmdline for kernel and forced it not to be changeable from bootloaders. It's easy to fix in the config but there should have been some idea or i'm paranoic?
What's wrong with LinuxDeploy, separate partitions and CyanogenMod? hiruna filed a bug but meefik seems to be away for a week. If anyone else with CM has an idea on how to overcome this maybe with some special unmount commands CM is thinking that ext4 partition is th extSdCard and mounts it so that LinuxDeploy can't install anything there (seems that it's the problem) while stock can't mount ext4 as extsdcard and is not touching the partition.
How do we make Debian/Ubuntu to boot? Both ways - for separate partition and img are stuck one the problem that not any mkinitramfs or abootimg or their combinations could get to a better state than initramfs shell. Separate partition should be easier so focus should be on it for the start.
Adapt X-Stranger's guide about booting Arch from *.img. It's there and should be tested, rewritten and easied and some whitespaces should be filled. I know there are some as i have spent many hours in Arch with little dirty hacks like
Code:
ln -s /proc/self/fd /dev/fd
that are needed but no one ever wrote that they are.
What's wrong with basic video? While we get bootable Arch if you add lxdm and xorg.conf it should work with lightdm and boot there without console commands. If you try to install lightdm you will get nothing but a black screen if you start it with
Code:
sudo lightdm
... and it should boot automatically without touching console.
Oh and why is kernel from exception13 not building at all? XD
Redesign #2
Anyone dislikes the new design idea with navbar selectors instead of tabs?
I hope it's better.
Will soon update the guide with last steps to have Arch with LXDE bootable from separate partition.
That's fun as I started this project to get Ubuntu working... :angel:
If anyone can understand what should be done with mkinitramfs to make debian/ubuntu rootfs bootable - please do it.
First success!
If you choose any pc distro, arch on sgn with lxde on a seaprate partition you will now get a fully working guide that will give you a native bootable GNU/Linux =)
That's first success for me but still i hope to get help as i don't know things I asked two posts ago and it's difficult to move forward.
XFCE problems
XFCE is booting (not in the guide yet) but for working with fingers in XFCE one should probably disable multitouch S-pen works fine.
http://lists.x.org/pipermail/xorg/2012-July/054626.html
http://xfce.10915.n7.nabble.com/Xfwm-window-borders-do-not-respond-to-touch-screen-td17348.html
Will find a way to enable onscreen keyboard on LightDM and update the guide with XFCE. Still I was hoping to make it my primary DE and they are not supporting fingers moving windows upstream :crying:
I was hoping to contribute this weekend but unfortunately my only machine is down after mucking up the /lib folder when heimdall. To add insult to injury, I have no backups. Installing Arch Linux or Debian and configuring everything to my liking again will take a few hours.
Sent from my GT-N8010 using Tapatalk 2
How to setup WiFi using wpa_supplicant.conf
How to setup WiFi using wpa_supplicant.conf
1. Copy the "wifi" folder to "/opt"
- You will need gedit to edit the nameservers.
- You also need two dependencies before installing gedit.
- The two dependencies are : gtksourceview3-3.6.1-1-armv7h.pkg.tar.xz and libpeas-1.6.1-1-armv7h.pkg.tar.xz
2. Download them and copy over to ArchLinux
3. Install the dependencies first then gedit:
Code:
sudo pacman -U gtksourceview3-3.6.1-1-armv7h.pkg.tar.xz
sudo pacman -U libpeas-1.6.1-1-armv7h.pkg.tar.xz
sudo pacman -U gedit-3.6.2-2-armv7h.pkg.tar.xz
4. insmod the drivers:
***NOTE*** " 3.0.31-gedcc915 " is my kernel name. Change it to your
kernel name if it is different.
Code:
sudo insmod /lib/modules/3.0.31-gedcc915/kernel/net/wireless/cfg80211.ko
sudo insmod /lib/modules/3.0.31-gedcc915/kernel/drivers/net/wireless/bcmdhd/dhd.ko op_mode=0 firmware_path=/opt/wifi/bcmdhd_sta.bin nvram_path=/opt/wifi/nvram_net.txt_murata
5. Enable the wlan0:
Code:
sudo ip link set wlan0 up
6. Setup wpa_supplicant and ip address:
Code:
sudo wpa_supplicant -B -i wlan0 -Dwext -c /etc/wpa_supplicant/wpa_supplicant.conf
sudo ip addr add 192.168.1.33/24 dev wlan0
sudo ip route add default via 192.168.1.1
7a. Add nameservers:
Code:
sudo gedit /etc/resolv.conf
7b. Go to the next available line and type:
Code:
nameserver 8.8.8.8
7c. Next line :
Code:
nameserver 8.8.4.4
7d. Save it
8. Go back to the terminal and edit the wpa_supplicant file:
Code:
sudo gedit /etc/wpa_supplicant/wpa_supplicant.conf
- wpa_supplicant.conf file should be like this:
Code:
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
network={
ssid="NETWORKNAME"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
psk="NETWORKPASSWORD"
}
9. And finally, to connect to your network, run
Code:
sudo dhcpcd
Open up a web browser and enjoy!
:good: :good: :good:
WiFi
I am currently including WiFi in the main guide as it's something everyone needs :laugh:
Soul_Est said:
I was hoping to contribute this weekend but unfortunately my only machine is down after mucking up the /lib folder when heimdall. To add insult to injury, I have no backups. Installing Arch Linux or Debian and configuring everything to my liking again will take a few hours.
Sent from my GT-N8010 using Tapatalk 2
Click to expand...
Click to collapse
I will be happy if you join :good:
thermatk said:
I will be happy if you join :good:
Click to expand...
Click to collapse
I'll get right on the Arch Linux instructions once I get an Arch based OS installed. Hopefully that'll be tomorrow.
Written on my Galaxy Note 10.1
is this project dead ?
Equilibrio said:
is this project dead ?
Click to expand...
Click to collapse
Great job! This is awesome.
Anyone else having dependency conflicts with bluez and obexd-client?
cctoro said:
Great job! This is awesome.
Anyone else having dependency conflicts with bluez and obexd-client?
Click to expand...
Click to collapse
I did before but it really depends on what you have install at the time when you do the update.
Having a small issue
Ok, so I followed all the instructions and set the kernel up to boot from mmcblk1p2 (my ext4 partition on my sdcard I made for linux), and used dd to copy the prebuilt arch to the partition, and it boots and eveything seems to work but the wifi.... I repeated the process from the beginning all over and recompiled to make sure i didn't miss anything, but still no wifi... And since I'm using the prebuilt image copied to the sdcard for the distro, and everything works in it if i boot the .img from the internal storage and use the premade recovery, I'm assuming maybe there's something missing from compiling the kernel? In either case, if anyone has any ideas about this, please help, or if someone can make a properly compiled recovery.img that boots from mmcblk1p2, that would be super awesome.... I'm only mediocre in linux skill so any help would be appreciated!
K, so i was an idiot and forgot to copy the compiled kernel modules to /lib........ OOPS!
Arch linux distro booting from mmcblk1p2 with 1p3 as swap... all work awesome! Working on dri2 for the mali now.....
Sent from my GT-N8013 using xda app-developers app
Could you post a prepared .IMG, possibly? Thanks.
Sent from my GT-N8013 using xda app-developers app
This is a guide about getting a Linux distribution up and running on your Nexus 9. The goal of this thread is to give a basic understanding about how to get a basic system running, but not working throughout all the kinks that come with doing so on tablet style hardware.
This guide will be non-destructive, and won't touch the data on your tablet. Unless of course you've yet to unlock your bootloader, which if that is the case then shame on you.
Some prerequisites before starting this project with your Nexus 9
A Linux distribution running on your computer. Either in a virtual machine or as your main OS.
A USB flash drive
USB OTG cable
Some things that are nice to have
USB hub
USB keyboard
USB mouse
USB network card
Headphone UART cable
A brief overview about what we are going to be doing here.
First we are going to be building an initramfs. This is a small filesystem with a bare minimum set of tools that can be loaded in to RAM space and use. We will be using this while we are initially getting our kernel up and running, to make sure we didn't mess anything up.
Next we will move on to building the actual kernel for the device. We will be running a Android kernel since Nvidia hasn't been the quickest on their attempt to upstreaming everything required to run this device on a upstream Linux kernel. So we'll be running a 3.10 kernel, which is a heck of a lot better than some 3.0 or 3.4 thing that older devices are on.
Third we will be building our rootfs that will run from an external USB storage device, so we don't affect any data actually on the tablet. I may also add to the guide how to partition your internal storage space so we can use that instead.
[Step 0/4]
We need to set up our build environment on our host Linux distribution before we begin anything. I'm going to assume that the host Linux system we are running is Debian/Ubuntu based, so we'll be using apt to grab our packages we need.
Code:
sudo apt-get install gcc g++ git gcc-4.9-aarch64-linux-gnu g++-4.9-aarch64-linux-gnu libncurses5-dev
This installs the host gcc and AArch64 cross compiler, along with git. We will need these tools to build everything required.
Things that don't work.
Rebooting
Touchscreen
Way more things that people care about
The first step that we will be doing is building our filesystem that we will load in to memory for testing.
This is typically called an initramfs, which tends to be a compressed filesystem that gets copied in to a kernel image once the kernel is built. We won't be using this image for long, as it is mostly to make sure we have everything working correctly before jumping to a full linux distribution.
This step is technically unnecessary, but it brings you up to speed with what initially needs to be done to get something running.
So starting off, we are going to need to pick a target for the filesystem. I've decided to go with buildroot since it is a project that is really easy to get built.
Steps Overview
Clone buildroot with git
Setup buildroot to cross compile
Set up basic options
Compile!
1)*Clone buildroot from github.
Code:
git clone https://github.com/buildroot/buildroot.git
cd buildroot
2)*Start configuring buildroot
Code:
make menuconfig
This will bring up a menu for determining how we want to build our buildroot. We have quite a few things to change.
These options enable building an AArch64 capable buildroot using the Linaro AArch64 toolchain, with it outputting a terminal to ttyFIQ0 which is the headphone UART terminal. Along with taking the filesystem and pushing it in to a cpio archive which later the linux kernel understands how to use.
Target options->Target Architecture->AArch64
Toolchain->Toolchain type->External toolchain
External toolchain automatically enables the Linaro AArch64 toolchain below it.
System configuration->getty options->TTY port->ttyFIQ0
Filesystem images->cpio the root filesystem
3)*Build the buildroot
Code:
make
This will go through downloading all the packages required to build an AArch64 buildroot. So go make a cup of tea, this should only take a few minutes depending on your internet speed and computer speed.
Once the system has gone through compiling everything, then you'll have a file available.
This file will end up in the `output/images/` folder as the file 'rootfs.cpio'. If that file isn't there then something terrible has happened.
If the file is there, then everything on this step is done! We built our temporary filesystem which we will be putting to use in the next step!
This is really the meat of the guide. Building the kernel correctly is half the battle with running a full Linux distribution on the device. We are going to be pulling our kernel from the official Android repository and changing the default configuration to suit our needs.
Steps Overview
Clone kernel with git
Configure environment for cross-compiling
Configure the kernel for building correctly
Test run kernel
1) Clone the kernel using git
This step will take quite a bit of time since it is fairly large.
Code:
git clone https://android.googlesource.com/kernel/tegra.git
cd tegra
2)*Checkout the correct branch
Code:
git checkout android-tegra-flounder-3.10-lollipop-release
3)*Set environment variables for cross-compiling the Linux kernel
Code:
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
4) Configure the kernel
Code:
make flounder_defconfig
make menuconfig
This will bring up a menu just like how the buildroot menu came up. We need to set a few options to make sure everything comes up correctly on the Nexus 9.
General setup->Cross-compiler tool prefix->aarch64-linux-gnu-
General setup->Initramfs source file(s)-><The cpio file that was built in the buildroot>
Mine was '/home/ryanh/work/N9_Kernel_Tutorial/buildroot/output/images/rootfs.cpio'
Device Drivers->Character devices->Virtual Terminal
Device Drivers->Generic Driver Options->Maintain a devtmpfs filesystem to mount at /dev
Device Drivers->Generic Driver Options->Automount devtmpfs at /dev...
Device Drivers->Network device support->Wireless LAN->Firmware path->/lib/firmware/fw_bcmdhd.bin
Device Drivers->Network device support->Wireless LAN->NVRAM path->/etc/wifi/bcmdhd.cal
Device Drivers->Character devices->Virtual terminal
Device Drivers->Watchdog Timer Support->Tegra watchdog (Disable it)
Device Drivers->Staging drivers->Android->Put the FIQ debugger into console mode by default
Device Drivers->Graphics support->Tegra Framebuffer driver
Device Drivers->Graphics support->Console display driver support->Framebuffer Console support
Device Drivers->Graphics support->Console display driver support->Map the console to the primary display device
Device Drivers->Graphics support->Console display driver support->Framebuffer Console Rotation
We've got to enable the tegra watchdog otherwise the device will reboot automatically every two minutes.
The few other things are needed for a sane Linux environment and also setting the initramfs file as our root filesystem.
5)*Compile the kernel
Code:
make -j5
If you're lucky it will build without error and you'll have a file in 'arch/arm64/boot/' named 'Image.gz-dtb' which is the final kernel file.
With this file we should be able to boot a kernel with a buildroot automatically mounted.
Test run the kernel!
This is where I recommend having your headphone UART cable, because this won't update the screen at all and it will seem like it has locked up. The cable is fairly easy to make with a little bit of know how about soldering and electronics, and will save you from tearing out your hair trying to figure out what went wrong.
Without the cable you won't be able to see any output, so either build the cable or skip this step.
To see output from the cable you need to connect to it with either gnu screen or minicom
Code:
sudo screen /dev/ttyUSB0 115200
To boot the kernel reboot in to the bootloader and then boot the kernel using fastboot
Code:
adb reboot bootloader
fastboot -c "console=ttyFIQ0,115200n8 rw" boot arch/arm64/boot/Image.gz-dtb
Once you do this, over the UART cable you'll see the Linux kernel booting and have a buildroot login terminal.
The default username is 'root' without any password.
Code:
Welcome to Buildroot
buildroot login: root
# uname -a
Linux buildroot 3.10.40-ga3846f1 #2 SMP PREEMPT Sat Dec 27 06:15:13 CST 2014 aarch64 GNU/Linux
This shows that the kernel is booting properly and jumping in to our buildroot correctly.
To go back in to Android from this area just type reboot in to the terminal instance.
The final step in getting a Linux distro is to build our root filesystem on a USB flash drive.
Steps Overview
Format flash drive as ext2/ext3/ext4
Dump Ubuntu rootfs on to the flash drive
Minor configuration
Rebuild Linux kernel with new options
The first thing we will want to be doing is formatting a flash drive to a Linux partition type. I am going to be using an ext3 partition on a 64GB USB 3.0 flash drive. I'd recommend at least an 8GB flash drive, anything smaller may have issues with fitting everything on to it.
Once you're done flashing your drive you'll need to download an Ubuntu Core image for AArch64/ARM64/ARMv8.
Download the Ubuntu Core 14.04.1 image*Here. Make sure to grab the 'arm64' tar.gz file, not the 'amd64' file.
Once you have the flash drive formatted and mounted, extract the ubuntu core image to the flash drive.
Code:
sudo tar zxf ubuntu-core-14.04.1-core-arm64.tar.gz -C Mount/
Configuring the Ubuntu Core image for the Nexus 9
Steps Overview
Terminal over UART configuration
DNS configuration
Firmware files
Add user
In order to properly get a terminal instance over the UART we have to add a package to the base Ubuntu core image.
This is a small package that all it does is open a new terminal instance over the configured getty instance. The package can be found*Here.
To install it to the root filesystem just unpack it to the root filesystem on the USB flash drive
Code:
sudo tar xf console.tar -C Mount/
We need to set up a DNS server so that the filesystem will be able to resolve addresses via DNS.
Let's just set it to Google's DNS.
Code:
sudo echo 'nameserver 8.8.8.8' >> Mount/etc/resolv.conf
We've got to grab the firmware files from the Nexus 9 in order for the device to stop spamming warnings at us in the console.
These are used for multiple things, so it is a good idea to grab them. You can grab these either from a factory image or directly from the Nexus 9. I chose to grab mine directly from the Nexus 9.
Code:
sudo mkdir Mount/lib/firmware
sudo mkdir Mount/etc/wifi
sudo adb pull /vendor/firmware Mount/lib/firmware/
sudo adb pull /system/etc/wifi/bcmdhd.cal Mount/etc/wifi/
We need to add a user to the root filesystem. This is a fairly annoying step because we actually need to chroot in to the filesystem.
There is a really nice guide to doing this on a ARMv7 filesystem*Here. This won't work for our system because we are working with ARMv8 instead.
So we are going to use that guide as a base but change it over to support what we need to do for AArch64.
First thing we've got to do is build qemu as a static binary for AArch64
This is fairly straight forward.
Code:
git clone git://git.qemu-project.org/qemu.git
cd qemu
sudo apt-get build-dep qemu
./configure --target-list=aarch64-linux-user *--static --disable-werror
make -j5
This will get us a binary in the aarch64-linux-user folder called 'qemu-aarch64'
We will need to rename this to 'qemu-arm64-static' and move it in to the '/usr/bin/' folder inside of our root partition
Once qemu is inside of the root partition, we will be able to chroot in to it and add our user.
So go in to the root directory of our filesystem we are generating, and run a few basic commands.
Set up some mounts inside of the chroot
Code:
for m in `echo 'sys dev proc'`; do sudo mount /$m ./$m -o bind; done
*Chroot in to the root filesystem
Code:
sudo LC_ALL=C chroot . /bin/bash
Now we are inside of the root filesystem, we can add the new user to it.
Let's just add a new user named 'ubuntu'. The first command will ask for a password for your user. The rest will add it to some default groups to make sure it can do things.
Code:
adduser ubuntu
addgroup ubuntu adm
addgroup ubuntu sudo
Once the user is added you can exit the root filesystem with a regular exit command, then we have to make sure to unmount all of the mounts we did prior to chrooting in to the filesystem.
Code:
for m in `echo 'sys dev proc'`; do sudo umount ./$m; done
Make sure to cleanly unmount the flash drive so everything is written to it.
Reconfigure the kernel to boot from flash drive instead of initramfs
1)*Go in to the kernel configuration
Code:
make menuconfig
Change the configuration to remove the initramfs
General Setup->Initial RAM filesystem and RAM disk (initramfs/initrd) support (Disable it)
Then exit the menu and rebuild the kernel
Code:
make -j5
Running the Ubuntu Core Image
So with the device sitting at the bootloader we will need to boot the new kernel
Code:
fastboot -c "fbcon=rotate:1 root=/dev/sda1 rootwait rw" boot arch/arm64/boot/Image.gz-dtb
This will boot the kernel and then it'll wait until you plug in the flash drive to continue booting.
So plug the USB hub in to the USB OTG cable. Then plug your USB flash drive and USB keyboard in to the USB hub.
After that plug the USB OTG cable in to the tablet and it will continue booting.
Give it roughly 20-60 seconds and it will show a login prompt on the devices screen.
You'll be able to login to the core image with the user you created earlier.
With some packages installed like the xubuntu-desktop environment you can have a full desktop available.
Reserved for QA - Additional Information - Misc
Information
Hardware acceleration
Potentially hardware acceleration should be possible using the Nouveau video driver. This is completely untested, and the Nouveau version included with Ubuntu 14.04 isn't new enough to have GK20a support. One would most likely need to build Nouveau from ToT to get support.
Known Issues
If something tries enabling the wifi chipset then the kernel will hardlock and cause the device to reboot. It may be best to disable the broadcom driver in the kernel until that is figured out.
Bluetooth doesn't seem to work. Not sure why not. Seems to show up as a device, but it can't be used.
Wow thanks for taking the time to post this tuturial.
Greatly apriciated.
Nice work, excellent writeup.
Cant wait to try!!
---------- Post added at 08:35 PM ---------- Previous post was at 08:31 PM ----------
Where did you get your headphone UART cable
Great work sonic, been waiting for this. Will try and report back.
I took some time to figure out how to fix the integrated wireless LAN in the tablet.
This requires grabbing an additional file from the tablet and configuring a few kernel options so they know where the new file locations are since previously they are configured to Android specific locations.
Seems to work fine on my 802.11n 2.4Ghz network.
Running into a snag while compiling the kernel. It always fails at this exact spot on Ubuntu 14.10. Any ideas? (first time compiling a kernel from source )
{
"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"
}
farmerbb said:
Running into a snag while compiling the kernel. It always fails at this exact spot on Ubuntu 14.10. Any ideas? (first time compiling a kernel from source )
Click to expand...
Click to collapse
Note: that does not tell me what failed
When the build failes can you do
Code:
make
Then give me the output
USBhost said:
Note: that does not tell me what failed
When the build failes can you do
Code:
make
Then give me the output
Click to expand...
Click to collapse
OK, here's what failed. Looks like an error in qcom_usb_modem_power.c:
Looks like it's having a fit in a required module that is enabled for the tegra platform.
Looks like a new warning that has cropped up in a newer version of GCC? My AArch64 gcc version that I'm running is 4.8.2. I can install 4.9.1 and test there but it will have to be later.
GCC is definitely right in this case though, Qualcomm managed to screw up a basic memset function call. The zero is supposed to be the middle argument, and GCC recognizes it as an warning now. Which gets upgraded to an error with some configuration.
If you know light C/C++ you can change those two lines that it is complaining about to be correct.
Should be
memset(modem->ftrace_cmd, 0, sizeof(modem->ftrace_cmd));
and
memset(modem->msr_info_list, 0, sizeof(modem->msr_info_list));
For those two lines at 1912 and 1915 respectively.
Looks like I'm going to have to start a patch set for this to work around Qualcomm failing.
sonicadvance1 said:
Looks like it's having a fit in a required module that is enabled for the tegra platform.
Looks like a new warning that has cropped up in a newer version of GCC? My AArch64 gcc version that I'm running is 4.8.2. I can install 4.9.1 and test there but it will have to be later.
GCC is definitely right in this case though, Qualcomm managed to screw up a basic memset function call. The zero is supposed to be the middle argument, and GCC recognizes it as an warning now. Which gets upgraded to an error with some configuration.
If you know light C/C++ you can change those two lines that it is complaining about to be correct.
Should be
memset(modem->ftrace_cmd, 0, sizeof(modem->ftrace_cmd));
and
memset(modem->msr_info_list, 0, sizeof(modem->msr_info_list));
For those two lines at 1912 and 1915 respectively.
Looks like I'm going to have to start a patch set for this to work around Qualcomm failing.
Click to expand...
Click to collapse
I made the changes to qcom_usb_modem_power.c as you listed, and got the kernel to compile okay.
Starting from a fresh Ubuntu 14.10 install (inside a VM), I ended up installing these additional packages in addition to the ones you list in step 0:
Code:
libncurses5-dev libc6:i386 libstdc++6:i386 zlib1g:i386 qemu binfmt-support qemu-user-static android-tools-adb android-tools-fastboot
To get the kernel to compile, I also needed to symlink aarch64-linux-gnu-gcc-4.9 to aarch64-linux-gnu-gcc in /usr/bin, for make to recognize the correct gcc program.
But anyway, I've gotten my N9 booted to the Ubuntu login prompt Now I just need to grab a USB keyboard so that I can actually login!
Thanks so much for the guide! Can't wait for MultiROM to be ported to our device, to make this easier to boot
farmerbb said:
I made the changes to qcom_usb_modem_power.c as you listed, and got the kernel to compile okay.
Starting from a fresh Ubuntu 14.10 install (inside a VM), I ended up installing these additional packages in addition to the ones you list in step 0:
Code:
libncurses5-dev libc6:i386 libstdc++6:i386 zlib1g:i386 qemu binfmt-support qemu-user-static android-tools-adb android-tools-fastboot
To get the kernel to compile, I also needed to symlink aarch64-linux-gnu-gcc-4.9 to aarch64-linux-gnu-gcc in /usr/bin, for make to recognize the correct gcc program.
But anyway, I've gotten my N9 booted to the Ubuntu login prompt Now I just need to grab a USB keyboard so that I can actually login!
Thanks so much for the guide! Can't wait for MultiROM to be ported to our device, to make this easier to boot
Click to expand...
Click to collapse
ii cant wait
Excellent guide. Thank you very much.
It appears the "*" in this configure command below may be a typo?
sonicadvance1 said:
Code:
git clone git://git.qemu-project.org/qemu.git
cd qemu
sudo apt-get build-dep qemu
./configure --target-list=aarch64-linux-user *--static --disable-werror
make -j5
Click to expand...
Click to collapse
Anyway, I am running into a more serious issue (Problem resolved. See bottom.) executing dynamically build aarch64 binaries. On my 14.10 x86 machine, I am able to execute statically build aarch64 binaries using my new qemu-aarch64 emulator. I am not able to execute dynamically build aarch64 binaries. For instance, when I try to execute bin/bash from the mounted root filesystem directly on the host, it will complain:
/lib/ld-linux-aarch64.so.1: No such file or directory
Now this is all right, because I don't have the required aarch64 shared libs on my x86 machine. So I copied qemu-aarch64 to /usr/bin/qemu-aarch64-static on the mounted root filesystem. However, when I run chroot (executing the same /bin/bash):
sonicadvance1 said:
Code:
sudo LC_ALL=C chroot . /bin/bash
Now we are inside of the root filesystem, we can add the new user to it.
Click to expand...
Click to collapse
...I am getting this:
chroot: failed to run command ‘/bin/bash’: No such file or directory
I think this is due to the same issue as above: that qemu is looking for aarch64 shared libs (/lib/ld-linux-aarch64.so.1 is needed to run bash) on my host machine. Should it not, due to chroot, look for them in the mounted root filesystem (where they actually are)?
Other than this... my ARM64 kernel is booting fine. The only problem is, that I cannot login to it yet, because I wasn't able to add a new user.
Edit: Interestingly, the following "works":
Code:
$ sudo chroot . usr/bin/qemu-aarch64-static /bin/bash
bash: /usr/bin/groups: No such file or directory
[email protected]:/#
Now inside the chroot running the aarch64 variant of /bin/bash, I am still unable to start any aarch64 executables. But tab-completion works and I am able to find and run /usr/bin/qemu-aarch64-static (the x86 binary). Could this be a problem with any binfmts mappings inside chroot? Odd.
Edit 2: Solved. Just tried from another machine (10.04) and here, everything is working perfectly. I probably have chroot hosed on my 1st machine. Excellent guide. One last note: if you don't have qemu installed on your host machine, you may need to run the following:
Code:
sudo apt-get install qemu binfmt-support qemu-user-static
t1mur said:
Excellent guide. Thank you very much.
It appears the "*" in this configure command below may be a typo?
Anyway, I am running into a more serious issue executing dynamically build aarch64 binaries. On my 14.10 x86 machine, I am able to execute statically build aarch64 binaries using my new qemu-aarch64 emulator. I am not able to execute dynamically build aarch64 binaries. For instance, when I try to execute bin/bash from the mounted root filesystem directly on the host, it will complain:
/lib/ld-linux-aarch64.so.1: No such file or directory
Now this is all right, because I don't have the required aarch64 shared libs on my x86 machine. So I copied qemu-aarch64 to /usr/bin/qemu-aarch64-static on the mounted root filesystem. However, when I run chroot (executing the same /bin/bash):
...I am getting this:
chroot: failed to run command ‘/bin/bash’: No such file or directory
I think this is due to the same issue as above: that qemu is looking for aarch64 shared libs (/lib/ld-linux-aarch64.so.1 is needed to run bash) on my host machine. Should it not, due to chroot, look for them in the mounted root filesystem (where they actually are)?
Other than this... my ARM64 kernel is booting fine. The only problem is, that I cannot login to it yet, because I wasn't able to add a new user.
Edit: Interestingly, the following "works":
Code:
$ sudo chroot . usr/bin/qemu-aarch64-static /bin/bash
bash: /usr/bin/groups: No such file or directory
[email protected]:/#
Now inside the chroot running the aarch64 variant of /bin/bash, I am still unable to start any aarch64 executables. But tab-completion works and I am able to find and run /usr/bin/qemu-aarch64-static (the x86 binary). Could this be a problem with any binfmts mappings inside chroot? Odd.
Click to expand...
Click to collapse
I ran into these exact issues as well, and was eventually able to get the chroot working properly
Make sure you have the qemu, binfmt-support, qemu-user-static packages installed, and run 'update-binfmts --display' to ensure that aarch64 support is registered properly. Also make sure you've named the 'qemu-aarch64' binary as 'qemu-arm64-static' (not 'qemu-aarch64-static') at usr/bin on the flash drive (the Ubuntu Core image recognizes its architecture as arm64, not aarch64)
farmerbb said:
I ran into these exact issues as well, and was eventually able to get the chroot working properly
Make sure you have the qemu, binfmt-support, qemu-user-static packages installed, and run 'update-binfmts --display' to ensure that aarch64 support is registered properly. Also make sure you've named the 'qemu-aarch64' binary as 'qemu-arm64-static' (not 'qemu-aarch64-static') at usr/bin on the flash drive (the Ubuntu Core image recognizes its architecture as arm64, not aarch64)
Click to expand...
Click to collapse
Ah... it's really good to know one isn't alone. Hehe. Well, it looks like 14.10 is better suited for compiling the arm kernel (gcc-4.9-aarch64 etc.), but doing the chroot is smoother on 14.04.
But how do I get wifi and/or USB ethernet up? And why do have to look at this?
unable to stat /etc/sudoers: no such file or directory
Did you get this too?
t1mur said:
Ah... it's really good to know one isn't alone. Hehe. Well, it looks like 14.10 is better suited for compiling the arm kernel (gcc-4.9-aarch64 etc.), but doing the chroot is smoother on 14.04.
But how do I get wifi and/or USB ethernet up? And why do have to look at this?
unable to stat /etc/sudoers: no such file or directory
Did you get this too?
Click to expand...
Click to collapse
I'm still working on getting networking and X.org running myself. It will recognize my ASIX USB adapter (in the dmesg log) but eth0 doesn't show up and 'ifconfig eth0 up' doesn't work. Haven't tried Wi-Fi yet. My low-level Linux knowledge isn't all that great However, I can still chroot back into the filesystem on my PC and update/install packages, etc. in the meantime.
No I don't see the /etc/sudoers error.