Per the Nookie Froyo thread they have a suggestion to increase the refresh rate to 68000 to stop/reduce flicker.
I noticed a similar flicker on "stock" 2.1 and checked /sys/devices/omapdss/display0/timings only to find out it is also set at 48000. I increased it to 68000, but it is reset after each reboot.
What is the proper refresh rate? Anyone else notice a flicker on the stock ROM?
jleecong said:
Per the Nookie Froyo thread they have a suggestion to increase the refresh rate to 68000 to stop/reduce flicker.
I noticed a similar flicker on "stock" 2.1 and checked /sys/devices/omapdss/display0/timings only to find out it is also set at 48000. I increased it to 68000, but it is reset after each reboot.
What is the proper refresh rate? Anyone else notice a flicker on the stock ROM?
Click to expand...
Click to collapse
what process did you use to modify the file?
paleh0rse said:
what process did you use to modify the file?
Click to expand...
Click to collapse
I used the following from the thread I linked.
Code:
adb shell echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
jleecong said:
I used the following from the thread I linked.
Code:
adb shell echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
Click to expand...
Click to collapse
Did you su and mount as r/w first?
paleh0rse said:
Did you su and mount as r/w first?
Click to expand...
Click to collapse
You don't remount /sys
so does anyone know how to make this stick after boot?
dennisi01 said:
so does anyone know how to make this stick after boot?
Click to expand...
Click to collapse
See the thread I just made: http://forum.xda-developers.com/showthread.php?t=901791
jleecong said:
I used the following from the thread I linked.
Code:
adb shell echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
Click to expand...
Click to collapse
Originally Posted by dennisi01
so does anyone know how to make this stick after boot?
See the thread I just made: http://forum.xda-developers.com/showthread.php?t=901791
Click to expand...
Click to collapse
Thank you both. Seems to work. Now I know how to run my own scripts afterboot.
Does that mean we add the
adb shell echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
Click to expand...
Click to collapse
at the end of the clrbootcount.sh text to have it run that command to fix the refresh and make it stick?
I did this (as I posted in the nook flicker thread):
I did a CAT on immediately after, and it had defaulted instead to 66461 instead of 68000 (maximum rate for the chip?)
Of course it also cleared upon reboot. Should I have seen a flicker improvement right away?
After clearing up all the posted suggestions listed here is what worked for me
greenmky said:
I did this (as I posted in the nook flicker thread):
I did a CAT on immediately after, and it had defaulted instead to 66461 instead of 68000 (maximum rate for the chip?)
Of course it also cleared upon reboot. Should I have seen a flicker improvement right away?
Click to expand...
Click to collapse
I also get 66461
------------------------
increase the refresh rate to 68000/66461 to stop/reduce flicker.
---------------------------------------------------------------------------
adb pull /system/bin/clrbootcount.sh
gedit clrbootcount.sh (assume you stay in specific dir)
add this to end of file and save
---------------------------------------------------
#run other commands
setprop persist.service.mount.umsauto 0
---------------------------------------------------
NEXT
adb shell mount -o rw,remount -t ext2 /dev/block/mmcblk0p5 /system
adb push clrbootcount.sh /system/bin/clrbootcount.sh
adb shell chmod 755 /system/bin/clrbootcount.sh
adb shell mount -o ro,remount -t ext2 /dev/block/mmcblk0p5 /system
adb shell reboot
--------------
NEXT
adb shell - NOW AT THE su # PROMPT (HAD NO LUCK WITH THE ADB SHELL and then commands all in one line)
cat /sys/devices/omapdss/display0/timings
mount -o remount,rw /dev/block/mmcblk0p5 /system
chmod 0755 /sys/devices/omapdss/display0/timings
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
mount -o ro,remount -t ext2 /dev/block/mmcblk0p5 /system
reboot
-----------------------------------------------
NEXT
cat /sys/devices/omapdss/display0/timings
66461,1024/70/200/40,600/10/11/10
----------------------------------------------
Three reboots and I still have the changes...
Read all the posting listed if you want/need more details....
here.david said:
adb shell - NOW AT THE su # PROMPT (HAD NO LUCK WITH THE ADB SHELL and then commands all in one line)
cat /sys/devices/omapdss/display0/timings
mount -o remount,rw /dev/block/mmcblk0p5 /system
chmod 0755 /sys/devices/omapdss/display0/timings
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
mount -o ro,remount -t ext2 /dev/block/mmcblk0p5 /system
reboot
Click to expand...
Click to collapse
You do not need to remount /system to write to /sys, and if you have chmod at all (unlikely) it would not be 755, it would be 644.
here.david said:
I also get 66461
------------------------
increase the refresh rate to 68000/66461 to stop/reduce flicker.
---------------------------------------------------------------------------
adb pull /system/bin/clrbootcount.sh
gedit clrbootcount.sh (assume you stay in specific dir)
add this to end of file and save
---------------------------------------------------
#run other commands
setprop persist.service.mount.umsauto 0
---------------------------------------------------
NEXT
adb shell mount -o rw,remount -t ext2 /dev/block/mmcblk0p5 /system
adb push clrbootcount.sh /system/bin/clrbootcount.sh
adb shell chmod 755 /system/bin/clrbootcount.sh
adb shell mount -o ro,remount -t ext2 /dev/block/mmcblk0p5 /system
adb shell reboot
--------------
NEXT
adb shell - NOW AT THE su # PROMPT (HAD NO LUCK WITH THE ADB SHELL and then commands all in one line)
cat /sys/devices/omapdss/display0/timings
mount -o remount,rw /dev/block/mmcblk0p5 /system
chmod 0755 /sys/devices/omapdss/display0/timings
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
mount -o ro,remount -t ext2 /dev/block/mmcblk0p5 /system
reboot
-----------------------------------------------
NEXT
cat /sys/devices/omapdss/display0/timings
66461,1024/70/200/40,600/10/11/10
----------------------------------------------
Three reboots and I still have the changes...
Read all the posting listed if you want/need more details....
Click to expand...
Click to collapse
Tried all that and it did not stick. The final CAT showed a reversion to 48000. Still don't understand how the change to the clrbootcount.sh is supposed to make it stick but it isn't working.
DatterBoy said:
Tried all that and it did not stick. The final CAT showed a reversion to 48000. Still don't understand how the change to the clrbootcount.sh is supposed to make it stick but it isn't working.
Click to expand...
Click to collapse
It wouldn't. The change to the clrbootcount.sh only changes the automount, the change to the /sys var is completely temporary. I assume one could also put it in the clrbootcount.sh, assuming it isn't modified later by the system (negating the change made from the clrbootcount.sh script).
Yeah. not sure how anyone is getting this to work but i can't figure it out. As a warning, modifying the clrbootcount.sh and trying to incorporate the fefresh change script has force firmware into boot loop to needing a factory reset twice now. Wonder if anyone else had the same experience.
The flicker is annoying and the refresh change works, but just won't stick.
To get it to stick, follow the steps on my other thread http://forum.xda-developers.com/showthread.php?t=901791.
When you edit clrbootcount.sh, add the following to the end:
Code:
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
The final file (if you also want to disable automounting), will look like:
Code:
#!/system/bin/sh
##################################################################################
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
/data/boot_complete_hook.sh
# Zero the boot count
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
#run other commands
setprop persist.service.mount.umsauto 0
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
While I've never really looked at this, but isn't the "refresh" "rate" largely irrelevant with LCD based screens? I'd always just assumed that even assigning them a "refresh" "rate" was just a place holder to make things work and not break CRT compatibility in drivers/display engines.
Did all this from a super clean root. Did not hold.
cutterjohn said:
While I've never really looked at this, but isn't the "refresh" "rate" largely irrelevant with LCD based screens? I'd always just assumed that even assigning them a "refresh" "rate" was just a place holder to make things work and not break CRT compatibility in drivers/display engines.
Click to expand...
Click to collapse
Don't know if that is true, but I have seen flicker on other LCD panels that could be addressed with refresh changes. The echo command does work instantly on the NC but just won't hold for me.
I have been playing with this and while the changes in clrbootcount.sh do stick, I'm unable to get it to either set the refresh rate or run a script that sets the refresh that I KNOW works from the terminal. Seems idealy this should be set in the ROM. Back to the terminal...
I should add I'm running 1.0.1 (Auto-Nooter 2.12.25) and also tried it in Nookie Froyo.
Related
can someone give me a tutorial on how to update the user.conf..i have looked at the compcache threads and linux swap but im not getting it...i want to be able to update it through terminal emulator and do i have to do nething to the userinit.sh if i change the user.conf...because numerous configs i have done for swappiness and linux swap...etc, have shown no difference..can somone give me a walkthrough...thanks so much..sry if i have a lot of questions just want to make myself more knowledgeable so i can hopefully return the favor to somone else one day
i do not know if you can edit it through the terminal sorry. i do know that you do not have to change the userinit.sh if you change user.conf, also i do know that you can open it up with PSPad (thats what i use) on a computer edit it there and push it back to phone and reboot. sorry i couldn't answer all of your questions
well i have had no problems editing it...its just putting it back nd making sure it works..now i have no problem using adb if u know of a tutorial to use it on mac...or know how to use it on mac
when you put it back on the phone did you make sure to chmod 755 it after you put it back on the phone and reboot?
then to text it with adb just type adb shell sh /system/sd/userinit.sh -s and see if the new values you put in are reflected in the output of that command
david1171 said:
when you put it back on the phone did you make sure to chmod 755 it after you put it back on the phone and reboot?
then to text it with adb just type adb shell sh /system/sd/userinit.sh -s and see if the new values you put in are reflected in the output of that command
Click to expand...
Click to collapse
delete this post; see below...
david1171 said:
when you put it back on the phone did you make sure to chmod 755 it after you put it back on the phone and reboot?
then to text it with adb just type adb shell sh /system/sd/userinit.sh -s and see if the new values you put in are reflected in the output of that command
Click to expand...
Click to collapse
this applies to tools and location of user.conf on cyanogen's roms ->
-transfer it to the root of your sdcard from your pc or mac to the g1.
-unmount sdcard from dropdown on the g1
-open up terminal on the g1
type and hit enter afterwards: cp /sdcard/user.conf /system/sd
type and hit enter afterwards: dos2unix /system/sd/user.conf
type and hit enter afterwards: chmod 664 /system/sd/user.conf
type and hit enter afterwards: exit
reboot
see this is my problem..it does not find it in system/sd...it is in system/bin so am i suppsed to copy it back to /system/bin or system/sd
and can someon explain what the difference is between chmod 664 and chmod 755 nd why i should do them
bonkasnucca said:
see this is my problem..it does not find it in system/sd...it is in system/bin so am i suppsed to copy it back to /system/bin or system/sd
and can someon explain what the difference is between chmod 664 and chmod 755 nd why i should do them
Click to expand...
Click to collapse
i think chmod 755 gives it read/write permissions. do not know about 664. try putting it in system/sd with adb then chmod 755 it and see if that works
david1171 said:
i think chmod 755 gives it read/write permissions. do not know about 664. try putting it in system/sd with adb then chmod 755 it and see if that works
Click to expand...
Click to collapse
775 = rwx-rwx-rx. conf file does not need executable in u-g nor x in o groups.
664 = rw-rw-r
if it is in /system/bin do this:
open up terminal
dos2unix /sdcard/user.conf
su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cp /sdcard/user.conf /system/bin
chmod 664 /system/bin/user.conf
mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system
exit
exit
reboot
so thats what i get when i try to run fix permissions from terminal.
HTML:
/system/bin/fix_permissions 2.03 started at 01-12-2010 05:08:24
99 does not exist (1 of 99). Reinstall...
/system/bin/fix_permissions 2.03 ended at 01-12-2010 05:08:25 (Runtime:0m1s)
i tried replacing the system/bin/fix_p.. with one from cyans rom using rootexplorer.apk but the i get permissions denied when i try to run fix_p.. in terminal.
Also mount -w doesn't work.
installed the room after full wipe n even repartitioned my sd.
im not the only one with that problem too
You are supposed to run it in recovery. Just select the option there.
evilkorn said:
You are supposed to run it in recovery. Just select the option there.
Click to expand...
Click to collapse
ill run it from where i want to run and it wasn't my question.
double post
BrutalHoe said:
ill run it from where i want to run and it wasn't my question.
Click to expand...
Click to collapse
What's with the hostility?
Code:
$su
# mount -o rw,remount /dev/block/mtdblock3 /system
# cp /sdcard/fix_permissions /system/bin
# reboot
When it loads back up, either ADB Shell or Terminal :
#fix_permissions
Use this fix_permissions:
http://www.mediafire.com/?mwkxynmzumy
akapoor said:
What's with the hostility?
Code:
$su
# mount -o rw,remount /dev/block/mtdblock3 /system
# cp /sdcard/fix_permissions /system/bin
# reboot
When it loads back up, either ADB Shell or Terminal :
#fix_permissions
Use this fix_permissions:
http://www.mediafire.com/?mwkxynmzumy
Click to expand...
Click to collapse
dont like pll who jsut wanna post something useless.
ty ill try that.
I might have editted the post a little late, but make sure you have the fix_permissions file on your sd card.
How is your Ivory Throne?
BrutalHoe said:
dont like pll who jsut wanna post something useless.
ty ill try that.
Click to expand...
Click to collapse
evilkorn made a legitimate post. he said you're supposed to run it from recovery. that was his input and he made it known. how is that useless?
Eh, I don't know what I was thinking, but this is the correct form:
Code:
$ su
# mount -o remount,rw /dev/block/mtdblock3 /system
# cp /sdcard/fix_permissions /system/bin/fix_permissions
# chmod 755 /system/bin/fix_permissions
# reboot
Then when its back up do
Code:
$su
# fix_permissions
Sorry about that.
akapoor said:
Eh, I don't know what I was thinking, but this is the correct form:
Code:
$ su
# mount -o remount,rw /dev/block/mtdblock3 /system
# cp /sdcard/fix_permissions /system/bin/fix_permissions
# chmod 755 /system/bin/fix_permissions
# reboot
Then when its back up do
Code:
$su
# fix_permissions
Sorry about that.
Click to expand...
Click to collapse
nvm .
Are you doing it through Terminal or ADB?
And make sure your phone is not mounted. If it is (since you had to put the fix_permissions on the sdcard), unmount it.
evilkorn said:
How is your Ivory Throne?
Click to expand...
Click to collapse
grandomegabosses said:
evilkorn made a legitimate post. he said you're supposed to run it from recovery. that was his input and he made it known. how is that useless?
Click to expand...
Click to collapse
if u dont have an answer for my question then plz
Mod Edit
no need for that is there?
akapoor said:
Are you doing it through Terminal or ADB?
And make sure your phone is not mounted. If it is (since you had to put the fix_permissions on the sdcard), unmount it.
Click to expand...
Click to collapse
terminal i jsut reinstalled windows 7 havent had time to set up adb but yeah i know ty man im gonna try in a min.
Oh by the way, posting pics like it's 4chan make you look like a 14 year old tool.
On topic: I was under the impression that fix_permissions was made to run in recovery. You make it seem like it's a chore to reboot and run it the proper way.
evilkorn said:
Oh by the way, posting pics like it's 4chan make you look like a 14 year old tool.
On topic: I was under the impression that fix_permissions was made to run in recovery. You make it seem like it's a chore to reboot and run it the proper way.
Click to expand...
Click to collapse
it can b run from either places. ty bye
akapoor said:
Eh, I don't know what I was thinking, but this is the correct form:
Code:
$ su
# mount -o remount,rw /dev/block/mtdblock3 /system
# cp /sdcard/fix_permissions /system/bin/fix_permissions
# chmod 755 /system/bin/fix_permissions
# reboot
Then when its back up do
Code:
$su
# fix_permissions
Sorry about that.
Click to expand...
Click to collapse
not working i get cp: cannot stat '/sdcard/fix_permissions' :no such file or dir
its at the root of sd n sd is unmounted
Are you sure that it's correctly named as "fix_permissions" on the root folder of the SD card?
In Terminal,
Code:
$ cd /sdcard
$ ls
Is the file listed there?
yea but its with .txt extension.....that my prob aint it?
BrutalHoe said:
yea but its with .txt extension.....that my prob aint it?
Click to expand...
Click to collapse
it should be .sh, if i remember correctly
Ok, I'm not a total noob. I've been trying to return to 1.5 as cleanly as possible, but now I'm having an error when trying to remount my phone.
Code:
C:\android-sdk-windows\tools>adb devices
List of devices attached
HT9C1HF03306 device
C:\android-sdk-windows\tools>adb remount
remount failed: Operation not permitted
C:\android-sdk-windows\tools>adb shell
$ su
su
#
This is what I did:
Flashed the 1.5 RUU that Flipz has had out for months. No errors
Ran the Avalaunch PRI fix to get rid of the flipz_01 PRI name
updated my profile
updated my PRL (which is now 65000??)
rooted through the normal sequence without error, I can boot to the recovery just fine, but when I adb shell into the phone I end up at $ instead of #. I have to su to get to # and at the c:\windows-sdk-windows\tools\adb remount fails with "remount failed: operation not permitted"
Is it possible that the PRI update has foiled the root exploit? I even restored a nand backup that I know had a working root and I still have the same results. This is too weird.
Anyone else have this issue? I searched the forum but I came up empty.
Try adb remount before adb shell. I'm pretty sure anythig with adb should be ran at just the command prompt.
Someone feel free to correct me if I'm wrong.
right, this is at the c:\android-sdk-windows\tools\ prompt. I guess I need to re-word that last bullet point to be more clear.
Code:
C:\android-sdk-windows\tools>adb devices
List of devices attached
HT9C1HF03306 device
C:\android-sdk-windows\tools>adb remount
remount failed: Operation not permitted
C:\android-sdk-windows\tools>adb shell
$ su
su
#
Yeah the wording got me. I was hoping it was as simple as that for you tho. Defiantly Strange. Believe me I've had plenty of those moments where hours would have been saved if someone could have just said "no your just doing it wrong".
Maybe try rerunning the RUU and start from scratch the PRI fix should hold thru the RUU but if it did affect something else running the RUU again may correct it.
I RUU'd about 4 times so far on two different laptops, one with XP and one with Win7, running both versions of the HTC Sync drivers.
Something is definitely different. I'm thinking of doing the PRI fix again to see if that helps. The PRL being 65000 instead of the normal 60664 is another anomaly I'm curious about.
looks as if the 65000 PRL is a new one. I can't confirm (not with Sprint) but there is a thread over in General talking about it.
http://forum.xda-developers.com/showthread.php?t=684873
YEAH! I fixed it....well....actually Flipz fixed it for me. I created a custom ROM in the kitchen and flashed it. Now the remount miraculously works. I'm back to being happy...though I don't know why. Its not like I was using root for anything
Nextelian said:
right, this is at the c:\android-sdk-windows\tools\ prompt. I guess I need to re-word that last bullet point to be more clear.
Code:
C:\android-sdk-windows\tools>adb devices
List of devices attached
HT9C1HF03306 device
C:\android-sdk-windows\tools>adb remount
remount failed: Operation not permitted
C:\android-sdk-windows\tools>adb shell
$ su
su
#
Click to expand...
Click to collapse
Can someone splain how to fix this issue w/o flashing? Like maybe from command prompt/shell? Pleeeeease?
mrsato said:
Can someone splain how to fix this issue w/o flashing? Like maybe from command prompt/shell? Pleeeeease?
Click to expand...
Click to collapse
I found something that help me and you. it properly works!!
I can't spell out instructions for the above mentioned suggestion, since I
don't know which file editor comes on the shipped device, but I have an
alternative solution.From the SDK's tools directory, run adb shell. In the
prompt run the following:
# su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system (Or any subdirectory you want to push to inside system)
# exit
adb push <local file> <device location>
and eventually you should restore the original directory permissions by:
# chmod 755 /system (Or any subdirectory you modified permissions to)
Hope this helps,
Yoav
Click to expand...
Click to collapse
still no Read/Write on /system
I tried the above, and I could not mount /system as read/write:
Code:
adb shell
$ su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
Permission denied
$ mount: Operation not permitted
My Android 1.6 is rooted, so I feel like I should be able to do this. But any help would be...helpful.
mojotexas said:
I tried the above, and I could not mount /system as read/write:
Code:
adb shell
$ su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
Permission denied
$ mount: Operation not permitted
My Android 1.6 is rooted, so I feel like I should be able to do this. But any help would be...helpful.
Click to expand...
Click to collapse
I'm not at my computer but I think the command is off... check to make sure its exactly how it should be... maybe the coma after the rw
Sent from my HERO200 using XDA App
mojotexas said:
I tried the above, and I could not mount /system as read/write:
Code:
adb shell
$ su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
Permission denied
$ mount: Operation not permitted
My Android 1.6 is rooted, so I feel like I should be able to do this. But any help would be...helpful.
Click to expand...
Click to collapse
Just cd to your tools directory and adb remount
huedawg said:
Just cd to your tools directory and adb remount
Click to expand...
Click to collapse
Is there a solution for this?
I have a rooted HTC Desire.
When I type adb remount I get permission denied.
When I type adb shell and then su , i get permission denied!
This was a stock 2.2 rooted with unrevoked 3.
Any idea?
[edit]
i noticed root permissions pop-up on the phone and allowed so su worked.
[/edit]
Hi,
I have a Desire with stock froyo rooted with unrevocked 3 too and cannot use adb remount:
D:\android-sdk-windows\tools>adb remount
remount failed: Operation not permitted
Click to expand...
Click to collapse
D:\android-sdk-windows\tools>adb shell
$ remount
remount
remount: permission denied
$
Click to expand...
Click to collapse
I have allowed ADB via the Super user app popup.
Any idea?
EDIT: I have set S-OFF using AlphaRev's recovery fastboot and I am now able to remount in rw (well no access denied anymore)
still missing some access as I fail to remove the Google Maps app (want to use Brut maps only)
ghost_boy1412 said:
I found something that help me and you. it properly works!!
Click to expand...
Click to collapse
This worked perfectly! Thank you!
Good freakin lord why the heck did you feel the need to bump this thread thats almost a year old just to say that!!!!!!!! I rarly shout like this, but this crap is starting to drive me crazy!!!!!!!!!!!!
Grrrrrrrrrrrrrrr
same thing for me. i get permission denied
DannyMichel said:
same thing for me. i get permission denied
Click to expand...
Click to collapse
thank you for letting us all know, and in such detail, and with new valuable information no less
/me shakes fists in rage.
Post deleted.
Don't mean to bring up this dead thread but a more simple solution would be this
adb shell
$ su
# busybox mount -o remount,rw /system (or another desired directory)
# chmod 777 (or another desired permission set) /system (or another desired directory)
# exit
$ exit
Here is an easy way to run commands after each boot.
In the init.rc file, the file /system/bin/clrbootcount.sh always gets run after a successful boot. Since it isn't trivial to change the init.rc file, we will use clrbootcount.sh to run commands after a boot. Since people are having issues with modifying clrbootcount.sh, we will choose a safer method.
clrbootcount.sh will always attempt to call /data/boot_complete_hook.sh, which doesn't exit. We are going to create this file and use that to run commands.
Create a file named boot_complete_hook.sh with the following contents (On Windows, use Notepad++):
Code:
#!/system/bin/sh
##################################################################################
#
# File boot_complete_hook.sh
# Description Run any commands that you want to be run after boot
#
##
setprop persist.service.mount.umsauto 0
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
Save and close.
Now, execute the following commands to put the file on your nook:
Code:
adb push boot_complete_hook.sh /data/boot_complete_hook.sh
adb shell chmod 755 /data/boot_complete_hook.sh
Note:
Before you reboot verify that the file will run properly. Open up a shell via adb shell. Inside that run the following:
Code:
setprop persist.service.mount.umsauto 1
getprop persist.service.mount.umsauto
You should see 1 as the output. Now run:
Code:
sh /system/bin/clrbootcount.sh
You should see an output similar to:
Code:
4+0 records in
4+0 records out
4 bytes transferred in 0.010 secs (400 bytes/sec)
Now run:
Code:
getprop persist.service.mount.umsauto
If 0 is printed out, exit the shell.
If 0 is not printed out, something went wrong and the file will not be run properly on the next boot. If you do reboot in this state 8 times, the boot count won't be reset and you will hit the factory reset. While you are trying to get the script working, you could always manually reset the boot count by executing (from a shell):
Code:
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
Now reboot:
Code:
adb shell reboot
As you are rebooting, run:
Code:
adb shell getprop persist.service.mount.umsauto
It will return 1 since the init.rc file sets it to 1 explicitly. However, once you are fully booted it will return 0.
Didn't work for me.
JoshMiers said:
Here is an easy way to run commands after each boot.
In the init.rc file, the file /system/bin/clrbootcount.sh will always gets run after a successful boot. Since it isn't trivial to change the init.rc file, we will use clrbootcount.sh to run commands after a boot.
Do:
Code:
adb pull /system/bin/clrbootcount.sh .
Open the file (on Windows, don't use Notepad) and you should see:
Code:
#!/system/bin/sh
##################################################################################
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
/data/boot_complete_hook.sh
# Zero the boot count
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
Add the following to the end of the file:
Code:
#run other commands
setprop persist.service.mount.umsauto 0
Save and close.
Now, execute the following commands to put the file back on your nook:
Code:
adb shell mount -o rw,remount -t ext2 /dev/block/mmcblk0p5 /system
adb push clrbootcount.sh /system/bin/clrbootcount.sh
adb shell chmod 755 /system/bin/clrbootcount.sh
adb shell mount -o ro,remount -t ext2 /dev/block/mmcblk0p5 /system
adb shell reboot
As you are rebooting, run:
Code:
adb shell getprop persist.service.mount.umsauto
It will return 1 since the init.rc file sets it to 1 explicitly. However, once you are fully booted it will return 0.
Click to expand...
Click to collapse
Wouldn't this screw up the 8X "back to stock firmware" sequence since that depends on having the boot counter increment up to 8?
docfreed said:
Wouldn't this screw up the 8X "back to stock firmware" sequence since that depends on having the boot counter increment up to 8?
Click to expand...
Click to collapse
The script file is already there and already being called after each successful boot. The 8x boot counter logic happens with 8 failed boots. Regardless, the instructions just show you how to append a custom command to be run after the stock commands run, no other booting logic is affected.
>DARKMAN< said:
Didn't work for me.
Click to expand...
Click to collapse
What didn't work? Run the following and paste your output:
Code:
adb shell cat /system/bin/clrbootcount.sh
Code:
adb shell ls -l /system/bin/clrbootcount.sh
Awesome, thanks for the tip! Been wondering how to put in my own stuff into the init, I'd love to modify the path but I suspect this won't be the way, but regardless it's good info.
BTW, I have found that disabling this USM property seems to disable the SD card automounting but the Nook itself might still automount... But that's for another thread I suppose
Worked perfectly
This is exactly what I was looking for.
Thanks
Sent from my LogicPD Zoom2
There seems to be a little confusion over at the refresh rate thread http://forum.xda-developers.com/showthread.php?t=901294.
To be explicit, if you want to disable auto-mounting as well as change the refresh rate, you would edit clrbootcount.sh to have the following contents:
Code:
#!/system/bin/sh
##################################################################################
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
/data/boot_complete_hook.sh
# Zero the boot count
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
#run other commands
setprop persist.service.mount.umsauto 0
echo 68000,1024/70/200/40,600/10/11/10 > /sys/devices/omapdss/display0/timings
If you don't want to disable auto-mounting, just remove the line with
Code:
setprop persist.service.mount.umsauto 0
I ran what was posted and it still returns 1.
Sent from my HAXSUNG Moment
JoshMiers said:
What didn't work? Run the following and paste your output:
Code:
adb shell cat /system/bin/clrbootcount.sh
Code:
adb shell ls -l /system/bin/clrbootcount.sh
Click to expand...
Click to collapse
Screen shot attached (1.0.1 Auto-Nooter 2.12.25).
# cat /system/bin/clrbootcount.sh
cat /system/bin/clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
/data/boot_complete_hook.sh
# Zero the boot count
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
#
# ls -l /system/bin/clrbootcount.sh
ls -l /system/bin/clrbootcount.sh
-rwxr-xr-x root root 338 2011-01-06 19:50 clrbootcount.sh
#
edit double post oops
I lost my backup of clrbootcount.sh
and now it won't reset the boot count.
any help would be greatly appreciated.
adb shell getprop persist.service.mount.umsauto
Click to expand...
Click to collapse
always returns 1 during and after complete reboot. The echo command for screen does not persist. Have followed your instructions super letter by letter multiple times and leading up to the reboot everything is exactly as you say.
Right now, I am most concerned that whatever I have done will not reset the boot count since it stays at 1 and does not go to 0. I've already lost my entire setup twice and had to start from scratch trying to make this work. At least I know how to reset to 0 with the line command script but how do I ensure i don't need to worry about it?
I think this process may be a bust.
I am on 1.0.0 and have been using this since I posted it and both the refresh rate and automount values are sticking between reboots.
>DARKMAN< said:
# cat /system/bin/clrbootcount.sh
cat /system/bin/clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
/data/boot_complete_hook.sh
# Zero the boot count
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
#
# ls -l /system/bin/clrbootcount.sh
ls -l /system/bin/clrbootcount.sh
-rwxr-xr-x root root 338 2011-01-06 19:50 clrbootcount.sh
#
Click to expand...
Click to collapse
I am assuming you are using the new method, which would mean you need to post your /data/boot_complete_hook.sh
>DARKMAN< said:
I lost my backup of clrbootcount.sh
and now it won't reset the boot count.
any help would be greatly appreciated.
Click to expand...
Click to collapse
The clrbootcount.sh file that you posted is the default file. I will post it again:
Code:
#!/system/bin/sh
##################################################################################
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
/data/boot_complete_hook.sh
# Zero the boot count
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
Also, the original post explains how to manually reset the boot count. Here it is:
If 0 is not printed out, something went wrong and the file will not be run properly on the next boot. If you do reboot in this state 8 times, the boot count won't be reset and you will hit the factory reset. While you are trying to get the script working, you could always manually reset the boot count by executing (from a shell):
Code:
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4
jleecong said:
Screen shot attached (1.0.1 Auto-Nooter 2.12.25).
Click to expand...
Click to collapse
It appears you are running Windows, so I am hoping that you did not use Notepad to edit this file.
Since you are running 1.0.1, post your /init.rc file.
Thought I may have been doing something wrong since I used notepad but downloaded Notepad++ and created the new .sh file. Still no go. Screen still flickers and USB still automounts. Maybe 1.0.1 just is not commpatible with this process. Only difference I can see.
The getprop persist.service.mount.umsauto also indicates 1 after full boot and not 0. Pretty sure this will wipe everything out after 8 boots, going to wipe it all out now and proactively prevent it.
Device is pre-rooted, but only lets you do stuff via terminal. I didn't find a way to install Superuser/busybox on Mac, so I decided to make a simple guide. Took me all of 3min to complete, well since I already had the sdk and everything else installed.
You'll need this Superuser.apk, su binary and busybox.apk, dL the files from here http://d-h.st/BBk, once you have the files installed and launch Superuser it will ask you to update the binary, just click yes. Place the 3 files in your sdk/platform-tools folder.
Open Terminal cd sdk/platform-tools
On your Desktop go to Go…Go to Folder and type ~/.android, open adb_usb.ini and add 0x2836 to that file, save and close.
To verify it's listed:
./adb kill-server
echo 0x2836
./adb start-server
./adb devices
Your device should be listed here. If you want wireless adb access so you're not always hooked up to the console do the following, make sure your device is still connected via usb:
./adb tcpip 5555
unplug console
./adb connect xxx.xxx.xxx.xxx (this is the ip of your console, this is listed under manage…system…console info, should be the second line)
You're set, now you can install apps wirelessly to your OUYA console. You need to make the console read/write to do this do the following
./adb shell
su
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
Now we will install su binary, superuser and busybox
./adb push su/system/bin/su /sdcard/su
./adb shell
su
cat /sdcard/su > /system/xbin/su
ln -s /system/xbin/su /system/bin/su
chmod 6755 /system/xbin/su
exit
exit
./adb install com.koushikdutta.superuser.apk
./adb install stericson.busybox.apk
Should be up and running, if this helped you please thank me or donate a couple bucks
You rock!
I was at this for a while before I found your post. I'm on windows, but this is the only thread I could find that had anything useful Mind if I share this around on other forums?
Just link them back, steps are almost identical for Windows. Just need to remove the ./ from the adb commands
Sent from my HTC One using Tapatalk 4 Beta
WinDroidGuy said:
Device is pre-rooted, but only lets you do stuff via terminal. I didn't find a way to install Superuser/busybox on Mac, so I decided to make a simple guide. Took me all of 3min to complete, well since I already had the sdk and everything else installed.
You'll need this Superuser.apk, su binary and busybox.apk, dL the files from here http://d-h.st/BBk, once you have the files installed and launch Superuser it will ask you to update the binary, just click yes. Place the 3 files in your sdk/platform-tools folder.
Open Terminal cd sdk/platform-tools
On your Desktop go to Go…Go to Folder and type ~/.android, open adb_usb.ini and add 0x2836 to that file, save and close.
To verify it's listed:
./adb kill-server
echo 0x2836
./adb start-server
./adb devices
Your device should be listed here. If you want wireless adb access so you're not always hooked up to the console do the following, make sure your device is still connected via usb:
./adb tcpip 5555
unplug console
./adb connect xxx.xxx.xxx.xxx (this is the ip of your console, this is listed under manage…system…console info, should be the second line)
You're set, now you can install apps wirelessly to your OUYA console. You need to make the console read/write to do this do the following
./adb shell
su
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
Now we will install su binary, superuser and busybox
./adb push su/system/bin/su /sdcard/su
./adb shell
su
cat /sdcard/su > /system/bin/su
cat /sdcard/su > /system/xbin/su
exit
exit
./adb install com.koushikdutta.superuser.apk
./adb install stericson.busybox.apk
Should be up and running, if this helped you please thank me or donate a couple bucks
Click to expand...
Click to collapse
It's pure luck that this works. There's several things wrong with it.
There's no reason to have two copies of su. There should only be one, and at most have the other be a symlink.
the su binary should be chmodded '6755'.
It works because piping the contents of a file to another file usually leaves the permissions intact. So, sort of works - it leaves a broken copy of su in /system/bin and a luckily working one in /system/xbin.
So, tl;dr, the guide should be:
Code:
./adb push su/system/bin/su /sdcard/su
./adb shell
su
cat /sdcard/su > /system/xbin/su
ln -s /system/xbin/su /system/bin/su
chmod 6755 /system/xbin/su
exit
exit
./adb install com.koushikdutta.superuser.apk
rayman said:
It's pure luck that this works. There's several things wrong with it.
There's no reason to have two copies of su. There should only be one, and at most have the other be a symlink.
the su binary should be chmodded '6755'.
It works because piping the contents of a file to another file usually leaves the permissions intact. So, sort of works - it leaves a broken copy of su in /system/bin and a luckily working one in /system/xbin.
So, tl;dr, the guide should be:
Code:
./adb push su/system/bin/su /sdcard/su
./adb shell
su
cat /sdcard/su > /system/xbin/su
ln -s /system/xbin/su /system/bin/su
chmod 6755 /system/xbin/su
exit
exit
./adb install com.koushikdutta.superuser.apk
Click to expand...
Click to collapse
Thanks, this was my first time doing anything like this...figured I'd try to hack together something from other guides, since I didn't see very many people with the device yet. I will change it now
WinDroidGuy said:
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
Click to expand...
Click to collapse
This is really pointless, userdata is already RW, cache should be RW, but more importantly you do nothing that would require them to be remounted
I'm not sure what I am doing wrong here. Can anyone help? All the files are there.
TadeoNYC said:
I'm not sure what I am doing wrong here. Can anyone help? All the files are there.
Click to expand...
Click to collapse
The command should be "adb push su /sdcard/su" (pushing su to the sdcard).
Setup wired and/or wireless ADB
(Optional) Put adb.exe in your Windows PATH variable so you can run it from anywhere
Download and unzip the SuperUser files from http://d-h.st/BBk
Open an ADB shell with elevated permissions
Code:
adb shell
su
Mount the system partition as read-write
Code:
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
Exit the ADB shell
Code:
exit
exit
or CTRL + C
Push su to the sdcard
Code:
adb push su /sdcard/su
Open an ADB shell with elevated permissions
Code:
adb shell
su
Cat su into /system/xbin
Code:
cat /sdcard/su > /system/xbin/su
Create a symbolic link to su in /system/xbin from /system/bin (safer/cleaner than just putting su directly in the bin folder)
Code:
ln -s /system/xbin/su /system/bin/su
Set the su permissions to -rwsr-sr-x
Code:
chmod 6755 /system/xbin/su
Exit the ADB shell
Code:
exit
exit
or CTRL + C
Install SuperUser
Code:
adb install com.koushikdutta.superuser.apk
Install BusyBox
Code:
adb install stericson.busybox.apk
Run SuperUser on the OUYA (Make > Software > SuperUser) and allow it to update
Thank you Elmero.
I'm so glad I gave up and went to bed last night. It could not have gone smoother. I followed the instructions for setting up wireless adb from here http://forum.xda-developers.com/showthread.php?t=2272266 as well.
TIP: I wasted an hour or more trying to figure out why PC was not recognizing the OUYA at all. It was the stupid Micro usb port, compunding the fact that all the ports are to close to begin with the micro usb port is very deep. Neither of my Samsung cables worked, fortunately I have a kodak pocket video cam and the cable for that is a few mm longer and worked perfectly.
And who said Kodac isn't relevant anymore?
Sent from my Nexus 7 using xda premium
The link to the Superuser.apk is not working.
pdelponte said:
The link to the Superuser.apk is not working.
Click to expand...
Click to collapse
Working fine for me...
Sent from my HTC One using Tapatalk 4 Beta
WinDroidGuy said:
Working fine for me...
Sent from my HTC One using Tapatalk 4 Beta
Click to expand...
Click to collapse
Not working for me either.
This webpage is not available
The webpage at http://fs1.d-h.st/download/00044/BBk/superuser.zip might be temporarily down or it may have moved permanently to a new web address.
Click to expand...
Click to collapse
There is an issue with the website. Just try back until it connects.
Sent from my GT-P3113 using Tapatalk 2
just to be clear. once its rooted, can i install any android apk to the console? the one that i've bought from android play market?
tanush said:
just to be clear. once its rooted, can i install any android apk to the console? the one that i've bought from android play market?
Click to expand...
Click to collapse
1) It's already rooted.
2) You can already sideload anything you want to it, same as (almost) any android device, whether it is rooted or not. (http://forum.xda-developers.com/showpost.php?p=41796467&postcount=11)
elmerohueso said:
The command should be "adb push su /sdcard/su" (pushing su to the sdcard).
Setup wired and/or wireless ADB
(Optional) Put adb.exe in your Windows PATH variable so you can run it from anywhere
Download and unzip the SuperUser files from http://d-h.st/BBk
Open an ADB shell with elevated permissions
Code:
adb shell
su
Mount the system partition as read-write
Code:
mount -o rw,remount -t ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
Exit the ADB shell
Code:
exit
exit
or CTRL + C
Push su to the sdcard
Code:
adb push su /sdcard/su
Open an ADB shell with elevated permissions
Code:
adb shell
su
Cat su into /system/xbin
Code:
cat /sdcard/su > /system/xbin/su
Create a symbolic link to su in /system/xbin from /system/bin (safer/cleaner than just putting su directly in the bin folder)
Code:
ln -s /system/xbin/su /system/bin/su
Set the su permissions to -rwsr-sr-x
Code:
chmod 6755 /system/xbin/su
Exit the ADB shell
Code:
exit
exit
or CTRL + C
Install SuperUser
Code:
adb install com.koushikdutta.superuser.apk
Install BusyBox
Code:
adb install stericson.busybox.apk
Run SuperUser on the OUYA (Make > Software > SuperUser) and allow it to update
Click to expand...
Click to collapse
So what steps need to be repeated after the OTA?
from my limited understanding I think it should be steps 4 through 12. Or does the system partition not need to be mounted as read-write again?
Sent from my GT-P3113 using Tapatalk 4 Beta
Yup 4-12
Edit
If su is still on the sdcard you can skip 6-8... wont hurt if you do them though...
Sent from my SAMSUNG-SGH-I337 using xda app-developers app
professorpoptart said:
Yup 4-12
Edit
If su is still on the sdcard you can skip 6-8... wont hurt if you do them though...
Sent from my SAMSUNG-SGH-I337 using xda app-developers app
Click to expand...
Click to collapse
Might be a good idea to do them. The OTA version of such is different from the one in this guide. I had tried keeping the stock su and superuser complained
Sent from my Nexus 7 using xda premium
Do you still have access to the ouya store after SU installed? I heard rumors that access to the store was blocked until root access removed?
Sent from my GT-N7100 using Tapatalk 2