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

[SHELL SCRIPT] Battery logging (discharge, capacity, etc)

After seeing apps like Android Battery Monitor, I wanted something I could run in a shell (adb) that would give me similar statistics, namely the battery discharge rate. I couldn't find any such tools or scripts, so I wrote one. Hopefully it will be useful to someone else, too.
The file paths are hard coded, and will likely only work on the Samsung Epic 4G Touch, however it could probably be easily adapted to other devices as well. It also probably requires busybox, since it uses some basic shell programs.
The script will output statistics every second, like this:
Code:
[DATE]|[TIME]|[DISCHARGE]|[CHARGE%]|[CHARGEMV]|[BATTTEMP]
2011/09/27|13:03:18|+0mA|92%|4101mV|31°C
2011/09/27|13:03:19|+0mA|92%|4101mV|31°C
2011/09/27|13:03:20|+0mA|92%|4101mV|31°C
2011/09/27|13:03:21|-83mA|92%|4018mV|32°C
2011/09/27|13:03:22|+0mA|92%|4018mV|32°C
2011/09/27|13:03:23|+0mA|92%|4018mV|32°C
2011/09/27|13:03:24|+0mA|92%|4018mV|32°C
2011/09/27|13:03:25|+0mA|92%|4018mV|32°C
2011/09/27|13:03:26|+0mA|92%|4018mV|32°C
2011/09/27|13:03:27|+0mA|92%|4018mV|32°C
2011/09/27|13:03:28|+0mA|92%|4018mV|32°C
2011/09/27|13:03:29|+0mA|92%|4018mV|32°C
2011/09/27|13:03:30|+45mA|92%|4063mV|32°C
Here's the script:
Code:
INTERVAL=1
CAPACITYVOLTAGE=0
while true; do
PREVVOLTAGE=$CAPACITYVOLTAGE
DATETIME=$(date +'%Y/%m/%d|%H:%M:%S')
CAPACITYVOLTAGE="$(( $(cat /sys/devices/platform/sec-battery/power_supply/battery/voltage_now) / 1000 ))"
CAPACITYPERCENT="$(cat /sys/devices/platform/sec-battery/power_supply/battery/capacity)"
DISCHARGE="+$(( $CAPACITYVOLTAGE - $PREVVOLTAGE ))"
TEMP="$(( $(cat /sys/devices/platform/sec-battery/power_supply/battery/batt_temp) / 10 ))"
echo "${DATETIME}|$(echo ${DISCHARGE}|sed -e 's/^+-/-/')mA|${CAPACITYPERCENT}%|${CAPACITYVOLTAGE}mV|${TEMP}°C"
sleep ${INTERVAL}
done

While a nice piece of work - this is not development. It is an App. Moving to the appropriate section.

jerdog said:
While a nice piece of work - this is not development. It is an App. Moving to the appropriate section.
Click to expand...
Click to collapse
Well, I was hoping to get some feedback and make some improvements before calling it an app, but that works.

