I found out that the proximity sensor on my Note II isn't working as it should. Whenever I am on call, the screen goes off, but doesn't lit up when I move the phone away from my ear. I've investigated and found that calibrating the proximity sensor could solve the problem.
I've searched around but haven't found the right steps to calibrate the proximity sensor on Note 2. The 'Phone Tester' app shows weird behavior of the sensor. It sometimes just keeps waiting for the data and sometimes shows 'Far' , 'Near' status correctly. But once I move my hand near the sensor and then move it away, the status remains 'Near'.
I'd really appreciate recalibration procedure & any other recommended fix.
I would like to know the solution too
Handwritten from my Note 2
I have same problem too
Sent from my GT-N7100 using xda app-developers app
CrazyEngineer said:
I found out that the proximity sensor on my Note II isn't working as it should. Whenever I am on call, the screen goes off, but doesn't lit up when I move the phone away from my ear. I've investigated and found that calibrating the proximity sensor could solve the problem.
I've searched around but haven't found the right steps to calibrate the proximity sensor on Note 2. The 'Phone Tester' app shows weird behavior of the sensor. It sometimes just keeps waiting for the data and sometimes shows 'Far' , 'Near' status correctly. But once I move my hand near the sensor and then move it away, the status remains 'Near'.
I'd really appreciate recalibration procedure & any other recommended fix.
Click to expand...
Click to collapse
I think from check list call *#0*#:laugh:
Did any of you figure out a fix to this issue?
To calibrate the proximity sensor you need to edit the build.prop, file. Quickest way I do this is by using Romtoolbox pro which has that option. Once in the build prop up editor you'll see the option to recalibrate the proximity sensor. You'll need root access.
Sent from the Rabbit Hole
bushako said:
To calibrate the proximity sensor you need to edit the build.prop, file. Quickest way I do this is by using Romtoolbox pro which has that option. Once in the build prop up editor you'll see the option to recalibrate the proximity sensor. You'll need root access.
Sent from the Rabbit Hole
Click to expand...
Click to collapse
Where exactly in the build.prop is this setting. I access it using root explorer and scanned through the entire file and saw nothing that would hint at the proximity sensor calibration.
rumy said:
Where exactly in the build.prop is this setting. I access it using root explorer and scanned through the entire file and saw nothing that would hint at the proximity sensor calibration.
Click to expand...
Click to collapse
Sent from the Rabbit Hole
bushako said:
Sent from the Rabbit Hole
Click to expand...
Click to collapse
I don't have that in my build.prop I am running ARHD9.0
What exactly does that do. Does it just delay the screen from going of when on your face? In that case I have already disabled the proximity sensor during calls.
I am starting to wonder if this is a hardware fault.
Can you try this? If you use and it does not work once removing it will restore your factory values.
http://db.tt/C7PJnQgt
Sent from my GT-N7100 using xda premium
It looks like the proximity threshold is set too low in the kernel and causes this to misbehave when the sensor gets a little dirty.
For example: If you open the diagnostic menu by dialing *#0*# and look under sensors if your ADC value for the sensor is anything over 12, the proximity sensor will register that something is close to the phone. That value can be temporarily adjusted by setting prox_thresh under /sys/devices/virtual/sensors/proximity_sensor to something higher (like 30).
Unfortunately, it looks like changing this value doesn't "stick" and the next time the sensor is accessed, something changes it back to the default of 12.
I'm guessing that the default value is set in the kernel at compile time. Maybe someone can talk of the kernel devs into tweaking the value.
anyone found a solution to this yet?
Hi, is rooting the phone the only way to get this working? So annoying... Maybe will just send this galaxy note 2 back for a refund, tried for a long time to get this fixed, I think it started after the last android update I thought they'd have done something about it by now...
On Samsung devices like i9100 (Galaxy S3) or N7100 (Note II) you can do the following if you have root permissions:
On Android Terminal App or adb shell do:
Code:
$ su
$ echo 0 > /sys/class/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/class/sensors/proximity_sensor/prox_cal
The zero resets the actual calibration offset.
The one does an auto calibration (read sensor value, set offset to this sensor value, write calibration offset to "/efs/prox_cal" which is read while device is booting).
Best for calibrate your sensor is to keep it dark, the glass have to be clean and the sensor free (so that the sensor doesn't measure anything).
The calibration offset is stored in efs, thats why you can make full wipe and use other ROMs without the need of recalibration.
You can check the running config by:
Code:
$ cat /sys/class/sensors/proximity_sensor/state
The first value is the calibration Offset, the second one is the sensor threshold (threshold is set at compile time).
Open *#0*# to see "sensors" and check if your proximity sensor is now working properly.
Because in Kernel code (copyright by Samsung) for the device driver is somthing like this autocalibration, i bet that there is a secret menue or code that does the calibration too. But until someone discovers this secret we have to have root permissions to do a proximity sensor calibration.
greaty said:
On Samsung devices like i9100 (Galaxy S3) or N7100 (Note II) you can do the following if you have root permissions:
On Android Terminal App or adb shell do:
Code:
$ su
$ echo 0 > /sys/class/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/class/sensors/proximity_sensor/prox_cal
The zero resets the actual calibration offset.
The one does an auto calibration (read sensor value, set offset to this sensor value, write calibration offset to "/efs/prox_cal" which is read while device is booting).
Best for calibrate your sensor is to keep it dark, the glass have to be clean and the sensor free (so that the sensor doesn't measure anything).
The calibration offset is stored in efs, thats why you can make full wipe and use other ROMs without the need of recalibration.
You can check the running config by:
Code:
$ cat /sys/class/sensors/proximity_sensor/state
The first value is the calibration Offset, the second one is the sensor threshold (threshold is set at compile time).
Open *#0*# to see "sensors" and check if your proximity sensor is now working properly.
Because in Kernel code (copyright by Samsung) for the device driver is somthing like this autocalibration, i bet that there is a secret menue or code that does the calibration too. But until someone discovers this secret we have to have root permissions to do a proximity sensor calibration.
Click to expand...
Click to collapse
Hey, I've been looking for a fix for prox sensor on my Note 2 ever since I installed Paranoid back in december/january, went back to stock and it was still broken. This fixed it!! So thank you I have just one issue, it seems to go back to being broken when I reboot the phone. Is there any way to prevent this? Also the *#0*# doesn't work for me and the cat command returns just a 0. Thanks.
EDIT: it might help to note that I'm running cyanogenmod 10.1 nightly now
EDIT2: I figured it out! I did a search for prox_cal and found one in /sys/devices/virtual/sensors/proximity_sensor with the values 18,9. i put those values in the empty /efs/prox_cal. It now works on boot.
marcmy said:
... it seems to go back to being broken when I reboot the phone. Is there any way to prevent this? Also the *#0*# doesn't work for me and the cat command returns just a 0. Thanks.
EDIT: it might help to note that I'm running cyanogenmod 10.1 nightly now
EDIT2: I figured it out! I did a search for prox_cal and found one in /sys/devices/virtual/sensors/proximity_sensor with the values 18,9. i put those values in the empty /efs/prox_cal. It now works on boot.
Click to expand...
Click to collapse
I described the sensor recalibration on Samsung rom or Samsung based roms. " *#0*# "is a "secret code" that starts a samsung test tool - only included in stock or stock rom based.
I have read from other users that "cat state" returns zero. I don't know exactly why. But it could be because:
1. that the sensor is powered down (on my phone the sensor never sleeps)
2. the calibration offset is too high
3. the calibration offset is optimal
To test the sensor is on and working you should read the value with finger put on. (there should be value around 127-calibration offset). I guess to do the calibration/sensor reading with display on and phone unlocked. Another user told me that it helped to start an app which reads the sensor values (so the sensor wake up).
But in your case proximity_sensor with the values 18,9 means that the sensor is already calibrated to 18 which can cause a zero at "cat state".
Note that the offset is read from file calibration file at boot time and from that on holded in ram. The RAM value can only be influenced by "/sys/class/sensors/proximity_sensor/prox_cal" or by calibration file (on boot). The auto calibration process not only try to create a /efs/prox_cal file but also changes the calibration value in ram at run time .
So if you try "echo 0 > /sys/class/sensors/proximity_sensor/prox_cal; echo 1 > /sys/class/sensors/proximity_sensor/prox_cal" -> "mmh auto calibration does not work there is no prox_cal file, i will try it manually" can be the wrong way because the calibration offset can be already changed to a calibrated value and so you wont get the correct blank value read out "state".
The other path in virtual filesystem to the sensor control you mentioned is also correct. I don't know which is the most common one.
But since both pathes are available in samsung stock i guess it should be " /sys/devices/virtual/sensors/proximity_sensor".
Be careful of putting in the calibration value manually. In Samsung stock rom the kernel which is reading the calibration value at boot time don't make a character conversion. So if you write the config file like this:
Code:
echo '18,9' > /efs/prox_cal
Ends Up with Calibration value of 49 because the kernel will read the first byte of file. This is a "1" which is the ASCII code for "0x31" which is 49 in decimal. That should work too but throw away half of the sensor sensivity.
If you would like to calibrate it manually you have to:
Code:
cd /sys/devices/virtual/sensors/proximity_sensor/
Read the blank value ( glass have to be clean and fingers away from sensor ).
Code:
$ cat state #finger on the sensor to test if the sensor is working properly
120
$ cat state #blank value
10
Read the actual configuration:
Code:
$ cat prox_cal
0,9
The first value is the "sensor offset" and the second one is "Cancelation Threshold" (threshold can not stored in calibration file)
So you calculate your calibration value: 0 (actual sensor offset) + 10 (blank value) = 10 (new offset) = 0x0a HEX. Make shure your efs partition is mounted writeable and then:
Code:
$ su
$ echo -en $'\x[B]0a[/B]' > /efs/prox_cal
$ sync
If the prox_cal is created first you should change the permisssions. Kernel sets 666 by default :
Code:
$ chown system:system /efs/prox_cal
$ chmod 644 /efs/prox_cal
$ sync
After reboot you can confirm the calibration
Code:
$ cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal
10,9
$ cat /sys/devices/virtual/sensors/proximity_sensor/state
0
If you have to calibrate to a lower sensor value and want to do it the "manual way" you have to reset the calibration or delete the calibration file and reboot. because state value = sensor value - offset . And if offset gets to big the state is alway zero.
greaty said:
On Android Terminal App or adb shell do:
Code:
$ su
$ echo 0 > /sys/class/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/class/sensors/proximity_sensor/prox_cal
The zero resets the actual calibration offset.
The one does an auto calibration (read sensor value, set offset to this sensor value, write calibration offset to "/efs/prox_cal" which is read while device is booting).
Click to expand...
Click to collapse
working great on my i9505 thanks !!!!
Hello, so I had a very similar experience in flashing Paranoid and then my sensor went bezerk. It seems to be just not turning on with the phone, but the front camera does work fine. I was able to get it working a few days ago by flashing the stock rom and kernel multiple times, but I decided to get bold and reflash the Neak kernel and poof, that was over. Not another few flashes would bring my sensor back. At this point I don't even know what to do.
Thought it might also be worthwhile to mention: the light sensor also does not work and when I looked through the files in the sys/class/sensors for both proximity and light sensors the runtime status is unsupported.
A full Odin restore should reset all these values and the whole thing should work right immediately as long as the sensor hardware hasn't gone bad, right?
Easy FIX!!!!!
I took a can of compressed air and blew it through the top earpiece grill a few times and Voila, it works great now!!
I actually used a Old perfume can which perfume was over and it was only pressing Gas OFF!! :good::good::good::good:
Finally Fixed My Sensor
greaty said:
I described the sensor recalibration on Samsung rom or Samsung based roms. " *#0*# "is a "secret code" that starts a samsung test tool - only included in stock or stock rom based.
I have read from other users that "cat state" returns zero. I don't know exactly why. But it could be because:
1. that the sensor is powered down (on my phone the sensor never sleeps)
2. the calibration offset is too high
3. the calibration offset is optimal
To test the sensor is on and working you should read the value with finger put on. (there should be value around 127-calibration offset). I guess to do the calibration/sensor reading with display on and phone unlocked. Another user told me that it helped to start an app which reads the sensor values (so the sensor wake up).
But in your case proximity_sensor with the values 18,9 means that the sensor is already calibrated to 18 which can cause a zero at "cat state".
Note that the offset is read from file calibration file at boot time and from that on holded in ram. The RAM value can only be influenced by "/sys/class/sensors/proximity_sensor/prox_cal" or by calibration file (on boot). The auto calibration process not only try to create a /efs/prox_cal file but also changes the calibration value in ram at run time .
So if you try "echo 0 > /sys/class/sensors/proximity_sensor/prox_cal; echo 1 > /sys/class/sensors/proximity_sensor/prox_cal" -> "mmh auto calibration does not work there is no prox_cal file, i will try it manually" can be the wrong way because the calibration offset can be already changed to a calibrated value and so you wont get the correct blank value read out "state".
The other path in virtual filesystem to the sensor control you mentioned is also correct. I don't know which is the most common one.
But since both pathes are available in samsung stock i guess it should be " /sys/devices/virtual/sensors/proximity_sensor".
Be careful of putting in the calibration value manually. In Samsung stock rom the kernel which is reading the calibration value at boot time don't make a character conversion. So if you write the config file like this:
Code:
echo '18,9' > /efs/prox_cal
Ends Up with Calibration value of 49 because the kernel will read the first byte of file. This is a "1" which is the ASCII code for "0x31" which is 49 in decimal. That should work too but throw away half of the sensor sensivity.
If you would like to calibrate it manually you have to:
Code:
cd /sys/devices/virtual/sensors/proximity_sensor/
Read the blank value ( glass have to be clean and fingers away from sensor ).
Code:
$ cat state #finger on the sensor to test if the sensor is working properly
120
$ cat state #blank value
10
Read the actual configuration:
Code:
$ cat prox_cal
0,9
The first value is the "sensor offset" and the second one is "Cancelation Threshold" (threshold can not stored in calibration file)
So you calculate your calibration value: 0 (actual sensor offset) + 10 (blank value) = 10 (new offset) = 0x0a HEX. Make shure your efs partition is mounted writeable and then:
Code:
$ su
$ echo -en $'\x[B]0a[/B]' > /efs/prox_cal
$ sync
If the prox_cal is created first you should change the permisssions. Kernel sets 666 by default :
Code:
$ chown system:system /efs/prox_cal
$ chmod 644 /efs/prox_cal
$ sync
After reboot you can confirm the calibration
Code:
$ cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal
10,9
$ cat /sys/devices/virtual/sensors/proximity_sensor/state
0
If you have to calibrate to a lower sensor value and want to do it the "manual way" you have to reset the calibration or delete the calibration file and reboot. because state value = sensor value - offset . And if offset gets to big the state is alway zero.
Click to expand...
Click to collapse
Finally, this fixed my problem. I don't know why, but the other solution worked one time while using a CM 10.2 nightly
Code:
$ su
$ echo 0 > /sys/devices/virtual/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/devices/virtual/sensors/proximity_sensor/prox_cal
But, when I upgraded to the latest nightly, this stopped working. It wouldn't work even if y restored my stock ROM backup using TWRP, I even flashed a stock image with odin and the sensor would still malfunction.
Today I followed this steps using the values returned for my phone and it finally worked! I did this.
Code:
$ cat state #finger on the sensor to test if the sensor is working properly
120
$ cat state #blank value
10
This returned 255 #finger on the sensor and 69 #blank value
and when I did
Code:
cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal
this returned 47,60,45.....so my offset was 47. Ths sum of offset and #blank value was 47 + 69 = 116 that is equal to 74 in HEX.
so I did
Code:
$ echo -en $'\x74' > /efs/prox_cal
and then
Code:
$ chown system:system /efs/prox_cal
$ chmod 644 /efs/prox_cal
$ sync
After that I rebooted my phone from the terminal using que command
Code:
$ reboot
and that was it! Now my sensor is fixed and survives reboot. Thanks!
Debian “Chatter” Phone
Screenshot: http://www.mediafire.com/view/ljgv724r57tnx5y/2015-11-03-104935_480x800_scrot.png
Debian. Not run as a tack on, not emulated, not on top of Android, but standalone. That's my goal. That's what I've been working on. Turning an old Glide into a computer. After some careful thought, I figured some other people might be interested in that too, so I thought I'd post it here. Perhaps we can even work together to get it finished.
Why Debian “Chatter”? Well, all Debian versions are given a name from a toy in the Pixar film Toy Story. Chatter happens to be the toy telephone in Toy Story 3. I put Chatter in quotes because it actually is not an official release. Technically, at least at the moment, I am using Debian Jessie. Since becoming a release of Debian would be nearly impossible to spearhead from the ground level, it would most likely become an offshoot of Debian.
What I have done so far is utilize the internal “sdcard” partition as the root file system for Debian Jessie.
What's working:
- Standard Linux functions (mostly)
- Boot up to the X server (XFCE window manager currently)
- Screen, orientation and display
- Physical keyboard (Only the qwerty part)
- Touch-screen as a touch pad to move the mouse pointer
- Battery indication including if it is charging or not
- Audio with ALSA.
- Volume buttons
- Front soft keys
Flashing instructions if your Captivate Glide already has TWRP.
http://www.mediafire.com/download/z9fzrw68rio8sq9/recoveryTWRP.img
1. Download my TWRP backup, and put under the /TWRP/BACKUPS/<SERIALNUMBER>/ folder.
https://www.mediafire.com/folder/9vifxpouh9voc/2015-10-20
2. Restore the image through the Restore function in TWRP.
3. Download my tar.gz file to your computer and extract it.
http://www.mediafire.com/download/716x1oxcglythhk/20151102.tar.gz
Or,
http://www.mediafire.com/download/88r6sr3u33bs532/20151106.tar.gz
4. Put your phone into the TWRP recovery, and choose the Mount option and select “sdcard”
5. Place the extracted contents of the dated folder onto the sdcard partition, but not the dated folder itself, just what is in it.
6. Reboot your phone into the ODIN download mode.
7. Download my 2ndboot.img file and i927.pit file.
http://www.mediafire.com/download/mudjm3j3304vt77/2nboot.img
http://www.mediafire.com/download/793j89i277rggpa/i927.pit
8. Using Heimdall-frontend, select the pit file, and flash the LNX partition with the 2ndboot.img file.
9. Reboot and Linux on!
Flashing instructions if your Captivate Glide already has Clockworkmod.
http://www.mediafire.com/download/f64i073d65e0ug1/recoverycwm.img
1. Download my copy of Bio360Rom.zip and move it to your phones sdcard.
http://www.mediafire.com/download/1u2v6aac19fzh97/Bio360ROM.zip
2. Reboot into recovery mode (Clockworkmod) and install the Bio360Rom.zip
3. Reboot your phone into the ODIN download mode.
4. Download my 2ndboot.img file, my recovery.img file, and i927.pit file.
http://www.mediafire.com/download/mudjm3j3304vt77/2nboot.img
http://www.mediafire.com/download/z9fzrw68rio8sq9/recoveryTWRP.img
http://www.mediafire.com/download/793j89i277rggpa/i927.pit
5. Using Heimdall-frontend, select the pit file, and flash the LNX partition with the 2ndboot.img file.
6. Again using Heimdall-frontend, select the pit file, and flash the SOS partition with the recovery.img file.
7. Put your phone into the TWRP recovery, and choose the Mount option and select “sdcard”
8. Download my tar.gz file to your computer and extract it. Place the extracted contents of the dated folder onto the sdcard partition, but not the dated folder itself, just what is in it.
http://www.mediafire.com/download/716x1oxcglythhk/20151102.tar.gz
Or,
http://www.mediafire.com/download/88r6sr3u33bs532/20151106.tar.gz
9. Reboot and Linux on!
Optional instructions:
If you want to, head over to the Debian Jessie download page and download the arm version of the DVD's 1 and/or 2. In the following posts I describe how you can rip these cd's to set up a personal repository, one that you can strictly control all of the packages, which may be useful at this time.
Changelog:
Code:
Changelog - Debian "Chatter" using Canium Kernel
20151106
- Added shutdown.sh and reboot.sh to launcher for *better* handling of shutdown.
20151102
- Mapped soft keys: search - xfce-appfinder
- Mapped soft keys: back - xfce-next workspace
- Mapped soft keys: home - xfce showdesktop
- Mapped soft keys: menu - xfce-showmenu
- Mapped volume up/down to amixer Master +/- 5db.
- Added "event2" to xorg.conf. Volume buttons and power button are recognized and can now be mapped to an action.
- Added "event7" to xorg.conf. front soft keys are recognized and can now be mapped to an action.
- Enabled xfce splash screen (like a boot animation.) Also enabled text update of status during start of xfce.
20151101
- Edited xfce panel and options for display of information.
20151020-2
- Moved entire system off of sdcard and onto mmcblk0p4, the "internal sdcard" of the phone.
20151020
- Due to errors with Pulseaudio, removed pavucontrol/pulseaudio. Installed all Alsa controls.
- Installed LXMusic/xmms2 for mp3 player.
- Mixer and alsa mixer can properly set volume to path SPK_HP (the speaker or headphone) and adjust the volume. However, it will mute after a few moments of inactivity. A work in progress.
20151019 Continuing the current fork of Cranium Kernel.
- Udevd is not working due to lack of devtmpfs support in kernel. Added mdev support for hotplug items by editing init.stage2 with:
/sbin/busybox echo /sbin/busybox mdev > /proc/sys/kernel/hotplug
20151018
- Backed up entire system, forking to other kernels. This backup will remain with all that is done so far. The fork has a seperate changelog.
20151016
- Enabled usb0 as a network interface in /etc/network/interfaces, can start with ~# ifup usb0.
-On receiving computer, ensure that you insmod "mii.ko" and "usbnet.ko" if not already built into your kernel. -cannot figure out how to attach to it!
^-- I now realize that I would need to recompile my desktop computer kernel to support this endevour. This would distract from the process at hand. Scrapped.
- Added second armhf dvd from Debian Jessie to my local repository, and edited /etc/apt/sources to match.
20151015
- Edited xbattbar.sh script to accurately reflect if the phone is plugged in or not. - Put into 20151014 folder.
20151014
- Needed battery indicator. Added xbattbar as it is the only battery indicator with user scriptable inputs.
- Wrote script for xbattbar to work, now accurately reflects battery capacity.
- Put xbattbar in .xsession and removed xclock from .xsession
20151013
- Added XFCE4 and set as default for root in /root/.xsession file with xclock on startup for fun.
20151010
- Added local repository under folder /repo/all
- Used dpkg-scan to create Packages.gz
- Added local repository to /etc/apt/sources.list
20151008
- Added Keyboard to xorg.conf, some keys work, some do not.
20151005
- Added touchscreen to xorg.conf as "corepointer", works to move mouse.
20150924
- Created new initramfs.cpio.gz
- Created new_boot.img
- Copied another init script and init.stage2 script onto sdcard and edited for my purposes.
- Originally booted to Linux, then started Android, and Android was what you saw.
- Edited init and init.stage2 script so that it now boots Linux, and you see Linux. Android is running in chroot env. but cannot start fully due to /dev/graphics/fb0 is in use.
20150921
- Started with debootstrap base image of Debian Jessie
- Added openssh, vnc, lxde, jwm, and some other programs through emulator.
- Broke down Biorom kernel and initramfs. Using Cranium Kernel.
As for me, I plan to keep working on this project, if you are interested in working on this project as well, please feel free to work on it! You can work independently or with me on this if you would like. You are welcome to post here, or to contact me through XDA's message service. Please see the next posts on what still needs to be done (which is a lot).
The current passwords are:
root = root
trondroid = trondroid
me = me
Enjoy!
Thanks to these people for their time and knowledge!
As with any project, it starts somewhere, and I want to thank the following individuals for their prior work that I used as the basis of this project. These individuals may not know that their tools were used here, but I would like to thank them for posting their knowledge and or files or programs for people like me to be able to read and use:
XDA developer bubor – Seriously, this person has a lot of great material on this site. I borrowed their TWRP recovery.img.
XDA developer mdubb2341 - I used this person's Bio360Rom as the chrooted Android environment, due to it's small size and resource requirements (e.g. no zRam).
Mikael Q Kuisma - http://whiteboard.ping.se/Android/Debian – This guy helped tremendously with the breakdown of the boot.img and hijacking init to do what I want instead. He explains how to start Linux then Android, and use your Android phone with Linux underneath.
Eryk Wdowiak - http://www.wdowiak.me/anX11phone/ - This gentleman had some great material on starting Linux after starting Android and running Linux on top of Android.
Ivan Davidov - http://minimal.linux-bg.org/ - The tutorials on setting up minimalistic Linux environments and boot script examples were priceless.
To do list
Phone specific things to do: (Wow this is a big list!)
GPS – I have put FoxtrotGPS and gpsd in the image. I know that /dev/ttyHS0 is the GPS output, but it appears that the GPS is of course off, because it has not been started yet. I either need to echo the appropriate digits into the /sys files, or tell the chrooted Android to turn it on. I also found that it relies on gpsd, and uses standard output to it, which is a huge plus for a Linux phone.
Phone calls/text messaging/radio control – I have not even started on that. My goal was to run a chrooted Android environment and “tell it” from Debian to make a phone call or send and receive messages.
Bluetooth – The module for the bluetooth is already loaded, and I have put the bluez and other bluetooth tools on the phone, I just cannot figure out how to connect to it. It may be powered off also.
Wifi – The modules for this are in the /android/lib/modules directory, but once I insmod them, it does not appear as a connection. I believe that I need to do some sort of mknod to create a node or socket to connect to it, or have the chrooted Android turn it on.
Camera – I have not even looked at this yet.
Accelerometer/compass - I have not even looked at this yet.
Slide switch – I am hoping to use xranr and event input to rotate the screen and change the resolution if you slide out the keyboard.
Code:
Available devices:
/dev/input/event0: STMPE_keypad – The physical keyboard.
/dev/input/event1: mpu-accel
/dev/input/event2: sec_key – Physical keys – Volume +/- and power.
/dev/input/event3: sec_touchscreen – The touchscreen input.
/dev/input/event4: proximity_sensor – Sensor that turns off the screen when your face is against it.
/dev/input/event5: light_sensor – Ambient light sensor to control screen brightness and keyboard lights.
/dev/input/event6: HALL – Opening the slide out keyboard.
/dev/input/event7: sec_touchkey – front face soft keys - home, back, search, menu.
/dev/input/event8: compass_sensor
Linux specific things to do: (Wow, this is also a big list!)
lspci – lspci does not work, which hampers the ability to figure out control of some of the devices. This is a problem (I think) with the kernel / arm hardware and the way the arm ARCH is set up. It uses AMBA.
lsusb - Fixed!
- I also got an OTG cable and can plug stuff in and see it show up with lsusb!
Audio – Pulse audio fails, so I replaced it with alsa. While alsa does work, it has the uniqe problem of turning off the path to device when there is no sound playing. Currently, if you want to listen to music, you open a music player, start the music, open the alsa volume mixer, set the path to SPK_HP, and adjust the volume as desired. Once the song or play list is done, pressing play again will yield no sound until you go to the volume mixer and choose SPK_HP again.
Init – Systemd is the standard init for Debian Jessie, but it causes too many problems on the phone. It either needs to be redone, or replaced. Currently, I am using the rc.local script to start some selected services, as a userspace init, so to speak.
Dbus – dbus can be started after you enter the X window environment, e.g. after the chrooted Android is done starting. I don't know that it is working properly.
Graphics – Currently Debian is just drawing straight to the frame buffer, it would be nice to get the nVidia drivers working for 3d acceleration.
Chrooted Android specific problems: (Not as big of a list.)
ADB – Fixed, ADB now works to connect to the chrooted Android from your computer using ADB as usual.
AM – The activity manager cannot start because we have stolen /dev/graphics/fb0 for the Debian x-server, so you cannot access the AM. If the AM can get up and running, then it would be possible to script orders to it, such as make phone calls, start wifi, etc.
SurfaceFlinger - SF is waiting for the /dev/graphics/fb0 to become available. It would be beneficial to have it "start" without it, perhaps to a virtual frame buffer, which requires a new kernel, or user-space tools like xvfb.
If you have any ideas or thoughts on how to do these things, or if you would like to tackle one of these projects, please let me know! I'd be happy to post your work and let everyone know that you came up with the solution!
Optional Instructions
Optional instructions:
If you want to, head over to the Debian Jessie download page and download the arm version of the DVD's 1 and/or 2. In this post I describe how you can rip these cd's to set up a personal repository, one that you can strictly control all of the packages, which may be useful at this time.
Here are the links for the DVD's:
http://cdimage.debian.org/debian-cd/8.2.0/armhf/iso-dvd/debian-8.2.0-armhf-DVD-1.iso
http://cdimage.debian.org/debian-cd/8.2.0/armhf/iso-dvd/debian-update-8.2.0-armhf-DVD-1.iso
Then, on your computer:
Code:
~$ cd {to your download directory}
~$ mkdir disk1
~$ mkdir disk2
~$ sudo mount ./debian-8.2.0-armhf-DVD-1.iso ./disk1
~$ sudo mount ./debian-update-8.2.0-armhf-DVD-1.iso ./disk2
~$ mkdir repo1
~$ mkdir repo2
~$ cd disk1
~$ find . -name *deb -exec mv '{}' ../repo1/ \;
~$ cd ..
~$ cd disk2
~$ find . -name *deb -exec mv '{}' ../repo2/ \;
~$ cd ..
~$ sudo umount ./disk1
~$ sudo umount ./disk2
~$ rmdir ./disk1
~$ rmdir ./disk2
~$ cd repo1
~$ sudo dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
~$ cd ..
~$ cd repo2
~$ sudo dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
~$ cd ..
Now you can copy those files to your external sdcard, mount it and add these custom repositories to your /etc/apt/sources.list.
Enjoy!
Really great to see that! Please continue working on this I like the idea maybe I participate instead of trying to port ubuntu touch...
In the meanwhile keep up your work and thanks for sharing!
-----
Sent from my SGH-I927 using XDA Android mobile app
Thanks!
xdajog said:
Really great to see that! Please continue working on this I like the idea maybe I participate instead of trying to port ubuntu touch...
In the meanwhile keep up your work and thanks for sharing!
-----
Sent from my SGH-I927 using XDA Android mobile app
Click to expand...
Click to collapse
Thanks xdajog!
I also tried to port Ubuntu Touch, but the recovery drive is too big for the standard size. I broke down the recovery image and tried to shrink it, I could make it smaller, but I could not get it small enough. Then I attempted to change the pit and re-partition, but ended up having to recover the phone. That is when I started working on this project.
I appreciate the encouragement, and I will be posting more soon! I hope
20151102 update.
Just a quick post on the updates. The first post has been updated with new links to the new files, and the change log gives the basics. Here is a little more detail:
Essentially I was able to add support for the /dev/input/event7 (soft keys) and /dev/input/event2 (the physical buttons).
Now the front soft keys work:
Menu - essentially the right click menu of whatever the mouse pointer is on.
Home - clears the desktop, pressing this again will reveal all of your windows again.
Back - I used this as the switch between desktops.
Search - This now brings up the xfce app finder.
The volume keys now are bound with "amixer set Master 5dB+" or "amixer set Master 5dB-" to adjust the volume.
20151106 update.
Just a few things added in this update:
Created new shutdown.sh and reboot.sh scripts and linked them to a launcher menu on the panel. It was needed to make sure the system is properly shut down, including the chrooted android system.
Also purged and re-installed lsusb, and now it works. After plugging anything into the OTG cable, they will show up on lsusb and things like a mouse are added as /dev/input/event8.
Several failed attempts, but much was learned about the GPS, particularly the use of gpsd. I can now link gpsd to the GPS, however I still need to turn power for the GPS on. However, the Activity Manager for Android is not up and running because Surface Flinger fails to start due to /dev/graphics/fb0 or fb1 being in use by the X server for Debian.
20151109 update.
One of the principle problems with the phone setup was the lack of udev support, which is very important in Debian Jessie.
The problem with udev was the lack of "devtmpfs" file system support in the kernels for the Samsung i927.
So after *many* painful attempts, I was able to load a computer with Ubuntu 12.04, download all of the source code, and compile a custom kernel for the i927. This kernel includes devtmpfs and a few other Linux related things.
The output of uname -a:
Code:
Linux localhost 3.1.10 #2 SMP PREEMPT Mon Nov 9 11:25:41 AKST 2015 armv7l GNU/Linux
And after remaking a boot image, I flashed it to the phone, and to my surprise, this time it worked! Perhaps tomorrow I can update the top post with the new boot image.
It caught me by surprise also because it re-arranged the order of /dev/input/event#'s moving the touchscreen to 1, where before it was 2, but that was easily overcome by editing /etc/X11/xorg.conf.
I do not know that my new kernel is "better" overall, but it is more "useful" as it includes the devtmpfs support needed to continue with this project.
New Kernel.
Still having trouble fine tuning the kernel to be just right, which is why I have not updated the top post with this information yet, but for those interested, here it is.
The new kernel:
http://www.mediafire.com/download/orkbt7kcx16z0or/20151110ALUboot.img
Flash the boot.img with Odin to the LNX partition.
Edit the xorg.conf file /etc/X11/xorg.conf with the following. The reason for this is that the new kernel has a different order of "events" for device inputs.
Code:
Section "ServerLayout"
Identifier "Layout0"
Screen "Screen0"
InputDevice "touchscreen" "CorePointer"
InputDevice "keyboard"
InputDevice "mediakeys"
InputDevice "frontkeys"
EndSection
Section "Monitor"
Identifier "Monitor0"
ModelName "Monitor Model"
DisplaySize 800 480
EndSection
Section "InputDevice"
Identifier "touchscreen"
Driver "evdrv"
Option "Device" "/dev/input/event2"
Driver "multitouch"
EndSection
Section "InputDevice"
Identifier "keyboard"
Driver "evdev"
Option "Device" "/dev/input/event0"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "keyboard"
Driver "evdev"
Option "Device" "/dev/input/event8"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "mediakeys"
Driver "evdev"
Option "Device" "/dev/input/event3"
EndSection
Section "InputDevice"
Identifier "frontkeys"
Driver "evdev"
Option "Device" "/dev/input/event7"
EndSection
Section "Device"
Identifier "Card0"
Driver "fbdev"
Option "fbdev" "/dev/graphics/fb0"
Option "Rotate" "left"
Option "VertRefresh" "60"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
DefaultDepth 16
SubSection "Display"
Depth 16
EndSubSection
EndSection
Otherwise, your touchscreen will not function.
Phone is broken.
Unfortunately, my spare Captivate Glide finally bit the dust. :crying:
Regardless of what rom/software I put on it, it cannot sustain itself for more than a minute or so before it simply stops working. The screen turns grainy, gets lines through it, and then it reboots itself. Perhaps if I get another phone or motherboard I can continue working on this further.
AlaskaLinuxUser said:
Unfortunately, my spare Captivate Glide finally bit the dust. :crying:
Regardless of what rom/software I put on it, it cannot sustain itself for more than a minute or so before it simply stops working. The screen turns grainy, gets lines through it, and then it reboots itself. Perhaps if I get another phone or motherboard I can continue working on this further.
Click to expand...
Click to collapse
bad news. Nevertheless thanks for all your work!
The problem you describing may because of the power button. There is a known issue which is also with my dev phone (and others out there). Whenever I press it after the phone booted up it will crash the same way then yours. To be able to develop I avoid using the power button to do so I use the highest display timeout value and if I need to wake up the phone I use an adb command to do so.
.
tim241 said:
Any idea how to port this to an other device?
Click to expand...
Click to collapse
Tim241, sorry, I didn't watch this forum anymore, but I will be glad too if you want to ask questions.
Yes, I can tell you how to port this to another device, but I cannot guarantee success. What device do you wish to port it too?
Also, everything I did I wrote in my blog, which is in my signature. I will gladly answer questions here or there.
-AlaskaLinuxUser https://thealaskalinuxuser.wordpress.com/
tim241 said:
my device is the Samsung Galaxy Core 2 SM-G355HN
Click to expand...
Click to collapse
Okay, so the next thing we need are some ROMs to break down the boot image from. What ROMs are available for your phone?
Older is better, stock or custom is okay.
Preferably Android 2.3.* is best because it uses the least amount of processing power and ram.
Android 4.4+ will not work as well, as you will not be able to " hold " onto the screen. It is okay that it is older Android, since you will not actually see the Android part, you are just using it to initialize firmware, etc.
What we will do, as I can explain in more detail as we go along, is break down the boot image and make our own init script that will start Debian Linux. Then Debian will be the boss. Debian will start Android, but Debian will control the screen and inputs.
-AlaskaLinuxUser https://thealaskalinuxuser.wordpress.com/
tim241 said:
we only have cyanogenmod 11 :-/ here http://forum.xda-developers.com/gal...cyanogenmod-11-samsung-galaxy-core-2-t3308697
Click to expand...
Click to collapse
Bummer. So, we can still proceed, but we may have screen trouble with 4.4. Do you want to continue?
-AlaskaLinuxUser https://thealaskalinuxuser.wordpress.com
Great attitude! Let's try!
tim241 said:
We can try
Click to expand...
Click to collapse
Okay, so first things first, STEP 1: downloads!
Download these things:
http://www.mediafire.com/download/zl80gh0t310trla/unpack-bootimg.pl
http://www.mediafire.com/download/xdmd278n17gm58h/unmkbootimg
http://www.mediafire.com/download/byf0tw4ga2mqtw0/repack-bootimg.pl
http://www.mediafire.com/download/7cmi548pzetc6c4/mkbootimg
And download CM11, if you have not already.
I am using Linux, Ubuntu 14.04. I did this previously from Debian Wheezy, so any Linux should work. You can also use a VM, virtualbox, etc. if you are on a Windows computer.
STEP 2: Unzip!
Go ahead and unzip the CM11 that you downloaded. Preferably in its very own folder. For my work, I made a folder called "playground" in my home directory to play around in. I will reference the "playground" meaning the main folder with everything in it. Now, in the playground, make a new folder called "bootimage". In the playground folder, copy the boot.img file to the bootimage folder.
STEP 3: Tools setup!
Copy the downloaded above tools into a new folder called "tools" in the playground folder. Open a terminal here and give these files executable permissions and copy them again to the bootimage folder:
Code:
$ cd ~/playground/tools
$ chmod 777 ./*
$ cp ./ ../bootimage
We copy this twice so we have backups of the tools in case we delete them accidentally.
STEP 4: Unpack the boot image!
Open a terminal and go to the bootimage folder, and start typing:
Code:
$ cd ~/playground/bootimage
$ ./unmkbootimg ./bootimage
You will see some output in the terminal that looks *kind of* like this:
Code:
$ ./unmkbootimg ./boot.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
Kernel size 2992704
Kernel address 0x10008000
Ramdisk size 2196028
Ramdisk address 0x11000000
Secondary size 0
Secondary address 0x10f00000
Kernel tags address 0x10000100
Flash page size 2048
Board name is ""
Command line ""
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz -o new_boot.img
---------------
Whatever it says, copy and paste it, hand type it, screenshot, whatever it takes, write the output down, because this is the key to re-making your boot image! I recommend that you post the output here on XDA so we can look at it together.
Then, unpack it like so:
Code:
$ ./unpack-bootimg.pl ./boot.img
You should see something *like* this:
Code:
$ ./unpack-bootimg.pl ./boot.img
kernel written to ./boot.img-kernel.gz
ramdisk written to ./boot.img-ramdisk.cpio.gz
7607 blocks
extracted ramdisk contents to directory ./boot.img-ramdisk/
You will now have folders and files to play with. After you report back the outcome of this, we will make our init script and continue on.
Good luck! I will wait for your reply!
tim241 said:
Also I need to warn you about the disk space from the device(galaxy core 2 SM-G355HN):
http://www.gsmarena.com/samsung_galaxy_core_ii-6331.php.
Click to expand...
Click to collapse
Great! Good work.
Now for today's steps:
#1. Download:
Debian system (WARNING - this is almost 700 mb!)
http://www.mediafire.com/download/88r6sr3u33bs532/20151106.tar.gz
Very tiny busybox (1.06 mb)
http://www.mediafire.com/download/4uhu93prdtlqdmr/busybox
NOTE: These files will get you started. Later, you can build your own busybox and Linux root file system if you want, these worked for me, so I think it is best to start by using a known working source.
#2. Partition sdcard:
I use a computer to do this, but there are many phone tools available also. You can later transfer all of this internally, and do this without an sdcard, but this is the best way to get started, as you learn, you can move it all to the phone.
So, my computer has an sdcard slot, you may use an adapter, or use your phone, it really doesn't matter. The sizes here are a suggestion, but you will need 2 partitions on the card. I am using an 8 GB card as my example.
Partition Type Size Notes
1 fat32/vfat 2 GB (or more if your card is bigger)
2 ext4 6 GB (or the remainder)
Now, the first partition will be "seen" by Android. The second partition will not typically be seen by Android.
#3. Unzip the Debian system.
First, make a folder in your playgroup folder called sdcard. (~/playgroup/sdcard)
Right clicking on it will most likely work, depending on your distro, but if you use the terminal, the command unzip should do it. When you unzip the file, it may error after completing the task, that is usually okay. It is a difference in zip endings for Linux/Windows. All the 97151 files should be there, you can right click on the folder to verify. It will be in a folder called 20151106, in that folder, you will see a bunch of folders, such as android, proc, lib, etc, and so on. Copy all of those files to your ~/playgroup/sdcard folder.
Now you have a basic Debian Linux system with an XFCE desktop and a user all ready to go. We will need to change a few things that are specific to your phone though, to make this work right.
#4. Copy the original boot stuff to your sdcard folder.
In that ~/playgroup/sdcard folder, is a folder called android (~/playgroup/sdcard/android). This folder currently contains all of the ramdisk for the Cranium Kernel on an i927. You will go ahead and delete everything in the ~/playgroup/sdcard/android folder. It is useless to you.
When you broke down your boot.img file, you were given a new folder called "./boot.img-ramdisk/" this is the contents of your ramdisk for your kernel. Copy all of the files in the boot.img-ramdisk folder to the android folder. Make sure you copy, not move, you will need the other copy for modification shortly.
#5. Gather some information.
Install CM11 to your phone, if you have not already done so. Insert your sdcard. Turn on your phone. Once done, we need to get some information from it. Install a terminal app and give it root permission, or use adb shell from you computer, either way works. Now gather the following information:
Code:
$ su
# mount
.....info you need.....
Write down, copy, or screenshot all of this information.
Code:
$ su
# ls /dev
.....info you need.....
# ls /dev/input
.....info you need.....
# ls /dev/graphic <-----(or graphics depending on your phone)
.....info you need.....
Write down, copy, or screenshot all of this information. You may need some of it later.
WHY:
We will need the partition details and the framebuffer details.
Turn off your phone and remove the sdcard.
#6. Make some changes to init.stage2 file.
There should be a file called init.stage2 in the etc folder: ~/playgroup/sdcard/etc/init.stage2
Open that file with a text editor. Line 43 should say this:
Code:
export FRAMEBUFFER=/dev/graphics/fb1
Change the last part "fb1" to be the earliest fb you wrote down from step 5: "# ls /dev/graphic". So if you have an fb0, put that here. If it starts at fb1, put that here. save the file. You can close that now.
WHY:
Currently, it was set to the framebuffer I was using. We need the framebuffer (screen) for your phone.
#7. Edit your rc.local file.
Open the ~/playgroup/sdcard/etc/rc.local file.
NOTE: There is also an ~/playgroup/sdcard/etc/init.d/rc.local file, that is not the file you want.
It should say:
Code:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# Start the ssh client, in the event you need it.
/etc/init.d/hostname.sh start
/etc/init.d/ssh start
# Clean up bad crash before starting x server.
# /sbin/busybox mkdir -p /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/
# Start the x server, warning, if the touchscreen or keypad doesn't work
# then you cannot escape without killing power!
/usr/bin/startx &
#export USER=root
#vncserver :5000
exit 0
At this time, change it to say:
Code:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# Start the ssh client, in the event you need it.
/etc/init.d/hostname.sh start
/etc/init.d/ssh start
# Clean up bad crash before starting x server.
# /sbin/busybox mkdir -p /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/
# Start the x server, warning, if the touchscreen or keypad doesn't work
# then you cannot escape without killing power!
#/usr/bin/startx &
#export USER=root
#vncserver :5000
exit 0
Save the file, and you may now close that window.
WHY:
Currently, it was set to start the openssh server, then the x server. We want to only start the ssh server so we can get the proper information for the x server. We will change this file back later when we have the information.
#8. Put Debian Linux on the sdcard's second partition:
Here is where things will differ for you and me. I don't know where your card will mount, your system may auto-mount your sdcard when you put it in, but here is what you need to do:
-Mount the second partition to /mnt, or figure out where it is mounted.
Code:
$ cd ~/playgroup/sdcard/
$ sudo su
<enter your password>
# cp -Rav ./* /mnt
# sync
# exit
$ exit
WHY:
If you drag and drop, some files will not copy right. We need all files to have the proper permissions and the proper file attributes.
Now you can unmount the partitions and remove the sdcard from the computer/adapter.
#9. Prep your new boot image.
Okay, here is where rubber meets the road. Follow close, because this is really important.
The
Code:
<---
are my comments, don't type those (obviously).
Code:
$ cd ~/playgroup/bootimage/boot.img-ramdisk/ <---to get to the right place.
$ rm -rf * <---to empty out the ramdisk
$ mkdir data
$ mkdir dev
$ mkdir mnt
$ mkdir proc
$ mkdir sbin
$ mkdir sys
$ mkdir system
$ touch init
$ mkdir ./mnt/root
WHY:
This makes the empty directory that you need. Most of this will be populated when the phone starts by busybox.
Remember that busybox file you downloaded? copy it into the sbin folder. THis busybox will actually be the heart and soul of your computer/phone during startup. The Kernel will only interface with it at first.
Now open the init file with gedit or some other text editor, and fill it in with this:
Code:
#!/sbin/busybox sh
# initramfs pre-boot init script
# Mount the /proc and /sys filesystems
/sbin/busybox mount -t proc none /proc
/sbin/busybox mount -t sysfs none /sys
/sbin/busybox mount -t tmpfs none /dev
# System needs a few cycles here
/sbin/busybox sleep 1
# Populate /dev
/sbin/busybox mdev -s
# Mount the root filesystem, second partition on micro SDcard
/sbin/busybox mount -t ext4 -o noatime,nodiratime,errors=panic /dev/mmcblk1p2 /mnt/root
# Clean up
/sbin/busybox umount /proc
/sbin/busybox umount /sys
/sbin/busybox umount /dev
# Transfer root to SDcard
exec /sbin/busybox switch_root /mnt/root /etc/init
Save the file and close it. Now, this only works if your step 5: "ls /dev" has /dev/mmcblk1p1 and /dev/mmcblk1p2, and no higher /dev/mmcblk1p* numbers. There should also be a bunch of /dev/mmcblk0p* numbers, that is okay, that is your phone's internal storage. This should be correct, but if you do not have that in step 5, then let me know and we will look at your output from step 5.
Code:
$ cd ~/playgroup/bootimage
$ rm initramfs.cpio.gz
$ cd ./boot.img-ramdisk/
$ sudo su
<enter your password>
# chmod a+x ./init
# chmod a+x ./sbin/busybox
# find . | cpio --quiet -H newc -o | gzip > ../initramfs.cpio.gz
# cd ..
# mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x0 --cmdline 'console=ttyS1,115200n8 androidboot.selinux=permissive' -o new_boot.img
-With heimdall, heimdall-frontend, or Odin, flash the new_boot.img to the boot partition of your phone. Make sure you already have your prepared sdcard in your phone. If it auto rebooted, proceed to step 10. If not, power off when done, then power on and go to the next step.
#10. Reboot your phone.
So, make sure your prepared sdcard is in the phone. Your phone probably rebooted when you flashed the new boot image. For the most part, if this worked, boot up will look normal. If it did not work. It should not have booted. CM11 will start and you will have no idea that anything is different. However, if it booted, there is a difference now, there are a few easy ways to see it.
Install an ssh app on your phone from the playstore or with adb. Remember in step 7, we left the openssh server running. This is your ticket "in" to the Linux that is actually in charge of your phone.
open-ssh is installed and running, so using the ssh app, set it for: [email protected]
username is trondroid, password is trondroid
If successful, it should log into the command line of your Debian Linux powered phone! A couple things to remember:
root user has a password of root.
me has a password of me.
trondroid has a password of trondroid. trondroid also has sudo permission.
If you turn on the WiFi in CM11, and your computer is on the same network, you can run this in your computer's terminal to access the phone:
ssh [email protected] (ipaddress of phone, get from settings menu)
Debian actually is CM11's boss. Debian can delete/move/modify anything in CM11's world. BE CAREFUL! This is the ultimate root! You can even resize CM11's partitions from here. SO BE CAREFUL!
Apt-get works to download any Debian programs you want. We will get into the graphical stuff next time.
Congratulations! You made it work. Now we just have to set up the buttons, keys, xorg.config, and sound for the Debian part, which we will do next. Let me know how it went, and if you have any trouble! Play around and have fun! You are IN!
Part 3 of 3. The final instructions.
Well, I don't know what happened to Tim, but for any interested (probably not many, but for any who are) here are the final instructions.
If you are still with me, then you have already set up your phone to first boot Debian Linux, and then Linux will start Android in a chroot environment. Your phone is actually already running Debian Linux, just with Android being run and displayed on the screen. At any moment, you can actually stop or kill Android. At this point, you also have the power to mess Andriod up, so do be careful!
If you just tuned in, I recommend that you go back to the previous posts, as there is a lot of critical information you need.
Right now, you should be able SSH into your own Linux from the Android gui by using any ssh app to yourself as the local host, since our SSH deamon is running. What we want, though, is for your screen to display the Linux screen, instead of the Android that is running in a chroot environment.
A key part of all of this, is that Android, other than through services like SSH, does not know that Debian Linux exists and it does not have any control over the Linux system or functions. One problem with this is that Android may occaisionally crash due to memory problems, if your Linux environment is using too much RAM. Ironically, if you SSH into your Linux environment, you can use ps aux, or top to see all of Android's running processes. Your Linux environment is now the ultimate root, because even Android doesn't know it exists. You can log anything from Android and save it, you can stop any Android process. You have complete control over your Android system.
However, before making the "plunge" to a Linux only phone, you need a few details. The easiest way to get these is to do some research on your phone. Through SSH, run the ls command in your /dev folder, and look for "input"
Code:
$ cd /dev
$ ls |grep input
/dev/input
/dev/input/event7
/dev/input/event6
/dev/input/event5
/dev/input/event4
/dev/input/event3
/dev/input/event1
/dev/input/event0
/dev/input/event2
On my Samsung Captivate Glide, these are all the available inputs. But what are they? Well, there are several tools to check this. The easiest way, however, is to SSH into Linux, start x11vnc in Linux, and use an app like bvncfree in Android to bring up a visual screen to work with. How you need to do this is a bit tough to describe, because it is so dependent upon your phone and setup. However, if you are using my files, the user trondroid should have a shell script in the home folder for starting jwm in this fashion.
Another way is to start the XserverXDSL app in Android, and then startx in Linux through SSH. That should get you to the same place.
Once you have established a "visual" screen, you now should open up a terminal in your Linux screen. Remember, all input commands that you input right now are from the Android app you are using. That means the "mouse", "click", and "keyboard" are all virtual. You need to set up your real screen as a mouse, for motion and clicking. You also need to set up your physical buttons from your phone, and your keyboard if you have one. With your terminal open, use evtest, like so:
Code:
$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: STMPE_keypad
/dev/input/event1: mpu-accel
/dev/input/event2: sec_key
/dev/input/event3: sec_touchscreen
/dev/input/event4: proximity_sensor
/dev/input/event5: light_sensor
/dev/input/event6: HALL
/dev/input/event7: sec_touchkey
/dev/input/event8: compass_sensor
This even works on your home computer. For instance, here is my laptop:
Code:
$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Sleep Button
/dev/input/event1: Lid Switch
/dev/input/event2: Power Button
/dev/input/event3: AT Translated Set 2 keyboard
/dev/input/event4: Logitech USB Optical Mouse
/dev/input/event5: SynPS/2 Synaptics TouchPad
/dev/input/event6: Video Bus
/dev/input/event7: ST LIS3LV02DL Accelerometer
/dev/input/event8: HDA ATI SB Mic
/dev/input/event9: HDA ATI SB Line
/dev/input/event10: HDA ATI SB Headphone
/dev/input/event11: HP WMI hotkeys
Select the device event number [0-11]:
But we will focus on the phone. Great! Now we know what event is what input! For instance, event3 is the touchscreen. Now we have something to work with. In my case, event0 is the physical keyboard, but those are rare these days.
You can also test those inputs, by choosing a number for the device, and then using that function. Here you can see me test the "menu key" on the keyboard:
Code:
Menu Key on keyboard
Event: time 25170.575766, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8b
Event: time 25170.575844, type 1 (EV_KEY), code 139 (KEY_MENU), value 0
Event: time 25170.575854, -------------- EV_SYN ------------
Another great tool is called xev, again, open up a terminal and use it like this:
Code:
$ xev
ButtonRelease event, serial 33, synthetic NO, window 0x1e00001,
root 0x26f, subw 0x0, time 156984900, (175,123), root:(228,195),
state 0x100, button 1, same_screen YES
MotionNotify event, serial 33, synthetic NO, window 0x1e00001,
root 0x26f, subw 0x0, time 156985076, (177,123), root:(230,195),
state 0x0, is_hint 0, same_screen YES
There is also xinput, here is an output from my computer:
Code:
$ xinput test-xi2
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Optical Mouse id=9 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
↳ HP WMI hotkeys id=12 [slave keyboard (3)]
EVENT type 13 (RawKeyPress)
device: 3 (10)
detail: 54
valuators:
cEVENT type 14 (RawKeyRelease)
device: 3 (10)
detail: 54
valuators:
EVENT type 13 (RawKeyPress)
device: 3 (10)
detail: 40
valuators:
The overall idea, though, is that you need to open up an x session, so you can then see what x inputs are matched to which event. Once you have all of this information, you can edit the /etc/X11/xorg.conf file to match. Here is the one I made for the Samsung Captivate Glide:
Code:
Section "ServerLayout"
Identifier "Layout0"
Screen "Screen0"
InputDevice "touchscreen" "CorePointer"
InputDevice "keyboard"
InputDevice "mediakeys"
InputDevice "frontkeys"
EndSection
Section "Monitor"
Identifier "Monitor0"
ModelName "Monitor Model"
DisplaySize 800 480
EndSection
Section "InputDevice"
Identifier "touchscreen"
Driver "evdrv"
Option "Device" "/dev/input/event3"
Driver "multitouch"
EndSection
Section "InputDevice"
Identifier "keyboard"
Driver "evdev"
Option "Device" "/dev/input/event0"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "keyboard"
Driver "evdev"
Option "Device" "/dev/input/event8"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection
Section "InputDevice"
Identifier "mediakeys"
Driver "evdev"
Option "Device" "/dev/input/event2"
EndSection
Section "InputDevice"
Identifier "frontkeys"
Driver "evdev"
Option "Device" "/dev/input/event7"
EndSection
Section "Device"
Identifier "Card0"
Driver "fbdev"
Option "fbdev" "/dev/graphics/fb0"
Option "Rotate" "left"
Option "VertRefresh" "60"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
DefaultDepth 16
SubSection "Display"
Depth 16
EndSubSection
EndSection
Notice how you must declare a screen, a monitor, and then the card that controls it. /dev/graphics/fb0 is the framebuffer that you got the other day, if you were following along with these posts. You will also notice, that for each section, a driver is declared. The drivers used here are generic drivers. You may have different hardware, and use different drivers. So, if one doesn't work, google the xorg.conf section and the word drivers to see some of the different drivers available. You may even need proprietary drivers specific for your device. Like I said though, these generic drivers worked great for me. So I would try those first.
Once you have your drivers and xorg.conf file all set, it is time to take the plung. Be sure to back up your system first. Remember, TWRP or CWM are your freinds, as they work outside of all of the other work you are doing. So you can always start over or go back to something else.
Now, go back to your /etc/rc.local file. It should say:
Code:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
# Start the ssh client, in the event you need it.
/etc/init.d/hostname.sh start
/etc/init.d/ssh start
# Clean up bad crash before starting x server.
# /sbin/busybox mkdir -p /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/
# Start the x server, warning, if the touchscreen or keypad doesn't work
# then you cannot escape without killing power!
#/usr/bin/startx &
#export USER=root
#vncserver :5000
exit 0
And change the last part to say this:
Code:
# Start the x server, warning, if the touchscreen or keypad doesn't work
# then you cannot escape without killing power!
/usr/bin/startx &
#export USER=root
#vncserver :5000
exit 0
Now you have told it to startx on the next startup. If all goes well, reboot your phone, and you should see the XFCE desktop. If not, then you need to figure out how to edit the xorg.conf file to make it work right. You may also need to uncomment the lines about rmdir /tmp/.X11-unix, and the other lines like it, if your xserver ever crashes.
I have noticed several variants, especially on Android 4.4 and newer, that it will startx, but also start Android. You will see one normally, and then a small, pink version of the other overlayed on part of the screen. Almost like a picture in picture TV, but very dificult to understand or use. In these cases, you may need to add a command to kill surfaceflinger, or stop zygote to get Android to "clear out". You actually could just skip Android altogether, but having the chrooted Android is great for playing with making phone calls, etc, as I do not know how to do that from Linux yet.
If you made this work then you do have some pretty good Linux skills, if I may be so bold. This is not an easy task, and not for the faint of heart. So great job! Now it is up to you to improve upon this and make it useful. Who knows, you might be giving Ubuntu Touch a run for the money!
tim241 said:
Sorry, I needed to remove linux because I needed space for windows. Sorry , maybe I will take some time later to redo everything
Click to expand...
Click to collapse
No problem! I just hadn't heard from you in a while.
AlaskaLinuxUser said:
No problem! I just hadn't heard from you in a while.
Click to expand...
Click to collapse
Hey uh, I tried following your instructions but I'm stuck on step 9.
From what I can tell from a ton of debugging, it gets stuck at this line.
Code:
/sbin/busybox mount -t ext4 -o noatime,nodiratime,errors=panic /dev/mmcblk1p2 /mnt/root
It seems to be unable to mount it, I've no idea why though because I have no way of seeing any results aside from 'phone boots up' or 'phone loops' which makes debugging a bit hard heh.
Mounting it in Android and recovery (TWRP) works just fine so I'm pretty certain that '/dev/mmcblk1p2' is the right address and I've tried to mount the fat32 partition of the sd card so I could redirect the output of the mount command to a file but mounting the fat32 partition fails as well.
Maybe it's the population of /dev that's failing?
Code:
/sbin/busybox mdev -s
I tried manually creating the node as well to see if that'd help fix anything
Code:
/sbin/busybox mknod /dev/logs b 179 33
Alas, it didn't work for unknown reasons or of course, mdev and mknod could have worked but the mount failed for other unknown reasons. No idea and as far as I can think, no way of figuring it out to my knowledge.
P.s
My phone is the HTC One m8, earliest Android version I could find was 4.4, Cyanogenmod 11. 64 GB class 10 micro SD Card
P.p.s
Thank you for making such a comprehensive guide!
p.p.p.s
It's 12:26am and I'm so very very tired. I spent at about 9 hours on this wow