[Q] Change init.rc to custom memory management? - Android Q&A, Help & Troubleshooting

Hello,
While i am not new to this forum, due to some reasons I had to create a new user for myself. I am currently using Samsung Galaxy Tab Plus P6200.
From the very beginning, I am frustrated at how android decides to kill my apps on my own. I majorly use web browser with 6-7 tabs open and as soon as I switch applications, the browser gets killed and all tabs are lost.
Thus i wanted to take the matter in my own hands as there is no stable CM for this tablet.
While going through init.rc, I found a block of property setter, which i think are used to kill apps. This is:
Code:
# Define the oom_adj values for the classes of processes that can be
# killed by the kernel. These are used in ActivityManagerService.
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.PERCEPTIBLE_APP_ADJ 2
setprop ro.HEAVY_WEIGHT_APP_ADJ 3
setprop ro.SECONDARY_SERVER_ADJ 4
setprop ro.BACKUP_APP_ADJ 5
setprop ro.HOME_APP_ADJ 6
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.EMPTY_APP_ADJ 15
# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
# These are currently tuned for tablets with approx 1GB RAM.
setprop ro.FOREGROUND_APP_MEM 8192
setprop ro.VISIBLE_APP_MEM 10240
setprop ro.PERCEPTIBLE_APP_MEM 12288
setprop ro.HEAVY_WEIGHT_APP_MEM 12288
setprop ro.SECONDARY_SERVER_MEM 14336
setprop ro.BACKUP_APP_MEM 14336
setprop ro.HOME_APP_MEM 14336
setprop ro.HIDDEN_APP_MEM 16384
setprop ro.EMPTY_APP_MEM 20480
# Old values for phones. Should probably be adjusted up for the next
# phone version.
#setprop ro.FOREGROUND_APP_MEM 2048
#setprop ro.VISIBLE_APP_MEM 3072
#setprop ro.PERCEPTIBLE_APP_MEM 4096
#setprop ro.HEAVY_WEIGHT_APP_MEM 4096
#setprop ro.SECONDARY_SERVER_MEM 6144
#setprop ro.BACKUP_APP_MEM 6144
#setprop ro.HOME_APP_MEM 6144
#setprop ro.HIDDEN_APP_MEM 7168
#setprop ro.EMPTY_APP_MEM 8192
# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have combined some of
# the classes into the same memory level; the associated processes of higher
# classes will still be killed first.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree 8192,10240,12288,14336,16384,20480
So i went forward and changed these to suit myself, for once rebooted, my changes were lost! Searching more, I found that the flash in device is partitioned with hidden partitions as boot and recovery where the master files are placed ( init.rc), which on reboot are copied to device. So now I want to change the content of boot partition.
The device does not have /proc/mtd but mmcdevice is split in many parts. I am unable to recognize which one is boot partition.
So my question is can I use the official image of Samsung (gz file), unzip it, extract the boot partition, edit its content , repack it and flash it via odin?
Also if any simple workaround to stop android killing my apps is known, please do let me know.

init.rc
You need to do a couple things before editing init.rc
1) Unpack your boot.img
2)Find init.rc in ramdisk folder
3) Aha now edit init.rc
4) repack boot.img
5) make a lil flashable zip to load up new boot.img
My guess is you are trying to edit init.rc in /system; problem is ramdisk will overwrite that 'copy' and so your changes are not persistent. Try editing on ramdisk and watch the magic unfold
As for a memory management, after you tweak init.rc, you can get your init.d scripts looked at first [which is as it should be] and include the script(s) there. This way your boot.img doesn't swell up like a balloon
Rob