xak944 said:
After seeing apps like Android Battery Monitor, I wanted something I could run in a shell (adb) that would give me similar statistics, namely the battery discharge rate. I couldn't find any such tools or scripts, so I wrote one. Hopefully it will be useful to someone else, too.
The file paths are hard coded, and will likely only work on the Samsung Epic 4G Touch, however it could probably be easily adapted to other devices as well. It also probably requires busybox, since it uses some basic shell programs.
The script will output statistics every second, like this:
Code:
[DATE]|[TIME]|[DISCHARGE]|[CHARGE%]|[CHARGEMV]|[BATTTEMP]
2011/09/27|13:03:18|+0mA|92%|4101mV|31°C
2011/09/27|13:03:19|+0mA|92%|4101mV|31°C
2011/09/27|13:03:20|+0mA|92%|4101mV|31°C
2011/09/27|13:03:21|-83mA|92%|4018mV|32°C
2011/09/27|13:03:22|+0mA|92%|4018mV|32°C
2011/09/27|13:03:23|+0mA|92%|4018mV|32°C
2011/09/27|13:03:24|+0mA|92%|4018mV|32°C
2011/09/27|13:03:25|+0mA|92%|4018mV|32°C
2011/09/27|13:03:26|+0mA|92%|4018mV|32°C
2011/09/27|13:03:27|+0mA|92%|4018mV|32°C
2011/09/27|13:03:28|+0mA|92%|4018mV|32°C
2011/09/27|13:03:29|+0mA|92%|4018mV|32°C
2011/09/27|13:03:30|+45mA|92%|4063mV|32°C
Here's the script:
Code:
INTERVAL=1
CAPACITYVOLTAGE=0
while true; do
PREVVOLTAGE=$CAPACITYVOLTAGE
DATETIME=$(date +'%Y/%m/%d|%H:%M:%S')
CAPACITYVOLTAGE="$(( $(cat /sys/devices/platform/sec-battery/power_supply/battery/voltage_now) / 1000 ))"
CAPACITYPERCENT="$(cat /sys/devices/platform/sec-battery/power_supply/battery/capacity)"
DISCHARGE="+$(( $CAPACITYVOLTAGE - $PREVVOLTAGE ))"
TEMP="$(( $(cat /sys/devices/platform/sec-battery/power_supply/battery/batt_temp) / 10 ))"
echo "${DATETIME}|$(echo ${DISCHARGE}|sed -e 's/^+-/-/')mA|${CAPACITYPERCENT}%|${CAPACITYVOLTAGE}mV|${TEMP}°C"
sleep ${INTERVAL}
done
Click to expand...
Click to collapse
1) How does one install the script?
2) How does one uninstall it?
3) How much does the script affect battery performance?
4) How stable is the script?
5) What makes this script better than other similar apps in the market?

>> 1) How does one install the script?
You don't. Just move it to an appropriate location on your phone via adb push command, change permissions to make executable & run it. It does not involve any formal installation/removal.
>> 3) How much does the script affect battery performance?
Neglible. even if you launched from a terminal emulator on-board your phone & not while it was connected via the USB to your computer
>> 4) How stable is the script?
Fairly since its quite simple. He is only reading those ascii files available on any typical linux based system & printing to console after some post-processing

Been interested in looking at what I can get my rooted device to do via Terminal/SSH, this is a great start Had to edit it a bit for my desire Z, however working a treat.. The script can lag a little if I use it via SSH with the screen off, however to be expected I suppose. A little Caffeine and it completely works as expected.
Code:
INTERVAL=1
CAPACITYVOLTAGE=0
while true; do
PREVVOLTAGE=$CAPACITYVOLTAGE
DATETIME=$(date +'%Y/%m/%d|%H:%M:%S')
CAPACITYVOLTAGE="$(cat /sys/devices/platform/rs30100001:00000000/power_supply/battery/batt_vol)"
CAPACITYPERCENT="$(cat /sys/devices/platform/rs30100001:00000000/power_supply/battery/capacity)"
DISCHARGE="+$(( $CAPACITYVOLTAGE - $PREVVOLTAGE ))"
TEMP="$(( $(cat /sys/devices/platform/rs30100001:00000000/power_supply/battery/batt_temp) / 10 ))"
echo "${DATETIME}|$(echo ${DISCHARGE}|sed -e 's/^+-/-/')mA|${CAPACITYPERCENT}%|${CAPACITYVOLTAGE}mV|${TEMP}°C"
sleep ${INTERVAL}
done
I'm off to try and create something similar for the GPS.. No idea how feasible as yet, but appreciate the inspiration.

Nice job on this script.

Very good work man keep it up

I had to edit it a bit for my Vibrant (Miui 9.23)
make file (I called mine "adb_batt.sh" placed it on my sdcard
I used Gscrip lite to run it (or terminal)
"sh ./mnt/sdcard/adb_batt.sh"
==================================
INTERVAL=1
CAPACITYVOLTAGE=0
while true; do
PREVVOLTAGE=$CAPACITYVOLTAGE
DATETIME=$(date +'%Y/%m/%d|%H:%M:%S')
CAPACITYVOLTAGE="$(( $(cat sys/devices/platform/i2c-gpio.6/i2c-6/6-0066/max8998-charger/power_supply/battery/voltage_now) / 1000 ))"
CAPACITYPERCENT="$(cat sys/devices/platform/i2c-gpio.6/i2c-6/6-0066/max8998-charger/power_supply/battery/capacity
)"
DISCHARGE="+$(( $CAPACITYVOLTAGE - $PREVVOLTAGE ))"
TEMP="$(( $(cat sys/devices/platform/i2c-gpio.6/i2c-6/6-0066/max8998-charger/power_supply/battery/batt_temp_check) / 10 ))"
echo "${DATETIME}|$(echo ${DISCHARGE}|sed -e 's/^+-/-/')mA|${CAPACITYPERCENT}%|${CAPACITYVOLTAGE}mV|${TEMP}°C"
sleep ${INTERVAL}
done

