Develop Bugs

Google Android and Linux for Kaiser Volume II

The original thread:http://forum.xda-developers.com/showthread.php?t=396782 needs an abridged version.
==================================================
Go to http://www.androidonhtc.com/ if you're just starting as it has the latest info. This thread is to highlight the info from the original thread only.
Latest Builds
Port Status
==================================================
Compiling Android Kernel for Kaiser
Modify initrd.gz files and CPIO handling
system.img mounting, editing and rebuilding with ext2/3
system.img mounting, editing and rebuilding with cramfs
Howto: Pull from git (new/update/resync)
[WIP] Configuring WiFi Interface
==================================================

system.img mounting, editing and rebuilding with ext2/3
seidler2547: Post:
Actually I've played with Android a bit for now, and I changed to ext3. It doesn't only work - it's much faster, too! Startup time during the blinking android is about half of what it was before.
How-To:
Code:
Code:
cd /tmp
# prepare dirs
mkdir a-sys
mkdir a-ext
# prepare image
dd if=/dev/zero of=/where/is/sdcard/system.img.new bs=1M count=64
mkfs.ext3 /where/is/sdcard/system.img.new
# mount old image and copy to new
mount -o loop /where/is/the/system.img a-sys
mount -o loop /where/is/sdcard/system.img.new a-ext
cp -a a-sys/* a-ext/
Now you can unmount the old image and happily edit in the new image. Don't forget to rename the system.img.new to system.img (after you have unmounted it).
In your initrd, in file init, where it says
Code:
losetup /dev/block/loop1 /sdcard/system.img
...
mount -t cramfs -o ro,noatime,nodiratime /dev/block/loop1 /system
change "-t cramfs" to "-t ext2" or "-t ext3". You can also change the path (/sdcard/system.img) there.
Click to expand...
Click to collapse

Modify initrd.gz files and CPIO handling
dcordes: Post:
There is no magick in the initrd files. They are .cpio.gz files, gzipped cpio balls. To extract a .cpio.gz file named initrd-android.cpio.gz simply do
Code:
gunzip initrd-android.cpio.gz && cpio -i < initrd.android.cpio
Then you have the extracted rootfs. The reverse way would be, assuming you are inside your rootfs folder:
Code:
find ./ | cpio -H newc -o | gzip > ../my-initr-android-with-custom-stuffs.cpio.gz
And yes, you can remove and add applications you find that way.
Click to expand...
Click to collapse

system.img mounting, editing and rebuilding with cramfs
dzo: Post:
Hi, you can't just use mkcramfs on the system folder because the permissions will be wrong. This is the script I use:
Code:
Code:
out/host/linux-x86/bin/genext2fs -d out/target/product/generic/system -b 80000 -a system.ext2
mount -o loop system.ext2 /mnt/system
cp /mnt/system/usr/keychars/qwerty2.kcm.bin /mnt/system/usr/keychars/vogue-ts.kcm.bin
cp com.google.android.maps.jar /mnt/system/framework
cp Maps.apk Street.apk /mnt/system/app
mkfs.cramfs /mnt/system system.img
umount /mnt/system
#pcp system.img :/Storage\ Card/system.img
This also puts the maps app in (just copy from one of my images) and the vogue keymap. Without the source for the ril you will also need to copy my RIL (libreference-ril.so).
Click to expand...
Click to collapse

[WIP] Configuring WiFi Interface
This has been able to initialize the interface, assign arbitrary IP addresses but can not go further at the moment.
Code:
# ifconfig tiwlan0 192.168.1.100
# ifconfig tiwlan0 up
error: SIOCSIFFLAGS (Cannot assign requested address)
# ifconfig tiwlan0
tiwlan0: ip 192.168.1.100 mask 255.255.255.0 flags (down broadcast multicast)
dmesg will show:
Code:
wlan: no version for "struct_module" found: kernel tainted.
TIWLAN: Driver loading
trout_wifi_power: 1
trout_wifi_reset: 0
trout_wifi_set_carddetect: 1
TIWLAN: Found SDIO control (vendor 0x104c, device 0x9066)
TIWLAN: Driver initialized (rc 0)
TIWLAN: Driver loaded
Android's built-in wireless settings seem to disable the interface beyond just interfering with it, therefore it's best to stay with terminal and using 'ash' will give you a shell with command history (up/down scroll).
markya23: Post:
Need to create a folder in you system image package called /etc/wifi and copy tiwlan.ini, wpa_supplicant.conf and fw1251r1c.bin.
Need to copy the wlan.ko to /lib/modules in the system image (create the dir if required).
Create the new system image and boot Android. Start the dev console and type:
Code:
cp /system/etc/wifi/wpa_supplicant.conf /data/misc/wifi/wpa_supplicant.conf
insmod /system/lib/modules/wlan.ko
wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -e /proc/calibration -i /system/etc/wifi/tiwlan.ini
cd /data/local/tmp
wpa_supplicant -f -Dtiwlan0 -itiwlan0 -c/data/misc/wifi/wpa_supplicant.conf &
ifconfig tiwlan0 192.168.1.100 netmask 255.255.255.0
ifconfig tiwlan0 up
Click to expand...
Click to collapse

Compiling Android Kernel for Kaiser
dwaradzyn: Post:
Here are brief instructions on how to compile android kernel for Kaiser from git.linuxtogo.org repository. I assume that running OS is Linux and it has everything required to build x86 or ia64 kernel. Beside that latest git software should be installed. The shell is assumed to be bash.
1. Let's start with creating a directory for kernel in home directory:
Code:
mkdir ~/android-kernel
cd android-kernel
2. Next thing is to get the sources from repository. To make it happen (this could take a while, it downloads 280MB):
Code:
git clone git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git
OUTPUT:
Code:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/
remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016)
Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done.
Resolving deltas: 100% (755115/755115), done.
Checking out files: 100% (22584/22584), done.
3. The htc-msm branch is of our interest (again it could take a few seconds):
Click to expand...
Click to collapse
*** Update, poly_poly-man states we are working off of htc-vogue not htc-msm. I'm leaving the original code here but I would urge you to modify the next line as poly has suggested:
Code:
cd kernel
git checkout -b htc-msm origin/htc-msm
OUTPUT:
Code:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm.
Switched to a new branch "htc-msm"
4. Let's take care of arm toolchain. Download this file (64MB) into ~/android-kernel:
Code:
[url]http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2[/url]
Unpack it:
Code:
cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
5. Compile the kernel
Prepare default .config for Kaiser:
Code:
cd ~/android-kernel/kernel
make htckaiser_defconfig ARCH=arm
OUTPUT:
Code:
........
lots of output
........
# configuration written to .config
#
And finally compile the kernel to get zImage (takes a minute or two):
Code:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
OUTPUT:
Code:
........
lots of output
........
Kernel: arch/arm/boot/zImage is ready
Now copy ~/android-kernel/kernel/arch/arm/boot/zImage to your phone and play with it.
Some ending tips:
A. You can compile earlier versions of sources in repository. To do that click on one of "commit" links on page:
Code:
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=summary
and read commit id (for example: f9d1bcea9342348623f5a57588044f76d8b649cd):
Code:
git reset --hard f9d1bcea9342348623f5a57588044f76d8b649cd
It will override any changes you made to files in ~/android-kernel/kernel.
B. Once you have downloaded git repository, you can swallow latest changes by issuing:
Code:
cd ~/android-kernel/kernel
git pull
C. If your machine has more than one cpus/cores you can speed up kernel compilation by adding -j <cores/cpus_number>, for example (dual core):
Code:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse

bad internet makes for double post. Please delete

wrong directions for kernel - we are working off of htc-vogue branch... not htc-msm...

can we make the internet work through the usb cable?

how does android know which device node is gps? it's not picking it up for kaiser...
if you enable gps in winmo (or enable it in smd0 - I believe the command is @startgps), smd7 is a nmea stream (acts as a serial GPS).... could a symlink possibly be the right solution to this?

Howto: Pull from git (new/update/resync)
This will download the latest from git:
dwaradzyn: Post:
Here are brief instructions on how to compile android kernel for Kaiser from git.linuxtogo.org repository. I assume that running OS is Linux and it has everything required to build x86 or ia64 kernel. Beside that latest git software should be installed. The shell is assumed to be bash.
1. Let's start with creating a directory for kernel in home directory:
Code:
mkdir ~/android-kernel
cd android-kernel
2. Next thing is to get the sources from repository. To make it happen (this could take a while, it downloads 280MB):
Code:
git clone git://git.linuxtogo.org/home/grou
ps/mobile-linux/kernel.git
OUTPUT:
Code:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/
remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016)
Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done.
Resolving deltas: 100% (755115/755115), done.
Checking out files: 100% (22584/22584), done.
3. The htc-msm branch is of our interest (again it could take a few seconds):
Code:
cd kernel
git checkout -b htc-msm origin/htc-msm
OUTPUT:
Code:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm.
Switched to a new branch "htc-msm"
4. Let's take care of arm toolchain. Download this file (64MB) into ~/android-kernel:
Code:
http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
Unpack it:
Code:
cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
5. Compile the kernel
Prepare default .config for Kaiser:
Code:
cd ~/android-kernel/kernel
make htckaiser_defconfig ARCH=arm
OUTPUT:
Code:
........
lots of output
........
# configuration written to .config
#
And finally compile the kernel to get zImage (takes a minute or two):
Code:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
OUTPUT:
Code:
........
lots of output
........
Kernel: arch/arm/boot/zImage is ready
Now copy ~/android-kernel/kernel/arch/arm/boot/zImage to your phone and play with it.
Some ending tips:
A. You can compile earlier versions of sources in repository. To do that click on one of "commit" links on page:
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=summary
and read commit id (for example: f9d1bcea9342348623f5a57588044f76d8b649cd):
Code:
git reset --hard f9d1bcea9342348623f5a57588044f76d8b649cd
It will override any changes you made to files in ~/android-kernel/kernel.
B. Once you have downloaded git repository, you can swallow latest changes by issuing:
Code:
cd ~/android-kernel/kernel
git pull
C. If your machine has more than one cpus/cores you can speed up kernel compilation by adding -j <cores/cpus_number>, for example (dual core):
Code:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse
poly_poly-man: Post:
This will pull from git which will update/resync a git pull:
Code:
mkdir foo
cd foo
git init
git pull git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git htc-vogue
Click to expand...
Click to collapse

I'll follow-up with some nice, full instructions...
1. prerequisites: arm-none-linux-gnueabi toolchain (gentoo users can use crossdev - otherwise.... uhh... idk?), git, a host toolchain (gentoo users have this by default, most other distros have this under "development" in their package managment... if you have gcc, you're probably set).
2. mkdir kernel
cd kernel
git init
git pull git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git htc-vogue
3. make vogue_defconfig
4. make
5. cp arch/arm/boot/bzImage /path/to/sdcard/
6. to update, run the git pull command by itself again, run make (may have to do the config line again if it's changed) and cp.

Thanks for the post poly. I don't know how that's different from what the post I referenced as I'm not +4 at this stuff.. I did what you posted with android kernel from git and got a 1.2mb zImage that crashed HaRET.. I'm guessing this is my bad. What could I have overlooked? Thanks

enatefox said:
Thanks for the post poly. I don't know how that's different from what the post I referenced as I'm not +4 at this stuff.. I did what you posted with android kernel from git and got a 1.2mb zImage that crashed HaRET.. I'm guessing this is my bad. What could I have overlooked? Thanks
Click to expand...
Click to collapse
where'd you get your toolchain?
does building a regular (host arch) kernel work?
Also - what's the proper way to build a system.img by hand? I'm looking to modify that quite a bit, but can't find a persistent source tree besides the main one, which is seriously crippled.

I thought you were one of the experts, lol. I've been left with no support on how dzo, et all are customizing kernels so I've been in read only mode on the 'other thread' looking elsewhere for support.
Just wanted to ask you first, what's with the Dream radio? I know you posted the mods censored it but what's with the sig now? It piqued my interest... as I'm using (shudder) winmo on the regular while Android is being worked on I was hoping it would be worth looking into if it doesn't brick my phone.
Answers to your questions:
As I said, my own zImage is no go. Check this link (not for our phone but the links at the bottom are pretty useful): http://wiki.xda-developers.com/index.php?pagename=BlackstoneLinux#Runningx20.Linuxx20.onx20.blackstone
I got the toolchain from the steps I (re)posted on this thread:
http://forum.xda-developers.com/showpost.php?p=2269384&postcount=184 so that gave me a 1.2mb zImage where everyone's been posting 1.4mb-- I know there's something not right. As far as building a system.img by hand? I've taken existing ones either from posted bundles or from Android src directly. Maybe I suck (real possibility) but cupcake and 1.0 have been pretty flaky for me (there are system.img's included in the source). You should know how to mount and edit them though (look at the first post on this thread). My experience is the git source is useless unless you've got a G1-- I don't know how to make it run on Tilts. If it does work, then the answer to your question about host arch compiling is no-- it has to be ARMv5 for our phones. That's where this line comes in:
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse
Seriously, I need help learning how to modify the kernel-- I've been a "google will have the answer for me" Linux bystander for a while and while I'm good at what I've done I'm not so good at this uncharted territory. I'm really looking for help to figure out how to compile modules (saurik and dzo never got back to me about that) and all I've gotten is "wait while I do it myself" which is cool they're working on it but we're obviously here to work on it too.
I've even been trying to get Debian installed (familiar territory for me) so I can at least get stuff working. You do know that Android is nothing but a Java VM layer for Linux and it will (could be) put on any self-respecting distro. Personally, I want Debian on my phone with an Android chroot as that would trump all.
Sorry to rant but you seem more about figuring this out like me and I don't know who else is really working on this besides the dev-gods who have no tutorials.

enatefox said:
I thought you were one of the experts, lol. I've been left with no support on how dzo, et all are customizing kernels so I've been in read only mode on the 'other thread' looking elsewhere for support.
Just wanted to ask you first, what's with the Dream radio? I know you posted the mods censored it but what's with the sig now? It piqued my interest... as I'm using (shudder) winmo on the regular while Android is being worked on I was hoping it would be worth looking into if it doesn't brick my phone.
Click to expand...
Click to collapse
It never actually worked... maybe. My phone was reporting the wrong version on a *different* radio (1.65.21.18, was saying 19) before, and trying to flash this changed the version to be correct. 0x300 radios will never flash, and this as a 0x301 *will* brick your phone. Then again... like 2 people reported epic success... In other words, no, it never really existed.
Answers to your questions:
As I said, my own zImage is no go. Check this link (not for our phone but the links at the bottom are pretty useful): http://wiki.xda-developers.com/index.php?pagename=BlackstoneLinux#Runningx20.Linuxx20.onx20.blackstone
I got the toolchain from the steps I (re)posted on this thread:
http://forum.xda-developers.com/showpost.php?p=2269384&postcount=184 so that gave me a 1.2mb zImage where everyone's been posting 1.4mb-- I know there's something not right. As far as building a system.img by hand? I've taken existing ones either from posted bundles or from Android src directly. Maybe I suck (real possibility) but cupcake and 1.0 have been pretty flaky for me (there are system.img's included in the source). You should know how to mount and edit them though (look at the first post on this thread). My experience is the git source is useless unless you've got a G1-- I don't know how to make it run on Tilts. If it does work, then the answer to your question about host arch compiling is no-- it has to be ARMv5 for our phones. That's where this line comes in:
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
Click to expand...
Click to collapse
unnecessary - zImage is implied, and the other two are in the Makefile already.
Seriously, I need help learning how to modify the kernel-- I've been a "google will have the answer for me" Linux bystander for a while and while I'm good at what I've done I'm not so good at this uncharted territory. I'm really looking for help to figure out how to compile modules (saurik and dzo never got back to me about that) and all I've gotten is "wait while I do it myself" which is cool they're working on it but we're obviously here to work on it too.
Click to expand...
Click to collapse
we have 0 modules at the moment (but perhaps support - I forget). Just compile stuff in - modules are very bad.
I've even been trying to get Debian installed (familiar territory for me) so I can at least get stuff working. You do know that Android is nothing but a Java VM layer for Linux and it will (could be) put on any self-respecting distro. Personally, I want Debian on my phone with an Android chroot as that would trump all.
Click to expand...
Click to collapse
It's a nice idea, but remember where a lot of the current coding is taking place - the ril, which is part of android (the system.img, at least), and doesn't go across to other distros quite as well. I think running Dalvik alongside whatever you're running in Debian might be too much for this phone's epically slow processor (compared to msm7201a).
Sorry to rant but you seem more about figuring this out like me and I don't know who else is really working on this besides the dev-gods who have no tutorials.
Click to expand...
Click to collapse
my instructions should work - they are what I use, at least.

Someone should change the instructions to (in the Wiki they are correct):
make ARCH=arm vogue_defconfig
I compiled my kernel, booted in Ubuntu, but had no touchscreen at all, I am not sure if the vogue_defconfig file takes care of everything necessary, so now I am checking everything via menuconfig to see whether eveything is all right or not.
DOMy

Do not Use Ext3 on SD cards
enatefox said:
seidler2547: Post:
Click to expand...
Click to collapse
You should NOT be using ext3 on any sort of flash ram device. You will wear out the medium. Journaling is just a bad idea in this sort of situation.
http://www.handhelds.org/hypermail/familiar/273/27320.html
3) ext3 is "very bad" because of the way it does journaling. It does journal, which seems like a good idea, but it also automatically periodically writes a lot of things out to the same secors on disk. I don't have first hand experience with this, but I remember somebody familiar with ext3 writing about this. It's method of journaling is not particularly intended for any kind of wear leveling at all.
Click to expand...
Click to collapse
http://www.mail-archive.com/[email protected]/msg38988.html
There are three disadvantages with the journaled file system:
- lower performance at write time, since there is the extra work of the
journal
- increased chance of damaging the SD card due to extra use of the
journal causing wearing
- increased space usage (for the journal)
Click to expand...
Click to collapse
And this is the general consensus within most of linux on ext3 and wearing mediums. I'm not sure if Andriod's kernel can do ext4, but ext4 can run without a journal.
Yet another reason not to use ext3 is that is near impossible to undelete something, something you can do with ext2.
-edit-
It looks like Android can use Ext4
http://thatsbadass.com/android/tag/ext4/

haha! is a good job, i like it

can't run android on my kaiser
hi folks,
i have read many threads here and on androidonhtc.com, i have read also the install instructions, but it seems im too stupid to run it.
it fails on "can't find system.img". i wil not flash it, i will run it from sd-card.
so, please can anyone attached an actually zip file which i just unpack und run haret.exe to work android on my kaiser ?
thanks and best regards
lenzen

[KERNEL] is Tiny-shmem good for android?

Hi fellows,
I have made a patch to enable the use of Tiny-SHMEM instead the full SHMEM filesystem in android kernels. I think we can gain some performance here. It seems to be working, but I have some thoughts to share with you.
1) It seems that android uses /dev/ashmem rather than /dev/shm, and the only two functions of mm/shmem.c needed by mm/ashmem.c is available on tiny-shmem.
2) Android also needs to mount filesystem as tmpfs. If we use tiny-shmem, than tmpfs will use ramfs code. So, we will support online growing, but we can not limit sizes. I have just one partition (/app-cache) that has size limits. The question is: we actually need size limits?
If anyone like, I can release the patch after some testing I'm doing.
Thanks,
Ronan

I can help u test on, well you know!

Hi diz!
So, I'm attaching a patch for GT-P1000 kernels. It should be fine on every version.
It just modify the Init/Kconfig file since the tiny-shmem is already on source code and you just need to adjust the configuration to define CONFIG_TINY_SHMEM.
If you want to test, apply this patch into your kernel tree, execute 'make menuconfig', go to section:
General Setup -> Configure standard kernel features (for small systems) -> Default shmem filesystem implementation -> Tiny shmem filesystem
and then compile.

Any updates in this project??
Sent from my GT-P1000 using XDA App

jadmask3rlm said:
Any updates in this project??
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
Still need people to test it... RAMFS could induce some problems...

My latest unstable kernel version has this patch applied and tiny-shmem is selected. If anyone wants to test: http://forum.xda-developers.com/showthread.php?t=1274855
But, it is just for LATIN models!

Ronis_BR said:
Hi diz!
So, I'm attaching a patch for GT-P1000 kernels. It should be fine on every version.
It just modify the Init/Kconfig file since the tiny-shmem is already on source code and you just need to adjust the configuration to define CONFIG_TINY_SHMEM.
If you want to test, apply this patch into your kernel tree, execute 'make menuconfig', go to section:
General Setup -> Configure standard kernel features (for small systems) -> Default shmem filesystem implementation -> Tiny shmem filesystem
and then compile.
Click to expand...
Click to collapse
Hello
I have, and then someone else (just to make sure) applied the patch, but the "default shmem filesystem implementation" option is not available in general setup, after running 'make menuconfig'

dizgustipated said:
Hello
I have, and then someone else (just to make sure) applied the patch, but the "default shmem filesystem implementation" option is not available in general setup, after running 'make menuconfig'
Click to expand...
Click to collapse
yea the same happened with me too(on another device too)
so what i did
in .config
add this:
CONFIG_TINY_SHMEM=y (it should be 'is not set')

Hi diz,
This option is under Configure kernel features (for small systems). It is the last option in the menu and you can select two values. Yesterday I applied the patch in my kernel tree and it works properly.
Sent from my GT-P1000L using xda premium

AH! Btw, you must enable:
CONFIG_MMU (System type)
CONFIG_EMBEDDED (General setup)
to see the option. So, if you haven't enabled CONFIG_SWAP, than you can choose CONFIG_TINY_SHMEM, otherwise just CONFIG_SHMEM will be available.
FYI, I'm using this with tiny-shmem for 8h and nothing weird happened yet
Thanks,
Ronan

working on it now,
up to the compile part,
its a little different working with my source, than stock
quick q
how do we show users this is working or even added in their kernels?

Well, you can execute:
busybox zcat /proc/config.gz | grep SHMEM
If you see:
CONFIG_TINY_SHMEM=y
Then tiny shmem was selected and is activated.
I'll wait your results! Thanks for the help!!!!
Ronan
Sent from my GT-P1000L using xda premium

Now, when trying to compile (mine and teks way)
It says, kernel tree not clean, please run make mrproper in kernel directory.
So I do, and it erases the tiny shmem, and goes back to default p1cm7 configuration.
Lol, kernel work makes porting a rom from basecode a walk in the park!
When typing make, or make zimage, in same directory as make menuconfig, it errors and says /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc: Command not found
and
make
make: /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc: Command not found
scripts/kconfig/conf -s arch/arm/Kconfig
init/Kconfig:957:warning: choice value used outside its choice group
init/Kconfig:958:warning: defaults for choice values not supported
make: /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc: Command not found
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
Generating include/generated/mach-types.h
CC kernel/bounds.s
/bin/sh: /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc: not found
make[1]: *** [kernel/bounds.s] Error 127
make: *** [prepare0] Error 2
below is my .config file, zipped because xda cant load hidden files

Hi diz,
First,
kernel tree not clean, please run make mrproper in kernel directory.
It is because the kernel directory has a git repo and it is not clean. When you use 'make mrproper' it will remove the patch because it probably wasn't commited yet.
The easiest way to solve it is:
mv .git .gitold
<Compile the kernel>
mv .gitold .git
If you do this, this problem should be gone.
The second error seems that you are pointing the gcc cross-compiler to a wrong path in Makefile. Check where you installed the compiler and set it accordingly in Makefile by changing the value of this variable:
CROSS_COMPILE ?=
Hope it helps!
Thanks,
Ronan

By the way, your config file seems to be ok!

Change the tool chain prefix to arm-none-eabi- and compile (after doing the steps ron told)

SUCCESS!!!!!!!!
I've posted it here,
http://forum.xda-developers.com/showpost.php?p=19128294&postcount=2205

Good! Let's see what will happen now
Thanks!

Cyanogen 7 tiny_shmem kernel
I have decided to move the kernel here.
So as not to "invade" another's thread
This is only for unofficial beta cm7 port
* FILE SYSTEM
TINY_SHMEM enabled
* LCD Voltage
down to 260000 from 300000
* I/O scheduler default
"no-op"
type: busybox zcat /proc/config.gz | grep SHMEM
in your terminal emulator
you will see:
CONFIG_TINY_SHMEM=y
(means tiny shmem is activated."

dizgustipated said:
I have decided to move the kernel here.
So as not to "invade" another's thread
* FILE SYSTEM
TINY_SHMEM enabled
* LCD Voltage
down to 260000 from 300000
* I/O scheduler default
"no-op"
type: busybox zcat /proc/config.gz | grep SHMEM
in your terminal emulator
you will see:
CONFIG_TINY_SHMEM=y
(means tiny shmem is activated."
Click to expand...
Click to collapse
THIS KERNEL IS Making my WIFI Hotspot activate on MIUI for SGT
- I just have issue with the Mobile Network being broken?
- The touchscreen also broken but i'ved fixed that one
- usb tethering error = ive'd fixed it too
Can you do something on the mobile data being broken on the kernel side?
Because if i use angel666 zimage , cm modded, mobile data work but hotspot broken
If i use this its the other way around. Lol

[dev][kernel][kexec]

Last Update : August, 19, 2014
Hi,
I'm still try to bypass the MMU protection.
I have fixe a lot of bug, like memory misalignment, bad adresses allocation, dtb correction, etc...
Last sources and binaries here :
kexec-tools V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902912&stc=1&d=1408401794
kexec-tools binaries V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902913&stc=1&d=1408401794
Sorry, i have always 13 sec reboot after new kernel boot.
"cpu_proc_fin" use a "mcr p15" to init cache and proc that cause freeze.
I try to find solution for that.
Last Update : June, 22, 2014
Hi,
My sources are horrible... but i give something new.
This kexec is for stock kernel only (tested on .757). I thinks theses sources work on other kernel too.
In "kexec-tools V10.zip", you have all my sources. It's highly recommended to mod them to have something OK.
In "kexec binaries.zip", you have binaries to install
=> "kexec_load.ko" and "procfs_rw.ko" must be placed in "/system/lib/modules" folder with "chmod 777"
=> "kexec" must be placed in /system/bin" folder with "chmod 777"
=> cd /system/lib/modules
=> insmod kexec_load.ko
For sources :
Mod and adapt all you want, it's free.
You have 2 scripts in Zip : "./compil-kexec" in "kexec-tools" folder to rebuild and send in device directly (install Adbtcp on device and send by tcp with : adb connect xxx.xxx.xxx.xxx) = work perfectly with me.
"scriptZ1" is for compil stock kernel or another kernel (doomlord kernel for eg)
You must rename "custom_final_files" folder after compil to "final_file" manually ; You can have guest kernel in "custom_final_files" and stock kernel in "final_files" for "kexec-tools" path ... Don't mix a guest and host kernel please ^^
I am tired... i let you test and say if it's ok for you...
Thank a lot to munjeni for his help.
kexec-tools V10.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811994&stc=1&d=1403456181
kexec binaries.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811995&stc=1&d=1403456181
Last Update : November, 23, 2013
Hi,
For few days now, i haven't no more kernel panic with my kexec.
I have fixed few stuffs into sources, and add a lot.
These adds are, to include a "dt.img" image file into kexec load process.
This image file is a "device_tree" image to match hardware to software.
So, i assume to don't include atags into boot process, but pass bootloader informations by this DT.
I have programmed a little scan memory to found dynamicly all magic tags, because i found 3 device_tree into memory (magic is "0xd00dfeed").
These 2 device_tree are echo from first and nice structure.
The boot process need to have informations from this DT, and need all informations to initialize hardware (no HDW initialisation by the kernel)
I must first fix issues ; Regroup zImage and dt.img into memory to load a solid bloc to kexec_load module to boot into, and second, fix an offset i can't explain, 0x800 in memory causing misalignment memory
Keep tuned..
Last Update : November, 17, 2013
Hi everybody,
My kexec-tools work for Sony Xperia Z1 stock kernel "3.4.0-perf"
This tools can work on all locked bootloader for all locked device, not only Sony or Z1 models.
This kexec-tools add a kexec_load kernel module (LKM) and use a driver to grant a communication between "kexec" user program and kexec_load.ko module
what is for ?
"kexec" user program load in memory a custom kernel in zImage format, but can load ".tar" image too
This user tool load ramdisk in memory if necessary
This tool is for this purpose only, and don't keep in memory the custom kernel at device reboot.
It is a "user" program, not a "kernel" extension... So, to really do the magic, we need the host kernel (stock sony locked kernel) have a kexec_load capability to reboot in a new gest kernel (custom kernel).
Infortuntly, stock kernel don't have kexec_load capability.
Sony have compiled his stock kernel without this option, and "standard" kexec-tools "need" this option to work.
To see all system call capability of kernel, you can run theses command :
Code:
echo 0 > /proc/sys/kernel/dmesg_restrict
echo 0 > /proc/sys/kernel/kptr_restrict
cat /proc/kallsyms
Do all grep you want here.
The "echo 0" "restrict" is here to unmask logical adresses to "system calls"
Like you can see, "__NR_kexec_load" capability isn't here.
To add kexec_load capability in stock locked kernel, we need to add manualy a kernel module wich add this function into the kernel.
Why ? Because the way to keep in memory a custom kernel need to know a lot of parameters, and keep a specific memory range alive at reboot.
Only kernel can do this.
All user program will be terminated at reboot.
"Standard" kexec_load.ko module use a method to implement the "__NR_kexec_load" function in system call table.
Since 2.6.0 kernel, linux for security reason, have locked in memory the "system_call_table" ; No more add or modification is authorized.
If kexec tool try to add a value, "kexec_load" for us, we causes a kernel panic, and reboot device.
For this reason, i have modify kexec user program and kexec_load module to implement a driver to talk to each other.
this driver replace syscall method, and we no more need to use a system call table.
For this reason, this tool is now compatible with modern kernel like our "3.4.0"
For this reason, this tool must work for other device (Xperia X, P, S, etc...) and another brand
For this reason, if kernel is locked, we can bootstrap to run a new kernel.
Installation
First, you can compil your own kexec tool
Here, sources : http://forum.xda-developers.com/attachment.php?attachmentid=2397299&stc=1&d=1384689174
And here, the binaries : http://forum.xda-developers.com/attachment.php?attachmentid=2397305&stc=1&d=1384689406
(it's not a cwm zip, i have no time to create an installer for now ; use "./compil-kexec" if you want an automatic install)
Install *.ko in /system/lib/modules
Install kexec and kdump in /system/bin
Grant with "chmod 777"
Unzip in kexec-tools folder
Install a toolchain (sudo apt-get install gcc-arm-linux-gnueabi)
launch => ./compil-kexec
what's all
This script can do everythinks for you
- Compilation of tools
- Compilation of modules
- installation in device
This script can compil for every brand you have.
Except you must remove or adapt the patch (see below why)
Patch ??
This patch is because a module must be compiled in the same time the kernel himself.
For this reason a "vermagic", an identifier, is used by system to block every module not compil with kernel
Some custom kernel bypass this to authorize every modules.
But for stock kernel, it is not allowed.
You can easely strapp this by busybox.
"busybox modprobe" for help
"-f" to force load without vermagic
To see this vermagic :
Code:
# uname -r
This "uname -r" must be the same that
Code:
# strings kexec_load.ko | grep vermagic
vermagic=3.4.0-perf-g66807d4-02450-g9a218f1 SMP preempt mod_unload modversions ARMv7
If you want use automaticaly this vermagic, you can modify into the custom kernel this file :
Code:
"include/config/kernel.release" and add :
"3.4.0-perf-g66807d4-02450-g9a218f1"
This file will be use at module compil to match the vermagic.
Infortunatly, it is not enought. :silly:
The infamous "no symbol version for module_layout"
When a module compil is created, it use symbols link to system call function, translate by adresses
Theses symbols are not at same physical adresses in stock kernel and modules (compiled from DooMLoRD kernel).
So, theses adresses must be convert into modules itself to match with stock symbols adress.
A patch is needed.
If you use my script, modules are automatically patched.
Here patches :
Code:
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' procfs_rw.ko
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' kexec_load.ko
sed -i 's/\xBB\xD0\xF8\x4D/\x0E\x1C\x63\x77/' kexec_load.ko
sed -i 's/\xA6\x26\x81\x1A/\xD4\x56\x02\x7E/' kexec_load.ko
sed -i 's/\xA3\xD1\xEC\x96/\xEC\x43\x28\x1A/' kexec_load.ko
sed -i 's/\x8C\xE6\x6A\x5F/\x3D\xDF\x02\xF2/' kexec_load.ko
sed -i 's/\x3E\xF3\xEF\xE9/\x18\x7F\xA6\x8A/' kexec_load.ko
sed -i 's/\x8B\xD2\x92\x10/\xC8\x19\x08\x9C/' kexec_load.ko
sed -i 's/\x1C\xE8\x18\xE1/\x7C\x71\x9E\xEF/' kexec_load.ko
sed -i 's/\xAB\x2C\x2F\x8B/\x8E\xD7\x63\xC0/' kexec_load.ko
sed -i 's/\xF5\x62\xAA\x4B/\x34\x80\x1B\x74/' kexec_load.ko
sed -i 's/\x00\x52\xD6\xD7/\x6F\x80\x91\x20/' kexec_load.ko
sed -i 's/\x4F\x77\x57\x6A/\x0C\x57\xC7\x63/' kexec_load.ko
sed -i 's/\xCA\x2F\x65\x71/\x92\xB8\x7F\x53/' kexec_load.ko
sed -i 's/\x0F\xD0\xA0\x91/\xFA\x80\x15\xB4/' kexec_load.ko
sed -i 's/\x29\xA0\x6D\x48/\x6C\x6B\x96\x54/' kexec_load.ko
sed -i 's/\x6D\x1F\x1F\x37/\xCC\x5E\x79\x8B/' kexec_load.ko
sed -i 's/\xFD\x23\xD0\xFB/\xE3\xE3\x68\x52/' kexec_load.ko
You can use hexedit or hexdump to see these adresses :
Code:
hexdump kexec_load.ko | grep ff72
0003d50 b0b0 80ac ff72 205e 6f6d 7564 656c 6c5f
how does it work ?
# kexec --help
For kexec help... nothing more to say.
# lsmod
List loaded modules... You must see
kexec_load 31369 0 - Live 0x00000000 (O)
# rmmod kexec_load.ko
Remove kexec_load module from memory.
# grep kexec /proc/device
To see installed driver.
You must see :
100 kexec_driver
First number is "major" number to identify your driver in system.
# mknod /dev/kexec_driver c 100 0
Install driver.
Major number (here 100), is important for module.
This Major must be the same between module and driver.
By default, 100 is used.
# insmod kexec_load.ko
To install "LKM", kexec_load kernel module.
If another Major is needed, you can use "insmod kexec_load.ko 101" for Major 101
You can use "modprob" if you want, but you must configure the module folder.
How kexec and module exchange informations ?
By the driver.
Normal output for a kernel module is to write in "dmsg" file.
To see kernel output, launch this command :
Code:
# dmesg
To see last kernel log, see in :
Code:
# cat /proc/last_kmsg
For kexec module, this normal way still exist, and give a lot of informations, but to speak with, you must use the driver.
/dev/kexec_driver
You can yourself test communication:
Code:
# cat /dev/kexec_driver
You can send kernel by this communication channel.
Type following commands for help
=> echo help >/dev/kexec_driver
=> dmesg | grep Kexec
Code:
# echo help >/dev/kexec_driver
# cat /dev/kexec_driver
Last command : 'help'
Please type following command :
=> dmesg|grep Kexec
Every command send into driver is receive by kexec_load.ko module and running into the kernel.
The answer can by read thru the driver
Here, you can see that normal way to see messages is allway dmesg.
Code:
# dmesg|grep Kexec
<4>[15050.521628] Kexec: Starting kexec_module...
<6>[15050.521656] Kexec: kexec_driver_contener allocation
<6>[15050.521673] Kexec: kexec_memory_buffer allocation
<4>[15050.521691] Kexec:----------------------------------------------------
<4>[15050.521710] Kexec: kexec_driver created with major : '100'
<4>[15050.521728] Kexec: Please, prepare by typing the following commands :
<4>[15050.521746] Kexec: => mknod /dev/kexec_driver c 100 0
<4>[15050.521761] Kexec: => cat /dev/kexec_driver
<4>[15050.521775] Kexec:-----------------------------------------------------
<4>[15050.521791] Kexec: For help
<4>[15050.521803] Kexec: => echo help >/dev/kexec_driver
(...)
I have add a lot of informations to help to configure kexec.
rdtags, atags ??
Not sure for this part of kernel.
"atags" is the most used method to bootloader to parse commands and informations to kernel at boot.
"atags" is a form of structure in memory to organise informations.
At boot, a address chain is created and can be compulse in /proc/atags file.
This file is read only system.
"rdtags" is another way to bootloader to parse information to kernel.
"rdtags" is not stocked in "/proc"
But, as i see, stock kernel can use "atags" from bootloader.
kexec can substitute bootloader function to create fromscratch a atags chain, and parse to new kernel.
I have change this part to stock atags in "/data/atags", and reuse or change if need.
If this don't work, i must create a rdtags chain to replace atags ; It's not a hard work.
Status
For the moment, kexec tools works.
=> Phase one OK.
I can start Phase Two : new kernel patch.
If you want to help me...
Actually, load a custom kernel and boot into with kexec tools work.
But at boot into, a kernel panic occurs.
It seems, a part of kexec patch is missing in custom kernel.

Hi new thread created for kernel kexec development.
Status: not working: wrong values for mem defines under the kernel is giving segmentation fault as its attempting to write to memory areas that are currently being used byyyyy the system
Instructions:
Make kernel compatible?:
1. Download kernel diff patch from below
2. Terminal - diff patch > diff.txt
How to use:
1. Download kexec-tools (kexec binary) from below
2. Copy into system/bin directory and give it executable permission
3. Download compatible kernel
4. Terminal - kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Download links:
Kexec tool- https://db.tt/8DZXQ9eV
Ramdisk firmware 1.548 : https://db.tt/8DZXQ9eV
zImage (kernel):
Source code:
Kernel diff patch: https://db.tt/Xi2htT7Q (currently contains wrong values for mem defines)
Kexec-tools: https://db.tt/I22ofr3b
Special thanks: @delewer @krabappel2548

Reserved

Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app

krabappel2548 said:
Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app
Click to expand...
Click to collapse
Devdb?
Pm me i dont know what Devdb is lol

Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory

If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.

Shaky156 said:
Devdb?
Pm me i dont know what Devdb is lol
Click to expand...
Click to collapse
Shaky156 said:
Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory
Click to expand...
Click to collapse
I'll discuss with Kali- today if he's available.
Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Doesn't need to be same processor, can be ported
Sent from my C6903 using xda app-developers app

Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Yes it wont matter much, since its not s800 it should be easier for you guys , take the kexec-tool use that, implement the patch write to the correct mem addresses which is free, it should boot if you guys have issues let me know,
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values

Shaky156 said:
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values
Click to expand...
Click to collapse
the dt.img is needed by the kernel to boot, so I guess we need to load that too in kexec.
EDIT: people that wanna try add kexec patch to their kernel, check github: android_kernel_sony_msm8974/commits/kexec

krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...

delewer said:
krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...
Click to expand...
Click to collapse
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?

Knucklessg1 said:
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?
Click to expand...
Click to collapse
Read the OP
Status paragraph

Memory regions
00000000-07afffff : System RAM
00008000-00b79383 : Kernel code
00d04000-00f0cddb : Kernel data
0ff00000-779fffff : System RAM
7ff00000-7ff3ffff : rdtags_mem
7ff80000-7ffa0fff : last_kmsg
7ffa1000-7ffa5fff : last_amsslog
System RAM MEM = 00000000
So --min-mem=0x20000000
Now need to find a free memory area thatll allow us to write and hopefully the mmu/pmu on locked bootloader wont cancel it
@delewer? @DooMLoRD @kali @Bin4ry

I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app

king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
These devices are not 2013 devices, they arent s800 socs, so they are much easier to do, simply take the kexec-tools from op, implement the patch in your kernel, write the correct memory values for your specific device and execute in terminal via the command in op, minmem depends on your device too, good luck

I think some1 tried it already, but it works only for unlocked devices... Anyway, thanks for help.
Sent from my LT22i using xda app-developers app

king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
Does doing this require having an Unlocked Boot loader prior to implementation?
Sent from my C6603 using xda app-developers app

A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault

delewer said:
A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault
Click to expand...
Click to collapse
Did you compile this kexec yourself? Or did you get this from krapabbel? I issued krapabbel to compile a new debug version have gave him the code but never heard back from him :/
Anywayz so cannot find free memory is the issue

[DEV] Building a custom kernel and kernel modules for stock kernel

Since fire phone doesn't have a bootloader unlock at the moment. There is no point in building a custom kernel. But By building a kernel we can build kernel modules which work on the stock kernel. And yes you can load unsigned kernel modules without a problem since fire phone doesn't use tz apps to verify kernel modules like Samsung does.
Setup
Source
Download the fire phone sources for firmware 4.6.1 from here. And extract the platfrom.tar inside the archive to somewhere(KERNEL_DIR).
toolchain
You can use the android ndk from google, But it requires some setup. I'm using linaro toolchain from here. You can use compiler version 4.7, 4.8 or 4.9. Kernel I'm using (Firmware 4.6.3 - Linux 3.4-perf-g280c96c) is built with gcc-4.7. But I'm using this gcc-4.9. Download it, extract is somewhere(TOOLCHAIN_DIR) and add the $TOOLCHAIN_DIR/bin to your PATH. Theoretically you would be able to build the kernel on windows using Cygwin or MSYS tools but using Linux is better.
config
Connect your phone trough adb and run
Code:
adb pull /proc/config.gz
zcat config.gz > $KERNEL_DIR/kernel/qcom/3.4/.config
With this config you will run into some problems because of a missing "trapz_generated_kernel.h". I don't know if this is an auto generated file when they build android as a whole or amazon removed this explicitly(can they do that without violating GPL?). Anyway It looks trapz is some low level kernel debugging function(comment here if you know more about it). We can safely disable it. Open $KERNEL_DIR/kernel/qcom/3.4/.config in a text editor and change the lines
Code:
CONFIG_TRAPZ=y
CONFIG_TRAPZ_TP=y
CONFIG_TRAPZ_TRIGGER=y
CONFIG_HAVOK=y
to
Code:
#CONFIG_TRAPZ=y
#CONFIG_TRAPZ_TP=y
#CONFIG_TRAPZ_TRIGGER=y
#CONFIG_HAVOK=y
building
Now edit the $KERNEL_DIR/kernel/qcom/3.4/Makefile and add this changes
Code:
EXTRAVERSION = -perf-g280c96c
This is at the top of the makefile. If we don't add this, vermagic for the modules will differ from stock kernel and they won't load.
ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf-
Click to expand...
Click to collapse
Here arm-linux-gnueabihf- is my cross compiler frefix. Look in $TOOLCHAIN_DIR/bin/ to find it.
Now cd into $KERNEL_DIR/kernel/qcom/3.4/ and do
Code:
make
The build will fail a few times complaining about missing headers. Most of the time it's just
Code:
#include <myheader.h>
instead of
Code:
#include "myheader.h"
Edit the source file where the build fails and change <>s to ""s. (maybe android ndk ignores the difference and include the headers anyway)
After kernel compiles, we are good to go. We can use this kernel sources to build kernel modules for stock kernel.
Kernel modules
To build the kernel modules, we basically need two things. An approximate kernel source and the Module.symvers file from the original kernel. We can get the Module.symvers file by building the complete kernel as explained above or Just extract it from our stock kernel.
To extract the Module.symvers from the stock kernel, extract the boot.img file from firmware update image. Get mkbootimg tools from here compile it and run
Code:
unmkbootimg --kernel zImage ---ramdisk ramdisk.cpio.gz -i boot.img
After you get the zImage. Download extract-symvers script from here and run
Code:
python2 extract-symvers.py -B 0xc0008000 zImage > Module.symvers
place this file in $KERNEL_DIR/kernel/qcom/3.4/ (You still have to do the changes mentioned above in kernel config and building section run make in the $KERNEL_DIR/kernel/qcom/3.4 and intrupt it after few seconds)
Now you can build loadable modules against this source. Here is a hello world kernel module.
Code:
//hello.c
#include<linux/module.h>
#include<linux/kernel.h>
#include<linux/init.h>
static int __init hello_start(void)
{
printk("hello to the world from module");
return 0;
}
static void __exit hello_end(void)
{
printk("heloo exit");
}
module_init(hello_start);
module_exit(hello_end);
Code:
#Makefile
KERNEL_DIR=<your kernel dir>/kernel/qcom/3.4
obj-m := hello.o
PWD := $(shell pwd)
default:
$(MAKE) ARCH=arm CROSS_COMPILE=armeb-linux-gnueabi- -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
Put this files in a folder and run make in it. Change the paths and cross compiler prefix according to your setup. and run make.
After the build push the hello.ko to the phone.
Code:
adb push hello.ko /sdcard/
adb shell
su
cd sdcard
insmod hello.ko
run dmesg and you'll see the message.
I'm currently trying to build kexec module from hashcode's sources and USB OTG modules.
I'm attaching a few thing helped me do this.

since they have released this version of the fire os they have to provide the source code
see
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
you have just shown that the source code they releases for the kernel does not match the one used to build the kernel. This means it is a clear violation of the gpl and amazon is in breach and can be sued.
on another note.
are the drivers for the nfc and camera compiled as a module or into the kernel?

They have yet to provide 4.6.3 and 4.6.4 kernel sources too.
I don't know exactly but in order for NFC and camera to work drivers are required and they are in fact compiled into the kernel.
The problem we currently have with NFC and camera is proprietary hal (hardware abstraction libraries) They are a part of Android and does not subject to GPL. Amazon changed the original android way how hal works and didn't release the sources!
by looking at the kernel drivers maybe we would be able to implement hal from scratch. But I don't see that intense dev support for fire phone. If you are up for it camera sources are at $KERNEL_DIR/kernel/qcom/3.4/drivers/media/platform/msm/camera_v2/

Major MAJOR respect for all of you making the Fire Phone even better!

@madushan1000
Could we do something like this to install a custom boot.img?
http://forum.xda-developers.com/optimus-l9/general/guide-install-custom-roms-locked-t3249828

I don't own this device but has anyone tried to see if kexec works?

spudowiar said:
I don't own this device but has anyone tried to see if kexec works?
Click to expand...
Click to collapse
Nope, I was working on it. But then I got a job. It will be sometime before I can start working on it again.

Could someone please provide the config extracted from /proc/config.gz?
I can't find this on CM11 rom for some reason.

Building the kernel now.
Some bugs are in the code and -Wall and gcc-wrapper.py escalate the warnings.
I wonder if those errors are there on purpose XD
helloworld.ko loaded successfully
I was able to execute kexec without anything. Just the binary.
Will keep you posted - this hacking might take a while to figure it all out.
I already have 3.4 kernel from the amazon sources.
I have the kexec userland program.
What is left is a loadable kexec kernel module (if that is possible at all).

removed

Okarin said:
Are we even sure those Amazon Kernel Sources are correct?
Those errors caught by the wrapper scripts are giving me the creeps.
Git the kexec_load.ko build.
Currently hands on insmod.
Phone doesn't do a reboot any longer:
insmod kexec_load.ko
init_module(0xb6e6c008, 408241, "") = -1 ENOENT (No such file or directory)
write(2, "insmod: init_module '/sdcard/kex"..., 79insmod: init_module '/sdcard/kexec_load.ko' failed (No such file or directory)
) = 79
munmap(0xb6e6c000, 409600) = 0
mprotect(0xb6f8c000, 4096, PROT_READ|PROT_WRITE) = 0
mprotect(0xb6f8c000, 4096, PROT_READ) = 0
close(0) = 0
close(1) = 0
close(2) = 0
futex(0xb6f6cd74, FUTEX_WAKE_PRIVATE, 2147483647) = 0
munmap(0xb6f8c000, 4096) = 0
exit_group(-1) = ?
First goal is to get module loaded.
Goal reached:
kexec_load 27813 0 - Live 0x00000000 (O)
procfs_rw 12770 0 - Live 0x00000000 (O)
wlan 3793980 0 - Live 0x00000000 (O)
Shouldn't be functional at all..
I disabled some function calls just to get the module loaded.
The missing symbols are:
soft_restart
arch_kexec
machine_shutdown
And the version I use does some insane function hooking ..
More rework is needed.
[email protected]:/data/local # ./kexec /sdcard/vmlinux
kernel: 0xaf12d008 kernel_size: 7e1354c
unrecoverable error: could not scan "/proc/device-tree/": No such file or directory
<6>[ 97.681256] Kexec_load: Replacement... :
<6>[ 97.681344] kexec_load : my_syscall_table : c0106244
<6>[ 97.681405] kexec_load : kexec_load before replacement : c01b346c
<6>[ 97.681480] kexec_load : kexec_load after replacement : bf3a5650
<6>[ 97.681546] kexec_load : reboot before replacement : c01a83f0
<6>[ 97.681616] kexec_load : reboot after replacement : bf3a6348
<6>[ 97.681675] Kexec_load: End replacement... :
<6>[ 202.694691] Kexec: - Starting kexec_load...
<6>[ 202.694849] Kexec: - ---- kexec_load - result : '0'
It gets better:
255|[email protected]:/data/local # ./kexec --dtb=/sdcard/zImage-dtb /sdcard/vmlinux
kernel: 0xaf1b1008 kernel_size: 7e1354c
kexec-zImage-arm : dtb.img BEFORE CUT : Start : '0xae66f008' - Length : '0xb411e9' - End : '0xaf1b01f1'
Segmentation fault
More tomorrow.
Click to expand...
Click to collapse
Where are you getting your kexec module sources from? BTW try using the original amazon kernal binary the phone is shipped with (we are sure it works). Don't use the custom kernel for the kexec tests (We don't know the custom kernel actually works)

madushan1000 said:
Where are you getting your kexec module sources from? BTW try using the original amazon kernal binary the phone is shipped with (we are sure it works). Don't use the custom kernel for the kexec tests (We don't know the custom kernel actually works)
Click to expand...
Click to collapse
Here is the thread I used as a starting point.
I will put up my "fork" on github after I get permission to do that
The userland part build like a charm once I took the compiler you recommended.
The kernel-module was tricky because the whole thing is modded like hell.
To be able to load I had to comment out some hard coded addresses and the calls to unresolvable symbols.

removed

Okay the kernel gets loaded.
But
kexec -e shuts off the device.
strace doesn't help.
On the plus side:
Devices are shutdown
Look promising
I need a way to tail dmesg ...
Okay a lot of digging around and I found out that the reboot syscall doesn't work properly..
It doesn't look like it hits the kexec_module it looks more like it hits the actualy sys_reboot
Okay reboot syscall hits my reboot-hook.
But the softreboot doesn't work now.
Okay there is some kind of watchdog runnig which doesn't like my kexec.
I need to kill it - that should happen tomorrow.

removed

I hit the same wall when I tried to isolate the kexec code from the kernel itself to a module. I stopped working on it because I lacked the time. BTW the error you are facing now
<3>[ 80.580644] BUG: scheduling while atomic: kexec/4067/0x00000002
Click to expand...
Click to collapse
is because memory allocator is trying to switch threads while you are in a syscall. it's because of lines like this
image = kzalloc(sizeof(*image), GFP_KERNEL);
Click to expand...
Click to collapse
Try changing GFP_KERNEL to GFP_ATOMIC. Other than that, I have another suggestion. Try to get the kernel to run in a single core mode before running kexec code. This might simplify things. I don't know how to do this though.

madushan1000 said:
I hit the same wall when I tried to isolate the kexec code from the kernel itself to a module. I stopped working on it because I lacked the time. BTW the error you are facing now
is because memory allocator is trying to switch threads while you are in a syscall. it's because of lines like this
Try changing GFP_KERNEL to GFP_ATOMIC. Other than that, I have another suggestion. Try to get the kernel to run in a single core mode before running kexec code. This might simplify things. I don't know how to do this though.
Click to expand...
Click to collapse
The atmic error is gone now. It went away after I disabled the watchtog.
smp_disable() is what you are looking for - but this causes the system to hard_reboot ATM XD

what happens if you kill every userlevel program before smp_disable()?

removed

#define tomorrow
Okay .. I worked out the preemption thing.
At least it does something.
Still a black screen and the MSM_WATCHDOG is a ***** again.
It needs to be suspended .. at least that what I get from the code I read here.
If I remove the driver too early the output in /proc/kmsg stops ..
If I try to remove it too late ... well it causes a resched while atomic.

Requesting help with "make-standalone-toolchain.sh" for AFTV2

Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William

fecaleagle said:
Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William
Click to expand...
Click to collapse
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.

rbox said:
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.
Click to expand...
Click to collapse
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.

fecaleagle said:
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.
Click to expand...
Click to collapse
Well, I'm obviously still doing something wrong. The file command on my build-system reports:
Code:
./dropbearmulti: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
, which looks correct.
But clients are still receiving the following error when I try to connect to the server:
Code:
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
I'll keep digging, but basically, I am building the toolchain like so:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=aarch64-linux-android-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
Then running configure:
Code:
./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-android --prefix=/home/william/aftv2-toolchain --disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp --disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
Then, I am setting CC and PATH to the following:
Code:
CC=aarch64-none-linux-gnueabi-gcc
PATH=/home/william/aftv2-toolchain/bin:$PATH
Then, I am building as such:
Code:
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
No complaints during the build or from the file command, but the issue persists. Surely I am missing something.

Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?

fecaleagle said:
Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?
Click to expand...
Click to collapse
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...

rbox said:
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...
Click to expand...
Click to collapse
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.

fecaleagle said:
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
Click to expand...
Click to collapse
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie

fecaleagle said:
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.
Click to expand...
Click to collapse
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.

rbox said:
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie
Click to expand...
Click to collapse
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.

fecaleagle said:
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.
Click to expand...
Click to collapse
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.

jocala said:
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.
Click to expand...
Click to collapse
Thanks for your work on adbFire. I'll report back if I'm ever able to get this resolved.

rbox said:
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.
Click to expand...
Click to collapse
This suggestion is making more and more sense. I'll take a look at the source and start thinking about my own patchset for the latest source version. I'm annoyed that the verbose flag is not included in the source version of dropbear that the patch was created for, so I think I will end up going that route eventually. I'll take your advice and focus adding debug messages when dropbear initializes the shell, since the authentication goes of without a hitch and it's at that point that the process breaks down. I really appreciate all of your suggestions!

@rbox,
This is rather helpful, and the post from July 31st, 2015 all but confirms your suspicion about forking the shell and points me in the right direction:
http://www.kevinboone.net/kbox3_diary.html
I will start by modifying the patches to use: /bin/sh rather than /system/bin/sh when launching the shell and see if that resolves my issue, then get started on the long slog.

The blog post above seems to have shed some light on the issue. Updating the patches to refer to /bin/sh rather than /system/bin/sh seems to have resolved the "CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit" error. As @rbox suspected, dropbear seems to be creating the appropriate shell upon connect now on a 64-bit system (aftv2).
Unfortunately, I'm still receiving the "dispatch_protocol_error":
Code:
dispatch_protocol_error: type 51 seq 6
[5761] Jan 04 19:47:46 Exit (root): Child failed
Connection to 192.168.1.213 closed.
Any thoughts on this one @jocala? Googling dispatch_protocol_error type 51 returns zilch.