I'm no expert, but..
Probably safer than editing your ramdisk is using init.d, sysinit or install_recovery.sh
/system/bin/sysinit & /system/etc/install_recovery.sh are normal shell scripts that run at boot
experiment to see which you prefer & if either get overwritten or removed
In the one that you choose, if you have busybox, insert
Code:
run_parts /system/etc/init.d
otherwise you're going to have to do something much more elaborate like (correct my syntax)
Code:
for F in (/system/etc/init.d/*)
do
if test -x $F
then
source $F > /dev/null 2>&1 &
fi
done
In /system/etc/init.d/ place something like 99my_memory_hack.sh containing your fixes
'setprop' works as you've listed above, but the 'write' command is specific to init.rc
for the single parameter commands use
Code:
echo [parameter] > /proc/[wherever]
for the multi parameter commands I'm not sure, it might work as above or you might need a 'for' loop & post them sequentially (correct my syntax)
Code:
for I in (parameters)
do
echo $I >> /proc/[wherever]
done
---------- Post added at 11:32 AM ---------- Previous post was at 11:14 AM ----------
For every 'setprop' you intend to use, use 'getprop' to find the current value - it might not be what's set in init.rc!
Also look in /system/build.prop & look on the market for 'build.prop editor'

Xposed appsettings and resident ur app. It's the easiest and fastest way.
Gesendet von meinem Xperia SP

After tweaking init.rc
As for a memory management, after you tweak init.rc, you can get your init.d scripts looked at first [which is as it should be] and include the script(s) there. This way your boot.img doesn't swell up like a balloon
Rob[/QUOTE]
Hi Rob, I found this very helpfull and edited the init.rc file in the boot.img. It worked magically - but just for a few days.
Looking into process statistic I found that there was barely free RAM - even after rebooting. Is it that what you ment with: "you can get your init.d scripts looked at first [which is as it should be] and include the script(s) there. This way your boot.img doesn't swell up like a balloon "
I have to admit, I don´t no what I would have to do with the init.d scripts, beside of the fact, that I did not found a file with that name in the firmware. Any help or advice would be very much appreciated.
Thanks
Michael

micbin said:
I have to admit, I don´t no what I would have to do with the init.d scripts, beside of the fact, that I did not found a file with that name in the firmware. Any help or advice would be very much appreciated.
Thanks
Michael
Click to expand...
Click to collapse
Init.d is a set of scripts that is executed during the initialisation phase of the phone. So, instead of increasing the size of the tiny boot image by adding a few more lines into init.rc, you can create a script and add it to the init.d folder.
As far as I know, init.d runs after init.rc has completed execution, but still much before Android boots, so you can use it to apply your memory management mods.
From your message above, I feel you haven't understood some things properly. Init.d is not a file but a folder which can contain many number of scripts which are executed one by one in alphabetical order at boot time. It is usually located at /system/etc/init.d or /etc/init.d.
In most of the phones this folder is absent by default because the stock kernel doesn't support init.d.
Refer to this to get init.d support on your phone without having to switch to a new kernel.

Related

[Q] VEGAn Boot Sequence

With VEGAn 5.11 and Pershoot kernel. I want to do a few things when it boots up. I don't see the usual /etc/init.d kind of structure.
I did find init.rc and even found a link that describes its peculiar syntax. But editing that file (after remounting) doesn't "take" -- I assume it is on initfs and gets copied to a RAM disk on boot.
Is there anywhere easily user writeable where you can stick something in the boot sequence? Seems like that would be a common enough thing to need to do.
Thanks!
The init.rc is in the ramdisk, and the ramdisk is in the boot.img (found in all the stock and modded ROMs).
Here's a good guide on how unpack / repack that file: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
(obviously it's a bit technical) What I can tell you is that you don't need any cmdline options for the boot.img
Here's a real quick breakdown of what I do (Ubuntu user):
Code:
./unpack-bootimg.pl boot.img
go to the extracted ramdisk folder, make my changes and then:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
cd ..
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
"newboot.img" being my new boot.img. That's how the boot.img in all my mods are created.
Thank you and yeah I figured that was it. Technical is not an issue as I sling unix/linux for ages. Salute to you for all your work on this platform.
Well I cheated a little. Here's what I did:
I noticed that you had added to the bottom of /init.rc a one shot service for /system/etc/shuttle_ins.sh.
So I just remounted rw for /system and added the following to the TOP of /system/etc/shuttle_ins.sh:
# added by aaw
if [ -f /system/etc/rc.local ]; then
sh /system/etc/rc.local &
fi
# end aaw
So now I can put what I want in rc.local -- start up sshd or whatever. In this case here's what I actually wanted:
#!/bin/sh
# this is run at the end of the init.rc sequence if it exists
until mount | grep -m1 sdcard2 ; do sleep 5 ; done # wait for sdcard2 mount
mkdir /mnt/sdcard/sdcard2 # make mount point (might fail, but who cares?)
mount -o bind /mnt/sdcard2 /mnt/sdcard/sdcard2
Of course, this assumes I will always have sdcard2 or it spins. Could put a timeout in I guess, but for me this is always the case. Now things like players that only look in /sdcard can find stuff on sdcard2 as well.
A bit of a hack. I wonder if the release DEVs would consider adding an rc.local in user land in a nicer way? Maybe have a system rc.0 that does the -f test for rc.local and that way if you wanted to add an rc.local you could but if you didn't no harm or foul.
Or did I miss a smarter way to do this?
Thanks for the help (and the great releases, of course!).
I found this in the market: https://market.android.com/details?id=os.tools.scriptmanager
Lets you run scripts at boot time. Haven't tried it for that though, but it could work instead of my rc.local fix. A little different since I assume it runs late (after Android is up) unlike the rc.local which runs before Android, unless I'm mistaken.

Useful things to throw into froyo.user.conf

I've been building a list of commands that gets executed into froyo.user.conf. Use this as a reference, as I won't be responsible for your Rhodium exploding.
# Dealing with incomplete swapfile support in userinit.sh
swapon /sdcard/swapfile
# busybox /bin/sh is 10000x better than what's in /system
mount --bind /bin/sh /system/bin/sh
# I use F22's b1home setup, not only do I get needed symbols, it doesn't do idiotic stuff like define SMS to GRAVE, then redefine GRAVE to 0x03 (Ctrl-C) in the kcm file - read my post below on how to do this
mkdir -p /init.etc/keymaps/custom
cp -a /sdcard/*.kcm* /sdcard/*.kl /init.etc/keymaps/custom
# Create /data/local if it doesn't exist, then symlink bin to /sdcard/bin if that doesn't exist
mkdir -p /data/local
[ -e /data/local/bin ] || ln -s /sdcard/bin /data/local/bin
There is now a file that is called /sdcard/local.prop that gets copied on boot. Anything related to setprop can be set there, ie. I have:
dalvik.vm.execution-mode = int:jit
dalvik.vm.heapsize = 32m
ro.cdma.home.operator.alpha seems unnecessary now, but you must still have a valid eri.xml (again residing in /sdcard) to get the system to show you the provider.
-- Starfox
---
This is for legacy FRX06 or earlier, kept as reference:
# Readahead for /sdcard as per hyc
echo 2048 > /sys/devices/virtual/bdi/179:0/read_ahead_kb
# Dealing with incomplete swapfile support in userinit.sh, I use a 32mb file
swapon /sdcard/swapfile
# CDMA stuff, /etc gets rebuilt on every boot for now
echo "ro.cdma.home.operator.alpha = Sprint" >> /etc/default.prop
echo "ro.cdma.home.operator.numeric = 31000" >> /etc/default.prop
# CDMA stuff since I keep the Sprint SIM in & changing dalvik to jit
sed -e 's/default_network = 0/default_network = 4/' -e 's/vm.execution-mode = int:fast/vm.execution-mode = int:jit/' /system/build.prop > /sdcard/build.prop
# Bigger heapsize
echo "dalvik.vm.heapsize = 32m" >> /sdcard/build.prop
# /system/build.prop is mounted from /tmp, bindmount mine instead
umount -f /system/build.prop; mount --bind /sdcard/build.prop /system/build.prop
# GPS (0,0) fix
umount -f /system/lib/libhardware_legacy.so; mount --bind /sdcard/libhardware_legacy.so /system/lib/libhardware_legacy.so
# Using hyc RIL
mount --bind /sdcard/libhtcgeneric-ril.so /lib/froyo/libhtcgeneric-ril.so
# hyc's injection RIL lib
mount --bind /sdcard/libril.so /system/lib/libril.so
# Use /bin/sh (Busybox) over statically compiled sh, esp. for arrow key support
mount --bind /bin/sh /system/bin/sh
# I keep eri.xml and serialno in /sdcard/conf, and an empty dir called local
cp -a /sdcard/conf/* /data
# Term emu puts /data/local/bin in path first, I keep some binaries in /sdcard/bin, need to /data/local first
ln -s /sdcard/bin /data/local/bin
Nice. May want to note that the GPS 0,0 fix requires a fixed library.
Two sources for this:
1) Use the one on my testing thread
2) Extract it from system.ext2 of FRX06 (It may be difficult to do this with a running system due to the bindmounts. Although I see you're effectively unmounting the existing bindmount prior to mounting the new one - I should try this weekend to see if that is enough to get the fix to work with FRX06.)
2) is preferable as it's the official release, although it should be identical to mine.
Thanks alot for doing this.
Any chance you could attach the files you are showing to replace in some of your commands? Like some I see are 'build.prop', 'libhardware_legacy.so', 'libhtcgeneric-ril.so' and 'libril.so'.
Or possibly link to the original thread/post you got this from?
where do we put these in froyo.user.conf
anish88 said:
where do we put these in froyo.user.conf
Click to expand...
Click to collapse
Most go in CustomCommands...
Starfox said:
I've been building a list of commands that gets executed into froyo.user.conf. Use this as a reference, as I won't be responsible for your Rhodium exploding.
Click to expand...
Click to collapse
I hope to see most of these already incorporated in the next release...
# Readahead for /sdcard as per hyc
echo 2048 > /sys/devices/virtual/bdi/179:0/read_ahead_kb
Click to expand...
Click to collapse
I've requested this readahead patch to be merged.
# Dealing with incomplete swapfile support in userinit.sh, I use a 32mb file
swapon /sdcard/swapfile
Click to expand...
Click to collapse
Current Android system_server is too stupid to work well with swap. And I think our low_memory_killer settings need to be tweaked to work well with it. I haven't spent any time investigating but it definitely slows down too much. I would recommend against using swap for now.
# CDMA stuff, /etc gets rebuilt on every boot for now
echo "ro.cdma.home.operator.alpha = Sprint" >> /etc/default.prop
echo "ro.cdma.home.operator.numeric = 31000" >> /etc/default.prop
# CDMA stuff since I keep the Sprint SIM in & changing dalvik to jit
sed -e 's/default_network = 0/default_network = 4/' -e 's/vm.execution-mode = int:fast/vm.execution-mode = int:jit/' /system/build.prop > /sdcard/build.prop
Click to expand...
Click to collapse
CDMA stuff is going to be automated in next ril. No more manual prop settings needed.
# Bigger heapsize
echo "dalvik.vm.heapsize = 32m" >> /sdcard/build.prop
Click to expand...
Click to collapse
Good idea.
# GPS (0,0) fix
umount -f /system/lib/libhardware_legacy.so; mount --bind /sdcard/libhardware_legacy.so /system/lib/libhardware_legacy.so
# Using hyc RIL
mount --bind /sdcard/libhtcgeneric-ril.so /lib/froyo/libhtcgeneric-ril.so
Click to expand...
Click to collapse
These should no longer be needed when my rootfs requests are merged.
# hyc's injection RIL lib
mount --bind /sdcard/libril.so /system/lib/libril.so
Click to expand...
Click to collapse
I've requested that this be merged too.
# I keep eri.xml and serialno in /sdcard/conf, and an empty dir called local
cp -a /sdcard/conf/* /data
Click to expand...
Click to collapse
New system image will have a nicer default eri.xml ...
Does this look right? It's hard tell because it's all a jumble in notepad. I highlighted the two items I added in red.
Code:
# General parameters
general{
renice=1 # Run the renice script to inprove call answering
}
#compcache related parameters
compcache{
compcache_en=1 # enable(1) or disable(0)20 compcache
cc_disksize=100 # Ram swap disksize - any number between 1 to 98 should
work; default is 1/4 of the RAM (24)
cc_memlimit=64 # Limit the memory usage for backing swap (cc .5x known issue-defaults to
15% of total RAM)
cc_backingswap_en=0 # enable(1) or disable(0) backing swap
cc_backingswap=/dev/block/mmcblk0p4 # pointing to
the backingswap partition device, swap
}
#create swap file for compcache or linux swap
swap_file{
swap_file_en=0 # set to 1 to
create swap file
# set to 0 to del the swap file
linux_swap_file_size=32 # swap file size in MB
linux_swap_file=/sdcard/swapfile # pointing to the swap file location ( must be /system/sd/)
}
#Linux swap parameters
#
# linux
swap can only be enabled if cc_backingswap_en is set to "0"
#
linux_swap{
linux_swap_en=0 # enable(1) or disable(0) linux swap
linux_swap_partition=/dev/block/mmcblk0p4 # swap partition device
}
#virtual memory
sys_vm{
sys_vm_en=1 # enable(1) or disable(0)
virtual memory configurations
swappiness=0 # default 60
page_cluster=0 # default 3, (0 since CM3.9.6+)
laptop_mode=5 #
default 0
dirty_expire_centisecs=3000 # default 3000
dirty_writeback_centisecs=1500 # default 500
dirty_background_ratio=3 #
default 5
dirty_ratio=5 # default 10
vfs_cache_pressure=200 # default 100 (tendency of the kernel to reclaim cache memory)
overcommit_memory=1 # default 0 (0=Heuristic 1=Always overcommit 2=Don't overcommit)
overcommit_ratio=80 # default 50 (% of
Physical+Virtual memory to allow allocation)
}
# custom shell commands, these commands run last
custom_shells{
chmod 777
/etc/dbus.conf
#echo 2 > /sys/devices/platform/msm_hsusb/usb_function_switch
rm -f /sdcard/fsck*.rec
modprobe ipv6
mount --bind
/sdcard/Android/libhtcgeneric-ril.so /lib/froyo/libhtcgeneric-ril.so
[COLOR=Red]# Bigger heapsize
echo "dalvik.vm.heapsize = 32m" >> /sdcard/build.prop# /system/build.prop is mounted from /tmp, bindmount mine instead
umount -f /system/build.prop; mount --bind /sdcard/build.prop /system/build.prop[/COLOR]#echo "Hello!!!" # example
#echo "You can create
your own commands here" # example
}
Avatar28 said:
Does this look right? It's hard tell because it's all a jumble in notepad. I highlighted the two items I added in red.
Click to expand...
Click to collapse
Looks fine - use Notepad++ if you're on Windows.
arrrghhh said:
Looks fine - use Notepad++ if you're on Windows.
Click to expand...
Click to collapse
Hmm, you're right. MUCH better.
System wouldn't boot into Android at first. Just went black when it should load the animated xdandroid splash screen. Finally realized that I wasn't thinking and needed to copy the build.prop file from the system folder to the SD card before I could call it. Oops.
would anyone care to provide some info on what each command does? benefits?
manny05 said:
would anyone care to provide some info on what each command does? benefits?
Click to expand...
Click to collapse
He's commented each line... if you're not sure then don't use it. highlandsun also went thru them pretty thoroughly.
I think the only thing that isn't in the category of "soon to be obsolete" or "explained by highlandsun" is the vm.heapsize tweak
I believe that vm.heapsize sets the maximum amount of memory a single app can use. As a result, it can sometimes fix applications that claim to be running out of memory when there is plenty of system RAM. (Traffic features in Google Maps are one thing that frequently breaks with the default setting of 12-16M)
Entropy512 said:
I think the only thing that isn't in the category of "soon to be obsolete" or "explained by highlandsun" is the vm.heapsize tweak
I believe that vm.heapsize sets the maximum amount of memory a single app can use. As a result, it can sometimes fix applications that claim to be running out of memory when there is plenty of system RAM. (Traffic features in Google Maps are one thing that frequently breaks with the default setting of 12-16M)
Click to expand...
Click to collapse
how much memory do you think an app needs? i mean how would i know what to set it to.
manny05 said:
how much memory do you think an app needs? i mean how would i know what to set it to.
Click to expand...
Click to collapse
If you read the OP, that value seems good. AFAIK the default is 12, in the OP it's set to 32.
manny05 said:
how much memory do you think an app needs? i mean how would i know what to set it to.
Click to expand...
Click to collapse
Most of the Android forums I've read seem to recommend 32m - which seems to be more than enough for any app I am aware of. I think the majority of cooked Android ROMs for other devices use that value.
Added support for bluetooth:
sed -e "s% /system/bin/hciattach % /data/local/bin/brcm_patchram_plus -r --enable_hci %" -e "s%-n -s 115200 /dev/ttyHS1 texas 115200 flow%--enable_lpm --baudrate 4000000 --patchram /sdcard/BCM4325.hcd /dev/ttyHS1%" -i /etc/init.rc
This of course assumes you have patchram and the hcd files in their respective place.
-- Starfox
Starfox said:
# Bigger heapsize
echo "dalvik.vm.heapsize = 32m" >> /sdcard/build.prop
Click to expand...
Click to collapse
If this heapsize line is all I want to use from the thread, should I omit the ">> /sdcard/build.prop"? This stuff is all over my head, but I'm thinking that portion might refer to other commands I'm not using and a file I might not have. Any illumination would be appreciated.
___________________
The following two commands from elsewhere (as pulled from manekineko's custom conf) enable droidwall. This seemed like a good thread for them to be in.
modprobe xt_owner
modprobe ipt_REJECT
Click to expand...
Click to collapse
For those using F22's rootfs with the new keymaps and would like to use it over the somewhat braindead one residing in FRX07, these commands will help you keep the mappings:
1) While using F22's rootfs with the correct physkeyboard, copy raph_navi_pad.* and microp-keypad.* from /etc/keymaps to /sdcard
2) Rename raph_navi_pad.kl to qwerty.kl
3) Switch over to FRX07, and add these lines to froyo.user.conf
cp -a /sdcard/*.kcm.bin /sdcard/*.kl /init.etc/keymaps/default
4) Then go to startup.txt, and delete any reference to physkeyboard=
This prevents the init from overwriting "our" keymaps with theirs, as keylayout processing occurs after parsing froyo.user.conf. The init copies whatever is in /init.etc/keymaps/default to the proper place in /system/usr/key*, then checks /init.etc/keymaps/$physkeyboard/ exist, then does the same for that directory.
If you want to preserve the default keymaps directory for some reason, you could also do:
mkdir -p /init.etc/keymaps/custom
cp -a /sdcard/*.kcm.bin /sdcard/*.kl /init.etc/keymaps/custom
And use physkeyboard=custom for steps 3 and 4.
Now time for a rant:
Really why even bother defining a key to GRAVE (microp*.kl) then defining GRAVE as 0x03 (aka Ctrl-C) in the .kcm file. You can see the generated .kcm.bin has that included, by hd microp*.kcm.bin, at the bottom. Also why take away a useable SYM popup with 0x09 (aka Ctrl-I or TAB), again in the .kcm file.
Also, the choice of b1home vs b4home. IMHO Android is too unstable to lose ENDCALL. I can recall a number of times the system became unusable with an active phone call. Relying on touch screen interaction to end a call, on a what is still an unstable port, is quite idiotic. Not to mention you lose that nice end button feature in Spare Parts. You still need the same keypress to get to the dialer with either (as pressing takes you to either the home or contact list, and another to go to dialer).
-- Starfox
Updated post for FRX07, first and last post has been edited.
-- Starfox

[HOWTO] Install GNU/Linux on the Huawei S7 && Development thread (Kernel & GB)

[HOWTO] Install GNU/Linux on the Huawei S7 && Development thread (Kernel & GB)
Installing GNU/Linux on the Huawei IDEOS S7
( Using Debian or Ubuntu )
THIS GUIDE IS A WORK IN PROGRESS!
USE AT OWN RISK!​
Requirements:
Gnu/Linux experience! THIS IS NOT INTENDED FOR THE FAINTHEARTED!
Debian or Ubuntu.
The Google Android SDK Or at least adb and Fastboot
Busybox and a terminal emulator for Android.
A rooted device. See http://forum.xda-developers.com/showthread.php?p=14321729#post14321729 For how to root the Huawei S7 Android (2.2.2)
UPDATE:
New Image available.
Compatible and tested on :
-Huawei S7
-Huawei X5 / U8800(not quite done yet),
-RK2818 based devices,
-Samsung Galaxy s2.
Add "setprop ctl.stop bootanim" to the chroot command in "startnix-s7/other/rk.sh" on targets newer then gingerbread.
The image is using the MSM/QSD X11 driver for video,
ext3-4 modules for chroot on Android 2.2.2 stock image
xinput calibrator for screen calibration
Recompiled udev making that compatible.
And also a new sane kernel. which can be fastbooted with this image where ext3-4 are included and compiled-in. This kernel is necessary for enabling acceleration on the MSM/QSD X11 driver, using DRM. Swap and alsa(hopefully) are also enabled, ++, currently for _testing_only_!
Read post #11 for information - Merry Christmas and a Happy new year to you all!!
Setting up an image.
dd if=/dev/zero of=arm-linux.img bs=1024 count=2097152 to create a 2gb image.
mkfs.ext2,3 or 4 arm-linux.img , see post 10 for ext3 and 4 modules. as well as jbd and jbd2 which need to be insmodded.
Setting up a partition.
Plug it into your pc running Debian or Ubuntu, have usb storage selected on the device.
Back up everything on the 8GB Fat32 partition. I did this with a simple tar -cf android-back.tar /media/8gigandroidmountpoint. Verify that .android_secure is properly packed, but i also strongly suggest using titanium backup to backup application data and settings first then backup with a .tar. That cant fail.
Create a mountpoint and locate the special device of the S7.
Once you are absolutely sure you backed your partition, proceed with partitioning. Also be warned that ext2 is very prone to dataloss if not properly unmounted before rebooting, And by default, the s7 only supports ext2. So be sure and remember to have unmount any ext2 partition properly when done in Gnu/Linux, run sync as root before exiting, And have e2fsck handy. i have had to edit /etc/mtab back in due to corruption a dozen times when i was using ext2!
Code:
cfdisk -z /dev/sdx
I recommend at least 2Gb's. You can always increase the size of the partition later using tools such as gparted , but be aware, gparted might wreak havoc on your fat32 partition!
Now, create the first partition. It is very important that you make the first partition a Fat32 partition or the pad might go mad and operating systems with Multiple $clerosis wont see the partition! Choose "Type" and enter "0B" (FAT32). Create the second partition using the remaining space.
Select "Write" then Exit.
Now, do mkfs.vfat /dev/sdx1 and mkfs.ext2,3 or 4 /dev/sdx2.
Installing.
Once this is done we make ourselves a temporary directory, lets say mkdir /media/deb and loop mount the image or the partition there.
Instruct debootstrap to get the base packages for squeeze (Debian 6.0),
Squeeze is based on kernel 2.6.32 and is therefore safest to base our installation on, as Android 2.2 is designed with 2.6.32 in mind. The s7 is a armv7 so we could also use armhf, the drawbacks are its not quite done yet, and there is currently no video driver for our device available from me or the debian repo tested for armhf.
Code:
apt-get install debootstrap
# Adjust .nl. for your closest Debian mirror. Saves time and energy.
debootstrap --verbose --arch armel --foreign squeeze /media/deb [URL]ftp://ftp.nl.debian.org/debian[/URL]
Now using adb from the Google Android SDK and a usb cable, enter a shell and do the following.
(NOTE: I'm using /sdcard2 , which is the mountpoint to any external sdcard as the mountpoint, the reason for this is lazyness, creating a new folder on the s7's filesystem requires you run psneuter, remount the fs, then create your directory, see my rooting thread for that, you must change this if you are using an sdcard)
Code:
adb kill-server
adb start-server
adb shell
su
# For loopback image
mknod /dev/block/loop255 b 7 255
busybox losetup arm-linux.img /dev/block/loop255
mount -o rw -t ext2,3 or 4 /dev/block/loop255 /sdcard2
# For partition
mount -o rw -t ext2,3 or 4 /dev/block/vold/179:2 /sdcard2
export bin=/sdcard2/bin
export PATH=$bin:/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:$PATH
export TERM=linux
export HOME=/root
cp -r /etc/firwmare/* /sdcard2/lib/firmware/
cp -r /etc/wifi/* /sdcard2/lib/firmware/
cp /sbin/adbd /sdcard2/sbin
cp -r /dev /sdcard2/
chroot /sdcard2 /debootstrap/debootstrap --second-stage
# Adjust .nl. for your closest Debian mirror.
echo 'deb [URL]ftp://ftp.nl.debian.org/debian[/URL] squeeze main' > /sdcard2/etc/apt/sources.list
Tell it what nameserver to use, probably your routers IP address.
In this case we'll just use Googles DNS that should work in any case.
Code:
echo 'nameserver 8.8.8.8' > /sdcard2/etc/resolv.conf
echo 'nameserver 8.8.4.4' >> /sdcard2/etc/resolv.conf
Lets drop by our new home and make it nice and comfy.
Code:
chroot /sdcard2 /bin/bash
Once in, we need to do a quick few mounts, a fast few mknodes and a little bit of linking to make things fully functional.
Code:
mount -t devpts devpts /dev/pts
mount -t proc proc /proc
mount -t sysfs sysfs /sys
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/2 /dev/stderr
ln -s /proc/self/fd/1 /dev/stdout
mknod /dev/block/loop255 b 7 255 # Shouldn't really be needed as we just copied /dev
ln -s /dev/ptmx /dev/pts/ptmx
#mknod /dev/pts/ptmx c 5 2
# ln -s /dev/input/event0 /dev/event0
ln -s /dev/graphics/fb1 /dev/fb1
ln -s /dev/graphics/fb0 /dev/fb0
Creating the /etc/mtab file
The /etc/mtab file should look something like this.
Code:
/dev/block/vold/179:2 / ext2 rw,noatime 0 0
# or - You should have figured to adjust for ext 2 3 or 4 now?
/dev/block/loop255 / ext2 rw,noatime 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
devpts /dev/pts devpts rw 0 0
The FS should always be mounted with the noatime option! This reduces load considerably and conserves sdcard!
mount -o rw,noatime -t ext2 /dev/block/vold/179:2 /sdcard2 for instance
/etc/fstab should look like this: (remember to adjust / )
Code:
/dev/block/loop255 / ext3 defaults,noatime 1 1
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
Setup a password for the root account.
For some reason i had to run dhclient to get online at first, even though ifconfig shows me as connected. Also be aware that when Android falls asleep it puts the wlan0 device to sleep, dropping the connection. Pinging something with -i 90 is a temporary workaround for this.
Setting up OpenSSH
Code:
apt-get update
apt-get install openssh
(OPTIONAL) To configure your locale settings to use a language other than English, install the locales support package and configure it.
Currently the use of UTF-8 locales are recommended.
Code:
apt-get install locales
dpkg-reconfigure locales
(OPTIONAL! ) The "tasksel install standard" command installs all packages marked as "standard" packages for the selected distribution. Running just tasksel will promote you with several choices. tasksel --initial will promote you with installing the base system.
For things like the touchscreen to work properly we need to populate /dev.
Code:
# NOT NEEDED ANYMORE , USING DIFFERENT APPROACH! - leaving for reference
#mknod /dev/kgsl-3d0 c 244 0
#mkdir /dev/input
#mknod /dev/input/input0 c 13 64
#mknod /dev/input/input1 c 13 65
#mknod /dev/input/input3 c 13 67
#mknod /dev/input/input4 c 13 68
#mknod /dev/i2c-0 c 89 0
#mknod /dev/i2c-1 c 89 1
Poking around i figured out the touchscreen and stuff.
input0 = Hid Ofn
input1 = Touchscreen
input2 = Sensor
input3 = Keypad
input4 = Handset
After the installation there will be a lot of downloaded packages in /var/cache/apt/archives/. You can free up some diskspace by running:
apt-get clean
I then created a small script to drop into GNU/Linux a bit easier, note the path of the modules.
Code:
su &
if test -e /mnt/sdcard/arm-linux/linux/bin/bash # or /sdcard2/bin/ if your using a partition
then
echo "Already mounted."
else
busybox insmod /mnt/sdcard/arm-linux/s7/jbd.ko
busybox insmod /mnt/sdcard/arm-linux/s7/ext3.ko
busybox insmod /mnt/sdcard/arm-linux/s7/jbd2.ko
busybox insmod /mnt/sdcard/arm-linux/s7/ext4.ko
# For loopback image
mknod /dev/block/loop255 b 7 255
busybox losetup arm-linux.img /dev/block/loop255
mount -o rw,noatime -t ext2,3 or 4 /dev/block/loop255 /sdcard2
# For partition
mount -o rw,noatime -t ext2,3 or 4 /dev/block/vold/179:2 /sdcard2
fi
export bin=/sdcard2/bin/ # or /mnt/sdcard/arm-linux/linux if your using an image
export PATH=$bin:/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:$PATH
export TERM=linux
export HOME=/root
export SHELL=/bin/bash
# You can also do
#'setprop ctl.stop zygote & setprop ctl.stop media && chroot /sdcard2/ /bin/bash && setprop ctl.start zygote & setprop ctl.start media'
# This will kill the Android wm, start chroot, and once you quit return you to
# android, but that doens work in an android terminal, only via adb.
chroot /sdcard2 /bin/bash
This needs to be expanded with another script since you still need some mounts (sysfs devpts and proc), i just dropped them in the .bashrc file in /root for now.
Code:
if test -e /sys/class/graphics/fb0/uevent
then
echo "All sys mounts already mounted."
else
mount -a
#service hal start
hald --daemon=yes
service ssh start
fi
cd
For Xorg
I've compiled the MSM/QSD X11 drivers, which should provide "limited 3d acceleration, provided they works, here is the status of that so far:
http://threader.zapto.org/s7/dev/msm-drv/xf86-video-msm-6fd8528-gcc46-2-rgb-fix-accel-6.tar , Colour working, needs NoAccel on production kernel. With accel enabled on the production kernel, there are no errors shown when starting X as there were. But Lxde first appears, tjen the menu, taskbar, background, and the rest vanish in a puff of smoke, leaving only the pointer and which can be moved about corruption regions of the screen. This is because certain features were left out of the production kernel. Using the kernel provided in post #11, acceleration works!
You can always check http://threader.zapto.org/s7/dev/msm-drv/ and try out some of the others I've compiled and see if there are any speed issues, sources are also available.
Now to enter the X server, the first thing you really want to do is have your ssh server running and connect to it. You can start your xserver and have all resources devoted to it by having passed "setprop ctl.stop media & setprop ctl.stop zygote" to android in the ADB. Starting zygote again is merely a 'setprop ctl.start zygote & setprop ctl.start zygote'.
The HTC Dream is fairly similar to our device, similar as in its a QSD8x50 device, we should be able to borrow some of their work, this is probably optimized and should be fast, http://build.shr-project.org/shr-unstable/images/htcdream/ its good for reference anyway.
Some problems i ran into. # Outdated but leaving for reference.
When trying to ssh in, after a reboot, i got a rather nasty error.
PTY allocation request failed on channel 0
if present remove /dev/ptmx and do mknod /dev/ptmx c 5 2 then redo these mounts or make sure they are properly mounted.
mount -t devpts devpts /dev/pts
mount -t proc proc /proc
mount -t sysfs sysfs /sys
TIPS:
Install localepurge! This will save a lot of space!
Install a vncserver and try setting up an X session your happy with, i would recommend the use of lxde and openbox to minimize the memory footprint and to conserve space and ram as the s7's kernel is compiled without swap enabled (o,0).
Configure xorg.conf in /etc/X11/xorg.conf with the config i posted in #3 http://forum.xda-developers.com/showpost.php?p=14594464&postcount=3
Be sure to properly unmount the ext partition before you reboot your device! Especially ext2 partitions are prone to dataloss!!!!! Use "sync" as root atleast before exiting!
install matchbox-keyboard ( an onscreen keyboard )
Starting X11 was an oddball first few attempts! As the fbdev driver isn't really compatible with the qsd8250 gpu, it blanks out the screen and doesnt know how to revert it. With android still running, I experimented with startx -- :1 and stuff the xorg.conf but ended up using just startx and found that repeatedly pressing the power button (quite frantically) (once the screen blanked out), low and behold, the x session miraculously appeared! This was before i had even "thunk" about compiling the qsd msm driver and before the xf86-video-msm driver in wheezy Debian.
Congratulations, you should now have a fully working Debian install on your Huawei S7!
-------------------------------------------------------------------------------
Clean booting into the Debian partition!
Configure /etc/fstab: # Outdated , needs updating, see arm-linux.img
Code:
# /etc/fstab: static file system information.
#
# file system mount point type options dump pass
/dev/block/mmcblk0p2 / ext2 defaults 1 1
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /media/sdcard vfat defaults 0 0
Add "/sbin/adbd &" to /etc/rc.local and make a symlink so adbd can find sh or bash. (NB, was unsuccessful in my attempts at this for unknown reasons, did not fight it to long.)
# mkdir -p /system/bin/
# ln -s /bin/bash /system/bin/sh
apt-get install wpasupplicant network-manager-gnome wireless-tools
mv /etc/init.d/udev /etc/init.d/dis for now, this is a showstopper.
Get fastboot http://developer.htc.com/adp.html
Grab the zImage
(s7 10x -- Self compiled kernel,with ext3-4,drm,alsa(hopefully,powermanagement etc. _TESTING_ONLY_ copy lib to / , System.map to /boot/ and add dhd.ko to /etc/modules run depmod somehow ) http://threader.zapto.org/s7/kernel/2.6.32.9-ideos-fs-snd-drm-sane-5.tar.bz2
(s7 101 -- stock rom image ) http://threader.zapto.org/s7/rom/extracted/output-brazil/kern/zImage
(s7 other then 101 -- stock rom image ) http://threader.zapto.org/s7/rom/extracted/output/zImage
Configure the network:
To configure the network we need to copy a module from android dhd.ko from /lib/modules/ to /lib/modules/2.6.32.9-ideos/kernel/ and create an entry in /lib/modules/2.6.32.9-ideos/modules.dep kernel/dhd.ko: then run depmod -a from within Debian and add dhd to /etc/modules
Boot Debian:
Put the device into fastboot mode
$ adb reboot bootloader
The '-c' flag specifies arguments to pass to the kernel for boot.
This is probably the bare minimum.
Format is "fastboot -c 'kernelcmdline' boot zImage"
fastboot -c 'root=/dev/mmcblk0p2 rw rootfs=ext2 init=/sbin/init rootwait noinitrd' boot zImage
Please help feed my Linux addiction! Go to http://threader.zapto.org and click Donate!
TODO:
Clean boot from the Debian partition using fastboot.- DONE
Compile the codeaurora.org MSM/QSD X11 drv - DONE
Compile a sane kernel, with all the features you'd expect from a Linux kernel - DONE
Create a boot image with the new kernel compatible with the S7 101-105 possibly 201(slim) capable of booting Android and Linux, either from an early boot menu or using chroot. (WIP)
Hack up an existing rom, or compile 2.3.7 and make a complete solution. (TBA)
Stop playing Angry Birds, Dragon, FLY! XConstruct, Finger physics and Skies Of Glory when i should be doing this! - NEARLY ALMOST MOSTLY COMPLETELY DONE(ish) ;Þ
References & useful stuff! This would never have been possible in this short of a time if it weren't for these excellent posts. (Woaw, i sounded so optimistic in june 2011. The initial work was quick, over half a year later though im still not done! "Just gotta fix that last little ting before... Hey! i discover another little thing ...!
http://www.saurik.com/id/10
http://www.debian.org/releases/stable/i386/apds03.html
http://www.irregular-expression.com/?p=30
forum.xda-developers.com/archive/index.php/t-830077.html
http://forum.xda-developers.com/archive/index.php/t-830077.html
For development
git clone git://codeaurora.org/kernel/msm.git android-msm-2.6.32
https://www.codeaurora.org/gitweb/quic/xwin/
https://www.codeaurora.org/gitweb/quic/xwin/?p=xf86-video-msm.git;a=shortlog;h=refs/heads/chromium
http://gitorious.org/htc-msm-2-6-32...d65936b8bbc8708f352719/include/drm/kgsl_drm.h
https://github.com/tmzt/androix-xserver
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
/etc/X11/xorg.conf
Code:
Section "Device"
Identifier "msm"
# For MSM/QSD X11
Driver "msm"
Option "fb" "/dev/fb0"
# For fbdev
# Driver "fbdev"
# Option "ShadowFB" "on"
# Option "Rotate" "CW"
# for MSM/QSD X11
Option "NoAccel" "true"
# Option "SWBlit" "true"
EndSection
Section "Screen"
Identifier "Framebuffer"
# Device "fbdev"
Device "msm"
Monitor "Monitor"
# DefaultFbBpp 24
SubSection "Display"
# Depth 24
Modes "800x480"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Builtin Default Layout"
Screen "Framebuffer"
# InputDevice "Trackball" "CorePointer" # Reserved for buttons .
InputDevice "Touchscreen" "CorePointer"
InputDevice "Keyboard" "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Touchscreen"
Driver "evdev"
Option "Device" "/dev/input/input1"
# Option "ScreenNumber" "0"
Option "ReportingMode" "Raw"
Option "ReportingMode" "Scaled"
Option "ButtonNumber" "1"
Option "SendCoreEvents"
EndSection
Section "InputDevice"
Identifier "Keyboard"
Driver "kbd"
# Option "XkbLayout" "en_US"
EndSection
This is Debian running cleanly from without the chroot environment
After doing some debugging from within chroot and Android, without the /etc/xorg.conf doing a startx -- :1 and repeatedly pressing the power button (quite frantically) (once the screen blanked out) the x session miraculously appeared! But i couldn't use it since it didn't know of a pointer device.
I managed today to configure the touchsreen correctly, i can now use xfce and x11 from within chroot in android ,but ironically enough im unable to get it up (phun intended) in a clean boot at all, here im using matchbox-keyboard
zImage
Hello,
the links about zImage
Grab the zImage link(s7 101) link (s7 other then 101 dont know why this is 2 megs! and the other 1.4)
are broken.
Can you share zImage again?
Best regards and thanx for great work
Hi!
I've extract kernel using guide: HOWTO: Unpack, Edit, and Re-Pack Boot Images on android-dls.com/wiki/.
but at the end, i've have problems in dhd module. Can't modprobe without error at linux boot.
Now trying to run ubuntu 11.04. Installing "ubuntu-desktop" packages in chroot
santiagax99 said:
Hi!
I've extract kernel using guide: HOWTO: Unpack, Edit, and Re-Pack Boot Images on android-dls.com/wiki/.
but at the end, i've have problems in dhd module. Can't modprobe without error at linux boot.
Now trying to run ubuntu 11.04. Installing "ubuntu-desktop" packages in chroot
Click to expand...
Click to collapse
Hey, good stuff, use whatever kernel from whatever rom absolutely works on your droid.
It's also dawned on me there most probably might be an issue with the port of the x11 driver, thankfully i still have everything.
http://threader.zapto.org/ - im guessing everything i used is there, if i find more i'll put it up, if its down try again later. I also added a donate button to help feed my Linux addiction =)
The dhd.ko is here - http://threader.zapto.org/s7/rom/extracted/output/sys/lib/modules/dhd.ko
Also Ubuntu is a memory hungry beast, i would recommend Debian 6.0x/squeeze lxde+xfce.
Hi, how it's going with TODO:
Stop playing angrybirds, xconstruct and skies of glory when i should be doing this!
?
=)
installing Ubuntu fails because of my lazy =(
now i get some free time and trying to get working debian queeze on my S7.
I'll report back after finish.
---------- Post added at 03:22 PM ---------- Previous post was at 03:20 PM ----------
Also i think it's good idea to share complete image of partition with linux. Installing all packages on S7 takes much time =)
Hey,
Quite time consuming yes, and fiddly.
I was planning on sharing an image, but i had planned on having it a bit more complete and polished first. That just didn't happen however. But today i cleaned up http://threader.zapto.org and added an image of the partition. And got a fresh breath of motivation.
The image is 2.1 GB. If you write it to a partition, it needs to be equal to or greater then the image you write or you risk trashing the next partition or just failing to complete the write, i guess.
However, you can use a loop device Use the last available loop device, mknod /dev/block/loop255 b 7 255 to avoid conflict, and to mount the image using losetup /dev/block/loop255 s7-linux.img && mount -o noatime -t ext2 /dev/block/loop255 /sdcard2 . Do sync as root before rebooting.
http://threader.zapto.org/s7
http://shell.consolegfx.net/s7-linux.img.bz2 # Outdated - see post #11 or http://threader.zapto.org/arm-linux.tar.bz2
md5sum s7-linux.img
275b2fe0bbe0172910933e583835164c s7-linux.img
-rw-r--r-- 1 root root 2169503744 Nov 19 17:49 s7-linux.img
Password for root is root .
Now, i wont be working too much more on the fastboot approach, carrying around a pc to boot linux on the tablet just isnt practical at all. And i really need to have usb host confirmed and working. I have made progress on starting X11 cleanly. My current method of "setprop ctl.stop media & setprop ctl.stop zygote && chroot /mnt/sdcard/linux/ /bin/bash && setprop ctl.start media & setprop ctl.start zygote" works great from adb, but will fail in an android terminal emulator instantly restarting zygote as it quits the terminal app.
I also compiled some kernel modules and put up, mainly ext3 & 4, fuse, msdos, ntfs, but eventually some other goodies. Check http://threader.zapto.org/s7/modules/. None of these are included currently, and wont be until i upload a future version. That will be ext3, which hopefully wont be too far off, and i can already tell you it will include some substantial changes. It should also be infinently more usable, even for those that havent spent some 10+ years on linux. It would definitively be cool if i could releasing something with Digital video usb dongle support, wouldn't it?
Cheers!
-Mike
Btw. here's the next image running on the s7, as you can see there were some problems with the x11 driver, but i managed to fix that a bit so this is now working, but still Option "NoAccel". I can also report that even firefox 3.5 is running surprisingly smoothly. Over the next few days i will be working on the x11 driver and then internal gsm modem and bluetooth.
Driver working with Red and Blue switched:
Tada! Fixed driver!
Thanks where thanks are due must be given to Visor and Hydro for helping with hosting "o'huge ass image file" and such! Thanks!
KERNEL 'UPDATE!: :
--------------------------
I managed to find time to fix and compile the kernel! The new kernel boasts plenty of improvements over the stock kernel, most noticeably ext3-4 built in, drm, alsa, swap, some experimental features enabled like a new scheduler for the usb, and switch to the no-op scheduler, also a feature that could let us change kernels "mid flight", hopefully, with kexec. Added some fpu related optimizations. I was unable to get it booting with a newer compiler for now though, so its still soft-float. This kernel is half the size, or even less as debug symbols are disabled. The old kernel crawled to 7mb's , this is 3.3.
http://threader.zapto.org/s7/kernel/2.6.32.9-ideos-fs-snd-drm-sane-5.tar.bz2
Usage:
Take the tools folder from the tar.bz2 and copy it somewhere, preferably your home directory (as google sdk binaries are picky little pricks) extract the above archive and put zimage into the tools directory:
adb reboot fastboot
Kernel with modules, http://threader.zapto.org/s7/kernel/2.6.32.9-ideos-fs-snd-drm-sane-5.tar.bz2
Ramdisk extracted from stock bootrom: http://threader.zapto.org/s7/kernel/boot.img-ramdisk.gz
Extract 2.6.32.9-ideos-fs-snd-drm-sane-5.tar.bz2 somewhere on your machine, zImage is inside there.
Dont extract boot.img-ramdisk.gz
For booting Android:
Code:
fastboot -c 'console=ttyMSM2,115200n8 androidboot.hardware=qsd8k_s7' boot /path/to/2.6.32.9-ideos-fs-snd-drm-sane-5/zImage /path/to/boot.img-ramdisk.gz
For booting into linux (mmcblk0p2 is the device node for the second partition created on the 8gb internal sdcard, use mmcblk1p1 or 1p2 for external sdcard):
Code:
fastboot -c 'root=/dev/mmcblk0p2 rw rootfs=ext3 init=/sbin/init rootwait noinitrd' boot zImage
Thanks where thanks are due must be given to -ZEROsignal-. Visor and Hydro, for helping with hosting "o'huge ass image file" and such! Thanks!
Aosp 2.3.7 available for modders and powerusers!
Code:
experimental/aosp2.3/s7/README
Experimetnal build of gingerbread for the s7
Notes:
The build is 2G split, (vmsplit 2g), so given that a given library is compatible
these can be exchanged from 2.2 .
Its still software rendering via pixelflinger.
OpenGL works.
Notes on Wifi and Bluetooth, bcm4329 chipset.
An updated kernel driver, is included in /system/modules (bcm4329.ko).
I have however not come as far as to implement it properly, as i am currently fo
cused on the graphics bit.
Notes on graphics, gralloc-qsd8k has been fixed. Which meant updating the kernel
pmem driver a bit to accomodate this change.
renderscript (libRS and librs_ something ) crashes. Probably due to pixelflinger
Im sure a rom modder could have this rom running smoothly using the huawei 2.2 l
ibraries and such, and dhd.ko. Also delete /system/app/Provision.apk as this prevents booting!
Notes on boot.img:
The ramdisk content might be wrong! I might have copieid the wrong boot.img befo
re i left! This will get fixed.
And so it has, boot.img-dead is the old dead one, boot.img is the working one.
Directory structure named after build date
Cheers
-mike aka threader
Also arm-linux0.7 is shaping up, this is still an early version where i change a lot in preparation for a more general solution to publish on the google.code page.
Were now using freedreno x11 driver, which works well in chroot but doesnt work if you boot linux normally, the old msm-x11 driver works for this purpose.
I improved rendering alot, but still pixelflinger....it also appears that i introduced some rendering artefacts, these are however minimal.
http://code.google.com/p/lrfa/downloads/detail?name=system.img.bz2&can=2&q=
boot.img still on http://threader.zapto.org/experimental .
.
Hi! how's it going? what's new? long time no updates. Is there any success in running Linux? I would like to move to Linux as the primary operating system.
Hey.
Not much, still occasionally working to port the Codeaura Adreno GPU driver to the huawei kernel, which is a **** because of the version screweup which is the huawei kernel. Other then that there has been no news on the Android Gingerbread front since i last published http://threader.zapto.org/experimental/aosp2.3/s7/021212/ , which fixed audio and found a bug in the MDP which resulted in less glitching when fixed.
New kernel up on http://threader.zapto.org/experimental/s7/kernels/
Incomplete change list off the top of my head:
Patched from 2.6.32.9 to 2.6.32.60
Asturals msm kgsl with the following changes
- fixed kgsl_drm_init(null) which caused a kernel panic in older kgsl.
- patched exploit in kgsl
gcc 4.7 compatible - updated assembly.
clock code taken from 2.6.38.
AVS from 2.6.38
DRM from 2.6.38
Added memblock. Genalloc. Genlock.
Redone board file. (use board-qsd8x50-s7.c-full for full functionality)
msm-fb updated. Lcdc. Etc.
Retouched msm_battery-s7
and probably lots more.
Known bugs:
TBA ( TO BE ANSWERED )
Source : http://threader.zapto.org/experimental/s7/kernels/source/kernel-ideos-experimental-2.6.32.60.tar.bz2
Binary: http://threader.zapto.org/experimen...l-ideos-experimental-2.6.32.60/zimage-2gsplit
Happy hacking!
Hi threader, great work, will try and tell you how it goes.
One question have you tryied to move to 2.6.38 ?
cant we patch the 2.6.38 kernel with files we may need from 2.6.32 ?
hal_2000
Hey Hal.
Likewise
Still fixing some minor bugs, re-worked the board-qsd8x50-s7 file again to make dhd happy, and found a hw def that makes anything we compile think its a 8250. Tell me, is it the 103 or 20x that uses the 8250? I think that code should be moved to the board file.
I've been trying to move to 2.6.38, but i cant get it booting for some reason, i've actually got two 2.6.38 kernels i've been working on, neither give as much as a bleep. The one up in s7/experimental/ has everything it needs to boot, i think. I backported the board-qsd8x50.c file to the 2.6.32 kernel trying to rule that out, and thats whats in use there.. But its pretty hard to debug when i have no frame of reference (console output or anything).
Cheers
-Mike
hal_2000 said:
Hi threader, great work, will try and tell you how it goes.
One question have you tryied to move to 2.6.38 ?
cant we patch the 2.6.38 kernel with files we may need from 2.6.32 ?
hal_2000
Click to expand...
Click to collapse
Hi, i pick up the zimage file and make a boot.img file, it boot up the rom fusion but touch screen did not work and menu and home key also did not work.
Then used your kernel sources to try to compile a kernel for cm9 and it did not work, it hang at boot, i have a s7 model 105.
If you need more tests let me know.
as far i know que s7-10x uses a qsd8k board type and a cpu qualcomm snapdragon qsd8250 at 998Mhz, the 20x uses a diferent cpu. That why it uses diferent kernels, and i think there is more diference in hardware.
hal_2000

[Kernel, init.d] flawed init.d support stemming from doomlord kernels

It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.
I checked for sirkay 587c and 587d and for fly-kernel 0.8 as the latest of their breed, quite sure nobody has ever cared about this quirk.
The duplicate execution could be tracked back to the init.rc entries:
Code:
[COLOR=SeaGreen]#DooMLoRD: init.d scripts support
start sysinitsupport
class_start core
class_start main
#DooMLoRD: new init.d scripts support
service sysinitsupport /sbin/sysinitsupport.sh
class main
disabled
oneshot[/COLOR]
Which does:
Code:
#!/sbin/sh
# DooMLoRD: init.d support script (v1)
# [START] setting up
echo "[START] remounting system" > /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mount -o remount,rw /system >> /data/local/tmp/sysinitsupportlog.txt
# make init.d directory
echo "
[*] make init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox mkdir -p /system/etc/init.d >> /data/local/tmp/sysinitsupportlog.txt
# correcting permissions of files in init.d directory
echo "
[*] correcting permissions of files in init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
/sbin/busybox chmod 777 /system/etc/init.d/*
# [COLOR=DarkOrchid]make [/COLOR]init.d directory
echo "
[*] [COLOR=DarkOrchid]make [/COLOR]init.d directory" >> /data/local/tmp/sysinitsupportlog.txt
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /system/etc/init.d[/COLOR]
# [DONE] all done exiting
echo "[DONE] all done exiting" >> /data/local/tmp/sysinitsupportlog.txt
And later also in init.rc:
Code:
[COLOR=SeaGreen]#DooMLoRD: run my mods
service mymods /sbin/execute_mods.sh
class main
oneshot[/COLOR]
Which then does:
Code:
#!/sbin/sh
# starting
echo "[ START ]" > /data/local/tmp/log_doom-mods.log
echo "" >> /data/local/tmp/log_doom-mods.log
[COLOR=Red]# execute tweaks
/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
# execute FPS limit remove
/sbin/mount -t debugfs debugfs /sys/kernel/debug
/sbin/echo '0' > /sys/kernel/debug/msm_fb/0/vsync_enable
/sbin/umount /sys/kernel/debug
echo "FPS limit successfully removed " >> /data/local/tmp/log_doom-mods.log
# DONE
echo "" >> /data/local/tmp/log_doom-mods.log
echo "[ DONE ]" >> /data/local/tmp/log_doom-mods.log
You see that the execution of
Code:
[COLOR=Red]/system/bin/logwrapper /sbin/busybox run-parts /etc/init.d[/COLOR]
is actually done twice - from sysinitsupport.sh first and then again from execute_mods.sh
Also mind that the log-entry in the first is leading in the wrong direction (copy error from above). It should better read "execute init.d directory"
The related logs are found in \data\local\tmp.
You can check yourself with this little script in \etc\init.d:
Code:
#!/system/bin/sh
echo [] > /data/local/tmp/$PPID-exec-done
echo $PPID "init.d executed" >> /data/local/tmp/$PPID-exec-done
date >> /data/local/tmp/$PPID-exec-done
Mind the $PPID which is the parent PID of the executing command (the busybox "run-parts"). Per boot you should just get 1 file <PPID>-exec-done containing the timestamp if you get 2 then you know why...
I have attached the script wrapped in a zip file. Unpack it, copy to \etc\init.d (or if not sym-linked to \system\etc\init.d) and change attributes to "777". Reboot and look what you get in \data\local\tmp.
Once you know, remove the script again and delete the created files in \data\local\tmp.
Mind that the scripts referenced from init.rc are copied over again from the kernel part so any change of the scripts in the \system\sbin folder is useless. The kernel has to fix that, no way out here.
I've been looking into this issue as well with the help of dk_zero_cool (mounts2sd amongst other things) as no matter what I tried I could not get m2sd to run in anything other than Safe Mode because init.d was being run as a service and not being executed in full before the init continued. So far I have edited init.rc to remove the second instance you quote above, and edited the first instance to:
Code:
exec /sbin/sysinitsupport.sh
so it executes rather than running a service. I then edited sysinitsupport.sh to contain just this:
Code:
#!/system/bin/sh
export PATH=/sbin:/system/sbin:/system/bin:/system/xbin
/system/bin/logwrapper busybox run-parts /system/etc/init.d
and also removed the line in execute_mods.sh that relates to init.d, so now theoretically the only thing that should happen in relation to init.d is that the exec command runs sysinitsupport.sh which in turn runs the init.d scripts before anything else in init.rc happens. IN THEORY!!! Because even with all of that done (and I have searched through the whole ramdisk, plus looked at the git for the init binary used in the Lupus ICS kernel I am using to make sure I haven't missed anything) the m2sd init.d script is still running in Safe Mode because it is detecting /system/bin/servicemanager running at the point it tries to execute. So something somewhere is still starting before the execution of init.d. I even tried with the init binary from the latest CM9 build for the Ray to rule out something wrong in there too.
I have sent all my files to dk_zero_cool to see if he can shed any further light on what else may be wrong. I have checked four different Ray kernels and they all use the same DoomLord methods so I doubt whether there are any Ray kernels that are running init.d correctly. It would be great to find a fix for this. Hope more people chip in!
Thanks for opening the discussion
As I understood, you have made some changes in the kernel assembly (not the code) to circumvent the effects you have outlined. I admit that I have not fully understood YOUR concern - but for my double execution of the "run-parts" the deactivation of the relevant line in either of the 2 scripts should do it, or not?
Is your concern related to the situation that init.d cannot do "everything" at the time it is executing and so it cannot achieve what some scripts intend to?
I am far too little educated in the details of kernel execution privileges so cannot further comment on that
Yeah, pretty much - to avoid possible issues with the m2sd script moving stuff around while something else is trying to make use of it the first thing it does is check if servicemanager is running, and if it is it disables the ability to move things like /data and dalvik-cache to sd-ext. The changes that we made in the scripts SHOULD have changed the init.d implementation from it running as a service whilst the rest of the init process carried on, to being executed as a command allowing any init.d scripts to be executed prior to any other service being started - as I understand it this is how init.d was intended to be used (ie the user scripts in /etc/init.d are run fully before anything else). However as I said, even with these changes and everything else relating to init.d having been removed something is still starting servicemanager, and until the source of that can be isolated scripts like m2sd cannot run fully/safely.
I guess the strategy to check on servicemanager is not right here. This is a process that starts several services and should not depend on anything in the init.d. So if you say that the boot sequence would have init.d completed BEFORE any service is started via servicemanager - THEN this could be a flaw in the kernel.
However is that really true? Is there no option to check if certain "dangerous" (for your move purposes) services are active already instead of checking on the servicemanager? I had found a nice overview on the Linux boot process here and I think that somewhere as part of the various init.x excuted scripts the servicemanager simply MUST be started - init.d is just a part of init - and for sure not the first part of it.
Off Topic:
I wonder where I can get some more insight in the Xperia Kernels and how they are assembled - especially which trace of that is noticeable in the filesystem. I noticed that the ICS Kernel have roughly 340MB for the user space while the JB Kernel has 360MB. Device should have 512 MB RAM, then some MB go away for radio and possibly video buffer, but his should be the same for all (accross ICS/JB). So what kind of memory tweaking makes this 20MB difference? I have not found a good place to discuss this - where could I go to?
tobbbie said:
It seems that all Xperia Kernels that stem back to the DoomLord kernel start the init.d execution twice. While you may think "better twice than never" the nearly parallel execution of scripts can create problems if they concurrently manipulate CPU related tables - or fail to do so due to security mechanisms built in. I was hunting the problem that cpu-clock manipulation from init.d did not work for the scripts generated by System Tuner - finally resulting in this finding.
Click to expand...
Click to collapse
How about Radeon kernel? Is there an issue like you said?
Sent from my ST18i using Tapatalk 2
frogerra said:
How about Radeon kernel? Is there an issue like you said?
Sent from my ST18i using Tapatalk 2
Click to expand...
Click to collapse
Just try out (see the guide on 01test.zip) - nothing you can harm doing that.
kernel behaviour trick
I noticed some kernels (GB and ICS) do overwrite settings from /etc/init.d ....
So if you make an init.d script with specific cpu values, or VM settings...some kernel overwrite these with their compiled/preferred values "after" init.d scripts are executed. This way it looks as if your script is not completely accepted by the rom...but the truth is that the kernel applies its own preferred values afterwards.
Thats why my init.d script contains a wait of 60 seconds in the beginning of the scripts......how ? add:
sleep 60
So your script looks like this (example):
#!/system/bin/sh
# this init.d script is for when you apply doomlord kernel supplied with repack 2013
sleep 60
That will run your init.d goodies after one minute.
As you see I'm working on a revived repack4pda 2013 (GB) , which will be released soon in repack4pda thread.
Br.
Michel
I guess that these kernels may be doing the same what you are proposing - just sleep the shell process before action starts. So you need to lookup the call tree from the init process along the various init.*.rc scripts if this is the case. For duplicate execution of init.d content any timed scripts willl not help - the duplicate execution will just happen later as the same script will pause the same amount of time.
Not sure if the init process script execution is synchronous or not - so if you create scripts which sleep, the final signal for "boot completed" may just also delay and the whole boot process may take longer by that sleep time. As well would you just stack the delays after each other and so nothing is gained finally. Synchronous execution would make it impossible that a part of the init process could postpone beyond boot completed.
It may differ if you run the scripts via the "exec" command or let it execute via the servicemanager. I guess the latter may run them asynchronously - not sure here as well.

Problems with cron

Hi, I have made cron work on my 7" china tablet, it runs almost like I'd like it to..
I've made a passwd file in /etc with the following contents:
Code:
root:x:0:0::/data/cron:/system/bin/bash
I've made a symlink from /system/bin to /bin
And I've made a crontab file with the following line in it:
Code:
* * * * * /system/xbin/cat /sys/class/power_supply/battery/capacity > /dev/ttyACM0
Now the problem.. Cron runs fine, running the small bash code every minute, but..
ttyACM0 is a serial line to a microController - but the problem is that nothing is received on the controller, despite the cron running the script.
now if I LS /dev/tty* I get the following:
Code:
[email protected]:/ # ls /dev/ttyA* -l
ls /dev/ttyA* -l
crw------- root root 166, 0 2013-09-07 13:11 ttyACM0
-rw-rw-rw- root root 3 2013-09-07 13:14 ttyACM0
[email protected]:/ #
The cron creates an identical file in /dev and write it's data to this file, and not the *real* ttyACM0 serial..
I start the crond service in init.rc like this:
Code:
service crond /system/xbin/crond -c /data/cron
user root
disabled
oneshot
on property:dev.bootcomplete=1
.
.
start crond
If I change the cronscript to output to a flat file somewhere else (like /data/test_output), I can see the file with LS, but I'm not able to delete it nor cat it.
What's going on?
I need this to work in order to trigger a charger once the battery goes too low, and turn it off again once it has reached a given threshold. Not being able to send a simple command via serial really offsides this project.
Please help
Could it be that the cron job starts before the /dev/ttyACM0 is created?
hmm, I'll try and delay it a bit..
Made a simple check for if the device exists or not. if [ -c /dev/ttyACM0 ]This solves the problem.

Categories

Resources