doesn't this do the same thing
https://market.android.com/details?id=ccc71.bmw&feature=search_result

BLOWNCO said:
doesn't this do the same thing
https://market.android.com/details?id=ccc71.bmw&feature=search_result
Click to expand...
Click to collapse
yes, but having a tweakable script version.
back on topic, trying to run the script but it complains
Code:
# sh logb
: not found
logb: 16: Syntax error: "done" unexpected (expecting "do")

frifox said:
yes, but having a tweakable script version.
back on topic, trying to run the script but it complains
Code:
# sh logb
: not found
logb: 16: Syntax error: "done" unexpected (expecting "do")
Click to expand...
Click to collapse
Sounds like you might've copied and pasted the script on a windows text editor, which uses DOS line endings. You need to convert them to unix line endings. If you use notepad++ to edit/save the file:
Edit > EOL Conversion > Unix Format

FBis251 said:
Sounds like you might've copied and pasted the script on a windows text editor, which uses DOS line endings. You need to convert them to unix line endings. If you use notepad++ to edit/save the file:
Edit > EOL Conversion > Unix Format
Click to expand...
Click to collapse
sh1t, i thought i made sure it pasted in unix format... oh well, redid it with notepad++ and that fixed it

I like the scripts and like to have a look into this on my xperia z1 compact. Has anybody has an idea, where I can find the batteryfolder on sony devices?

[Dev] HD2 multi-script

I have a script and tools hosted on dropbox.
Stick with the beta script unless you're interested in testing.
What the script can do.
1. Essentially replace aroma in the most basic sense. [Can be made to run with]
It will take any ROM.zip convert the initrd.gz to the desired type (DataOnExt, NativeSD, DirectSD) and copy them to /boot and /boot_dir
Will strip the updater-script of the ROM.zip down to the symlink/set_perm lines along with extract data and system folders.
(Essentially turning an aroma ROM.zip to a basic CWM ROM.zip)
2. Mount appropriate folders
Just tell the script the type of install and the name of the ROM (i.e the ROM folder name on ext4).
Then you can flash any zip you want (as long as the zip doesn't change the mounts)
3. Modify the ramdisk
If you just want the ramdisk modified that can be arranged
4. System install.
In consideration.
It's difficult to get things running as they should without a device to reliably test things on, so need user feedback to correct stuff.
I have been unsuccessful thus far in getting a portadroid type up and running, I'm not sure why at this point.
If the interest is there I can try and add in the updating mechanic from portadroid to Native/Direct, i.e where you have a named folder(s) (open to suggestion on folder names) present in /sdcard/NativeSD and these folders are copied over to the ext4 folders on boot.
How to run:
Instruction can be seen on the dropbox page but:
Simpliest way is via adb.
Copy the bins folder to /sdcard/bins
Reboot to recovery
Push the script to /tmp for example: adb push *.sh /tmp/
Run the script:
adb shell
cd tmp
chmod 777 *.sh
./*.sh
Then read the prompts.
Alternatively you can run it directly as ./*.sh {opt} $type $ROM_NAME $data_NAME $systeminstall
Feel free to report any issues, suggestions/improvements.
I'll be posting a recovery with most of the needed stuff bundled in, so running it will be easier for devs.
Writing the script took some doing (especially as it's in dash - not bash), any feedback would be appreciated.
Credits due.
The portadroid guys (if/when it's up and running)
[cedesmit, Takaaki, boonbing]
The Native/DirectSD guys
[securecrt,Xylograph]
RobbieP for testing thus far.

I have noticed that I already have the code for an update feature in the script just need to add a loop, what would be the general consensus for the location of the script to flash /sdcard/NativeSD/*.zip or /sdcard/NativeSD/ROM_NAME/*.zip?? The second would mean that you can't rename the foldername (unless I manage to add in startup.txt features).
Update added to gamma script - using ROM folder (subject to change)

is this any good for determining kernel version? http://stackoverflow.com/questions/9535227/getting-uname-information-from-a-compressed-kernel-image

I added a modified version of @macs18max CM11 ROM using a version of my gamma script (will pull on request) to dropbox last night, if anyone is willing to test...
1. Does it boot
---If it doesn't add a blank file as /sdcard/bins/makemountfs (echo "" > /sdcard/bins/makemountfs will do it)---
---And try it again; unfortunately this will remove the update feature---
2. Are update zips installed properly
Diff from original:
only one initrd - script makes the others as needed
script performs the partition mounting for the ROM
script checks for zips in the ROM folder in NativeSD
Need to add:
my build.prop append code - once I where I posted it... to reduce duplicates.
Edit. Whoops didn't mean to edit my post from yesterday - @Robbie P just for reference "strings zImage | grep 'Linux version'" is similar to what you posted and can be run on the leo but doesn't seem to give reliable/usable results - I haven't ran the hexdump check on the latest kernel yet so not sure if the check is still valid.

i did try 1_92 on macs18max's rom last night, the kernel was not recognised as a 3.0 kernel. i added 6mb but it didn't boot. I had the extended battery in throughout
i did use the f2fs sd recovery though to flash it, that booted ok and has 3.0 kernel
i still think a simple "if kernel >3mb => 3.0 kernel" haven't checked the latest .35 kernel yet for size.
did you add the adb fix?
will try yours later:fingers-crossed:
thanks
Edit; in fact, size of kernel is the over-riding factor, surely. it is size-of-magldr's-boot-partition minus size-of-initrd.gz(any-type) gives the max size of a kernel before we have to add 6mb. i guess it is around 3mb.
it is conceivable that we may have to add 6mb to the .35 kernel's ramdisk if more code is added.

Robbie P said:
i did try 1_92 on macs18max's rom last night, the kernel was not recognised as a 3.0 kernel. i added 6mb but it didn't boot. I had the extended battery in throughout
i did use the f2fs sd recovery though to flash it, that booted ok and has 3.0 kernel
i still think a simple "if kernel >3mb => 3.0 kernel" haven't checked the latest .35 kernel yet for size.
did you add the adb fix?
I added the ADB 'fix' to on boot - with gamma 4_4 (the ROM zip is using 4_3) - the line I added is with the variable, not ABCD..., might work, moight not
will try yours later:fingers-crossed:
thanks
Edit; in fact, size of kernel is the over-riding factor, surely. it is size-of-magldr's-boot-partition minus size-of-initrd.gz(any-type) gives the max size of a kernel before we have to add 6mb. i guess it is around 3mb.
it is conceivable that we may have to add 6mb to the .35 kernel's ramdisk if more code is added.
You could be right about the 3mb size always needing 6MB but I can't be sure. My feeling is it is a 3.0.x issue rather than a size one (I could be wrong though). 3.0.x kernels could probably be cut down (esp. recovery kernels) to be less than 3MB (and vice versa with the 2.6.x) that's why I was keen to stay away from size as being the determining factor - I'll switch to using sizes in the next gamma.
Click to expand...
Click to collapse
ADB fix with 4_4 is:
sed -i "/on boot/ a write /sys/class/android_usb/android0/iSerial \${ro.serialno}" /tmp/work/init.htcleo.rc
I could try variable substitution \${ro.serialno:-ABCDEF123456} but not sure if that works with .rc's
Edit. 4_5 kernel check changed to:
Code:
[strike]zI=` busybox ls -la /tmp/zImage | awk '{print (${NF-4)}' `
if [ ${zI} -gt '3145728' ]; then...[/strike]
zI=` du -m /tmp/zImage | awk '{print $(NF-1)}' `
if [ ${zI} -gt '2' ]; then...

mac rom; i have an error from aroma-config line 147 col 40, pretty sure it is missing comma on line 145 after "1"
rezipping and re-flashing. is the rom-name different from original?
it went through aroma options (chose directsd, softkeys,wipe), then installed immediately, no files actually installed, attached recov logg
i did have original rom.zip on sdcard and nativesd rom installed, might have to delete either, or both?
Edit; deleted original rom.zip and used 4ext recovery (f2fs sd previously), but same, installs successfully immediately, log did not save unfortunately

Robbie P said:
mac rom; i have an error from aroma-config line 147 col 40, pretty sure it is missing comma on line 145 after "1"
rezipping and re-flashing. is the rom-name different from original?
it went through aroma options (chose directsd, softkeys,wipe), then installed immediately, no files actually installed, attached recov logg
i did have original rom.zip on sdcard and nativesd rom installed, might have to delete either, or both?
Edit; deleted original rom.zip and used 4ext recovery (f2fs sd previously), but same, installs successfully immediately, log did not save unfortunately
Click to expand...
Click to collapse
Have reupped with aroma fixed, rom-name was the same as original (folder in NativeSD would be different). Reupped version has _test added to it. recov.logg reports that system was installed??? Based on the other stuff in the log I don't think it's made from the zip.
type=NativeSD rom_name=cm11_ma and command run was m(ntstuff) rather then m(odify)r(amdisk)...
Yea - the log is from a different zip install:
Code:
Installing '/sdcard/cm11_ma_NativeSD.zip'...
Checking for MD5 file...
I:Cannot find file /sdcard/cm11_ma_NativeSD.zip.md5
Skipping MD5 check: no MD5 file found.
I:Zip does not contain SELinux file_contexts file in its root.
about to run program [/tmp/multi.sh] with 5 args
There really shouldn't be any conflicts with other zips here... Is there any text reported on screen after/before the system supposedly installs?
Edit. Anyone know where the HD2 HaRET source is located? Anyone trying to run 3.0.x with haret try adding 1MB of zeros to the initrd.gz (PM if you don't know how).

sorry about that log, was the one from previous night's install.
i just tried GAMMA4_5.sh DirectSD cm11_m
get screen.txt attached
i know @gilbert32 was looking at getting haret to boot with 3.0 kernel

Robbie P said:
sorry about that log, was the one from previous night's install.
i just tried GAMMA4_5.sh DirectSD cm11_m
get screen.txt attached
i know @gilbert32 was looking at getting haret to boot with 3.0 kernel
Click to expand...
Click to collapse
Could you try just using the zip on the dropbox page - the sh and bins are already added to it. No need to run any script. I might need to change the bundled script though. Picking through the errors in the log:
sh: 3.1: bad number
is from the kernel check - I added h (so that it reports 3.1M rather than 3, wasn't sure how it would handle the decimal) - reverted 4_5
cp: can't stat '/tmp/mountfs-DirectSD.sh': No such file or directory
copying fsck for f2fs
cp: can't create '/system/bin/mkfs.f2fs': No such file or directory
cp: can't create '/system/bin/fsck.f2fs': No such file or directory
chmod: /system/bin/mkfs.f2fs: No such file or directory
chmod: /system/bin/fsck.f2fs: No such file or directory
gamma doesn't use mountfs.sh's by default
f2fs added in error?? Can't copy to system/bin as there isn't one
/GAMMA4_5.sh: line 1236: /tmp/7za: not found
Should have been /bin/7za - fixed 4_5
sh: porta: unknown operand
Trying to figure this one out - it's line 1197 - fixed 4_5 - still not sure why it reported as an error (nested if??)
​Current 4_5 bundled in ROM zip
My thinking regarding haRET - the source I saw (different device) seems to have the ramdisk offset by 5MB. Offset for 3.0.x is 16MB (magldr default offset is 10MB plus the 6MB of zeroes = 16MB). If the offset in haret is matched to that of magldr (10MB) then 1 more MB is needed to get to to 16 - if haret is compiled to add a 5MB offset. Source I was referencing is here.

Robbie P said:
sorry about that log, was the one from previous night's install.
i just tried GAMMA4_5.sh DirectSD cm11_m
get screen.txt attached
i know @gilbert32 was looking at getting haret to boot with 3.0 kernel
Click to expand...
Click to collapse
funny thing, i just was looking into it (after a long time since being on xda), and saw this mention
still, i can't find any clue on what to do, or what's the cause for the no-boot with haret...

tried latest mac.zip, have attached logs
i have a work assessment coming up in the next couple of days, so need to get my head down.:fingers-crossed:

Robbie P said:
tried latest mac.zip, have attached logs
i have a work assessment coming up in the next couple of days, so need to get my head down.:fingers-crossed:
Click to expand...
Click to collapse
Get your head down, mate. Just some missing ,'s in the updater-script (used to separate arguments). Should be fine now - at least on the non-script side of things.
Correction - it's fine now (sh was wiping /tmp and thus /tmp/aroma before it was needed by updater-script), managed to botch a working device again - currently installing as DirectSD on cLK.

HypoTurtle said:
Anyone trying to run 3.0.x with haret try adding 1MB of zeros to the initrd.gz (PM if you don't know how).
Click to expand...
Click to collapse
Just tried this and it still doesn't boot, same as before, hangs on jumping to kernel
edit; tried changing initrd offset in startup.txt from 0x00a00000 to 0x00b00000 and 0x00900000 but no joy either

Robbie P said:
Just tried this and it still doesn't boot, same as before, hangs on jumping to kernel
edit; tried changing initrd offset in startup.txt from 0x00a00000 to 0x00b00000 and 0x00900000 but no joy either
Click to expand...
Click to collapse
nah, this isn't the problem. it's somewhere else and i can't figure it out we have to stick with clk or mag for 3.0.x atm

gilbert32 said:
nah, this isn't the problem. it's somewhere else and i can't figure it out we have to stick with clk or mag for 3.0.x atm
Click to expand...
Click to collapse
How about mtype? we know that the .35 kernel was originally from desire. is it possible that it still has mtype set to 2215 somewhere? i tried setting it to this in startup.txt but same.
Edit; might have found haret source code https://code.google.com/p/android-kaiser/downloads/detail?name=haret.tar.gz&can=2&q=

@gilbert32 @Robbie P
Just for reference: haretlog from 2.x
Built virtual to physical page mapping
Allocated 3124 pages (tags=5C000000/16368000 kernel=5C001000/16369000 initrd=5C2BB000/2c161000 index=5CC2D000/2b7ef000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x2b9800) [2.72MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b7ea0e4
[email protected]/2b7e9000 sj=5CC33278 stack=5CC31000/2b7eb000 data=5CC32000/2b7ea000 exec=2b7e93a0
Reading 2856960 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b7e9288 [695.91MB]
Trampoline setup ([email protected]/10028f68/1323ff68) [256.16MB][306.25MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...​and from 3.x
Built virtual to physical page mapping
Allocated 3308 pages (tags=5C900000/163e0000 kernel=5C901000/1649a000 initrd=5CC73000/16294000 index=5D5E5000/2b87c000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x3715b0) [3.44MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b8770e4
[email protected]/2b876000 sj=5D5EB278 stack=5D5E9000/2b878000 data=5D5EA000/2b877000 exec=2b8763a0
Reading 3610032 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b876288 [696.46MB]
Trampoline setup ([email protected]/1a028f68/12ca6f68) [416.16MB][300.65MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...​There's probably nothing there of any help. Physical address is changed by about 1.5MB?? 160MB in trampoline == graphics??

Double post

how about booting a 2.6.32 kernel from haret and then using kexec to change to 3.0 kernel in running rom?

HypoTurtle said:
@gilbert32 @Robbie P
Just for reference: haretlog from 2.x
Built virtual to physical page mapping
Allocated 3124 pages (tags=5C000000/16368000 kernel=5C001000/16369000 initrd=5C2BB000/2c161000 index=5CC2D000/2b7ef000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x2b9800) [2.72MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b7ea0e4
[email protected]/2b7e9000 sj=5CC33278 stack=5CC31000/2b7eb000 data=5CC32000/2b7ea000 exec=2b7e93a0
Reading 2856960 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b7e9288 [695.91MB]
Trampoline setup ([email protected]/10028f68/1323ff68) [256.16MB][306.25MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...​and from 3.x
Built virtual to physical page mapping
Allocated 3308 pages (tags=5C900000/163e0000 kernel=5C901000/1649a000 initrd=5CC73000/16294000 index=5D5E5000/2b87c000)
Built kernel tags area
Built page index
Tags will be at offset 0x00000100 (0xf00)
Kernel will be at offset 0x00008000 (0x3715b0) [3.44MB]
Initrd will be at offset 0x00a00000 (0x971ad6)
Video buffer at 49739000 sx=480 sy=800 mx=120 my=133
Video Phys FB=03839000 Fonts=2b8770e4
[email protected]/2b876000 sj=5D5EB278 stack=5D5E9000/2b878000 data=5D5EA000/2b877000 exec=2b8763a0
Reading 3610032 bytes...
Read complete
Reading 9902806 bytes...
Read complete
Launching to physical address 2b876288 [696.46MB]
Trampoline setup ([email protected]/1a028f68/12ca6f68) [416.16MB][300.65MB]
MMU setup: mmu=A04C0000/11cc0000
Go Go Go...​There's probably nothing there of any help. Physical address is changed by about 1.5MB?? 160MB in trampoline == graphics??
Click to expand...
Click to collapse
@HypoTurtle @gilbert32 @Robbie P
How do I get this logs from haret. I have just install win6.1. Could someone guide me?

Where can I find the "sswap" utility?

Sorry if this is posted in the wrong forum. XDA's brain-damaged posting policy doesn't allow me to post in the development section.
Moderator Edit: Definitely in the wrong Forum, you're right. Should have been in Q and A... which it now is. This Post will help you understand the XDA stance on posting in Development
I've been scratching my head trying to figure out the location and purpose of a mysterious file introduced in recent Cyanogenmod builds for the Samsung Galaxy Tab S 8.4 (klimtwifi).
The file is sswap. The file is referenced in at least two files within the Cyanogenmod build directory, i.e.:
Code:
device/samsung/klimtwifi/proprietary-files.txt
device/samsung/klimtwifi/rootdir/etc/init.universal5420.rc
In proprietary-files.txt we see the following lines:
Code:
# Samsung SSWAP
root/sbin/sswap
Basically, proprietary-files.txt is the list of files that the extract-files.sh script uses to download the prebuilt binary-only vendor files (without source code) from a working Cyanogenmod installation. This appears to place the file within the /system directory. At least this is my understanding of how the extract-files.sh script works, i.e. it takes the relative paths found in proprietary-files.txt and appends the base path /system.
Code:
if [ "$SRC" = "adb" ]; then
adb pull /system/$FILE $BASE/$DEST
# if file dot not exist try destination
if [ "$?" != "0" ]
then
adb pull /system/$DEST $BASE/$DEST
fi
However the reference to sswap in init.universal5420.rc puts it in a different location:
Code:
service sswap /sbin/sswap -s
class core
user root
group root
oneshot
seclabel u:r:sswap:s0
I can only assume that sswap is hardlinked or softlinked to or from the /system directory. However, this kind of defeats the
purpose of /sbin being assigned root-only read permissions.
Finally, I've not been able to find any documentation with regard to sswap, particularly what its advantages or disadvantages are when compared to the standard Linux swapon/swapoff utility.

DisposableName said:
Sorry if this is posted in the wrong forum. XDA's brain-damaged posting policy doesn't allow me to post in the development section.
Moderator Edit: Definitely in the wrong Forum, you're right. Should have been in Q and A... which it now is. This Post will help you understand the XDA stance on posting in Development
I've been scratching my head trying to figure out the location and purpose of a mysterious file introduced in recent Cyanogenmod builds for the Samsung Galaxy Tab S 8.4 (klimtwifi).
The file is sswap. The file is referenced in at least two files within the Cyanogenmod build directory, i.e.:
Code:
device/samsung/klimtwifi/proprietary-files.txt
device/samsung/klimtwifi/rootdir/etc/init.universal5420.rc
In proprietary-files.txt we see the following lines:
Code:
# Samsung SSWAP
root/sbin/sswap
Basically, proprietary-files.txt is the list of files that the extract-files.sh script uses to download the prebuilt binary-only vendor files (without source code) from a working Cyanogenmod installation. This appears to place the file within the /system directory. At least this is my understanding of how the extract-files.sh script works, i.e. it takes the relative paths found in proprietary-files.txt and appends the base path /system.
Code:
if [ "$SRC" = "adb" ]; then
adb pull /system/$FILE $BASE/$DEST
# if file dot not exist try destination
if [ "$?" != "0" ]
then
adb pull /system/$DEST $BASE/$DEST
fi
However the reference to sswap in init.universal5420.rc puts it in a different location:
Code:
service sswap /sbin/sswap -s
class core
user root
group root
oneshot
seclabel u:r:sswap:s0
I can only assume that sswap is hardlinked or softlinked to or from the /system directory. However, this kind of defeats the
purpose of /sbin being assigned root-only read permissions.
Finally, I've not been able to find any documentation with regard to sswap, particularly what its advantages or disadvantages are when compared to the standard Linux swapon/swapoff utility.
Click to expand...
Click to collapse
When I put together the prop* there was no option to get files from the roms ramdisk (extract-files.sh assumes all needed files reside in /system/. sswap lives in /sbin/ and should be in /sbin for the source build rom, too. If you look here:
https://github.com/TheMuppets/propr...-common/exynos5420-common-vendor-blobs.mk#L25
...you'll see that sswap is copied to /root/sbin. In /root the android build environment assambles the ramdisk.
You can use mkswap on the swap partition and go ahead with swapon and swapoff. This will work. But since I havn't found any documentation of samsungs sswap partition format, I decided to use samsungs sswap instead of standard linux kernel swap interface: I have no idea hpw to "mkswap" for sswap. If you use mkswap and swapon be prepared to have a hard time to get back to sammy tw.

BlissOS-x86_64 Kernel Parameters reference

Hey,
Looking around online there seems to be a lot of confusion on kernel parameters and what they do, so let's get a central thread going to clarify exactly what each kernel paramter does.
Here's what I've come up with after a lot of trial and error, I know if this information was more readily avaible it would have saved me a fair chunk of time.
Please feel free to add to the list and I will try to maintain the list as I continue to verify and understand what each parameter does.

INSTALL=1 #Run an installer, ( Extracting kernel,initrd.img,system.sfs & ramdisk.img from the iso and adding a new grub entry is sufficient. I dunno, it must be a linux thing, you windows boys wont get it? )
root=/dev/ram0 #needs more explanation
SRC=/android/ #the location of system.img&ramdisk.img
DATA=/path #the directory to use for persistent storage. this path is relative to the SRC directory Alternatively, DATA can be assigned a block device.
CREATE_DATA_IMG=1 #needs more explanation
DATA_IN_MEM=1 #Needs verifying and more clarification
REMOUNT_RW=1 #Enable rw remount of /system
VULKAN=1 #Enable VULKAN api support
nomodeset #?disable autodetecting video output settings
vga=0x1d4 #load specific video output. To determine supported modes, at the grub loading screen press c to enter the console and use the command vbeinfo

XxyZ4114 said:
INSTALL=1 #Run an installer, ( Extracting kernel,initrd.img,system.sfs & ramdisk.img from the iso and adding a new grub entry is sufficient. I dunno, it must be a linux thing, you windows boys wont get it? )
root=/dev/ram0 #needs more explanation
SRC=/android/ #the location of system.img&ramdisk.img
DATA=/path #the directory to use for persistent storage. this path is relative to the SRC directory Alternatively, DATA can be assigned a block device.
CREATE_DATA_IMG=1 #needs more explanation
DATA_IN_MEM=1 #Needs verifying and more clarification
REMOUNT_RW=1 #Enable rw remount of /system
VULKAN=1 #Enable VULKAN api support
nomodeset #?disable autodetecting video output settings
vga=0x1d4 #load specific video output. To determine supported modes, at the grub loading screen press c to enter the console and use the command vbeinfo
Click to expand...
Click to collapse
Most of these are documented in our https://docs.blissroms.com site. If you find anything that might need to be added, the repo can be found here: https://github.com/BlissRoms/Documentation-release and commits can be sent for review to https://review.blissroms.com
Thanks for helping out so far

XxyZ4114 said:
INSTALL=1 #Run an installer, ( Extracting kernel,initrd.img,system.sfs & ramdisk.img from the iso and adding a new grub entry is sufficient. I dunno, it must be a linux thing, you windows boys wont get it? )
root=/dev/ram0 #needs more explanation
SRC=/android/ #the location of system.img&ramdisk.img
DATA=/path #the directory to use for persistent storage. this path is relative to the SRC directory Alternatively, DATA can be assigned a block device.
CREATE_DATA_IMG=1 #needs more explanation
DATA_IN_MEM=1 #Needs verifying and more clarification
REMOUNT_RW=1 #Enable rw remount of /system
VULKAN=1 #Enable VULKAN api support
nomodeset #?disable autodetecting video output settings
vga=0x1d4 #load specific video output. To determine supported modes, at the grub loading screen press c to enter the console and use the command vbeinfo
Click to expand...
Click to collapse
Command is videoinfo BTW...