yashsingh1/xdaforums huggingface dataset:
[Gen9 Android Development] trevd:
Proving The Concept, The Good, The Bad and The Missing

Continuing what seems to be my own internal dialogue here. :D

I attached a ramdisk image.

What's good

Using Standard init which allow us to locate all the .rc files in the root of the ramdisk.

/sbin/recovery has the latest version of CWM ( 6.0.1.5 ) , More on this below

/sbin/abcbox, and it's symlinks are fully functional, Start that's the important stuff covered like getting the power led to blink :D LOL

adb shell led -b

I general have a kernel in my data partition so I can just send a initramfs.cpio.lzo and use /sbin/kd_flasher to flash them.

the recovery and adbd binary contain statically linked libcutils. I have fixed up the android_reboot.c code which to work correctly for switching

adb reboot recovery

will restart in recovery

adb reboot or adb reboot android

will reboot into the sde android. these work in recovery mode and also as standalone shell commands

adb shell
~# reboot
~# reboot recovery

Doing

adb start reboot_archos or adb start reboot_arecovery

will get you into the archos stock rom and archos boot menu respectively.

So this proves it possible and works quite nicely with little to no risk, I would say noooob proof, but there'll always be one exception to prove the rule.

What's Bad

MORE INFO TO FOLLOW SOON, but having the leave the house occasionally is bad at the minute :) and the Recovery Power Button Doesn't work atm so your pretty screwed for testing. so repeat after me PROOF OF CONCEPT

What's missing

The rest of this Post..... :) Obviously :) :silly:

I'll BRB!
[Gen9 Android Development] trevd:
Hi Folks let find out what happened this weekend. over on the inside my mind :laugh: Might Audition for XDA TV!!!!

Firstly It was all proving to be unnervingly simply. Obiviously the last zip proved the concept was feasable. I spent some time making this more secure and robust. I've create a new git repo which is a clone of the system/core/cutils and contains a patch android_reboot.c

With my First efforts I had over patched. this android_reboot function is about 2 or 3 calls before a completed bring down.

line number 108 - 120 are the additions, The patch works on the deault state being android and only switches to recovery when you send pass the word recovery as the arg. On nonesense is Ignored. I did some light fuzzing with passing nonsense to it , It coped quite well although I haven't tried any OS MAXIMUM +1 etc

Another Win on this is the the way the Android UserLand Works.

Basically descending through Java

Into JNI and finally hitting the android_reboot function with a reason code.

I've rebuilt the recovery but still was suffering for the " Action button" not functioning. all little odd but more cofiguration that bug..

adb rebooting and toolbox rebooting also all function correctly. So i'm sat there quite pleased with my ten line patch to control bootmodes.

but I've got doubts, It feels a little too hacky to stand up to any real world abuse, and after think how you would actually build update flashes etc the who thing kind of unravels and turns In a cluster**** of a support nightmare.

I'll explain what problems we WOULD face with this and I've also got the solution as well :) I've got some Smoking to do first.... these Posts seem to take me ****ing ages to write :)
[Gen9 Android Development] trevd:
Hi Again

So I was talking a few things through with surdu, I was about to explain some of the explicit consideration he would have to, take into.

"explicit considerations" WTF!!?! It's recovery, Yes Thinking It through any Update.zip especially one that need to update init.rc would

have the added responsibility of carrying and maintaining the Recovery Function , That's every thing in sbin, res as well as add specific Usb Confgiuaton, blah blah ****ing blah etc, I'm sure get the Picture.

SO, Is that It? A Nice Idea that a couple of folks might be able to use. If that were the case I would consider it a massive fail, Consideraing there's a voice of an optimist in these very pages who's state goal is to getting CWM going on the Archos G9 and Make it safe a usable for everyone..

Well Here' s that optimist again. I haven't tested this yet because my tablet needs some power!!!!

Back to basking in glory of that boot control switch. It struck me, instead of writing a pesistant property and having to force the unholy union of Android and Recovery Why not Just write then next ramdisk we want to load from with KD Flasher. It seems such an obvious thing to do It was a real life no-brainer and literally came from nowhere. I think that's what what Alcoholics refer to as a moment of clarity. :)

So This now give a standard recovery and standard Boot, I've not had an hard look at Letama boot Manager () , But to me It's sounds like I arriving a similar solution because the next word out of my are " you can even mount different kenel version and rapid cycle them

It reduce our exposure to accidental overwrites as the Edify Update has to explicitly overwrite the recovery image

Back To Easy Peasy Then :highfive:
[Gen9 Android Development] letama:
Well this solution works, however flashing over and over is a bad idea for the flash life expectancy.

Another point is safety: if something goes bad with your stock firmware, you won't be able to go back to recovery to fix the issue or reflash.
[Gen9 Android Development] trevd:
hmmm, Yeah never thought of that. It could be to the serious detriment of the hardware. Thanks alot. I suppose Its was just too perfect they had to be something ...

While I agree flashing over and over is bad , It not what I envisaged occurring. If i'm rebooting into android from android it wouldn't make any sense to flash anything, i would be just a of setting the reboot into flags,

I think I'm going to carry on I as am for now at least I can get CWM functioning, Both That and Android at least willl be running a layer above all this chaos I seem to be creating

Any Ideas or Input is welcome, Remember we are trying work within the constraints of the current device layout.
[Gen9 Android Development] trevd:
Hi Folks,

Hi attached a recovery binary that has been built with the correct UI Settings, The Power Button now acts as a selector and the Go Back option is available in submenus , You should be able to update the one from the ramdisk if your hacking on it.

my android_device_ti_archos github has the code for the UI changes which is setting in the BoardConfig, The same tree will also build the omapzoom 4.1.2 branch of the AOSP code with all OMAP_ENHANCEMENT turned on which is promising. There is a couple of bugs it seem in the process, the OMAP_ENHANCEMENT did get set as CFLAGS for a couple of headers which is weird ( aren't all bugs a bit weird? :) ),

A temporary patch is to remove the conditional check for OMAP_ENHANCEMENT as that's what we're building :)

Short one today!!! I'll save my crazy ramblings for the weekend! :)
[Gen9 Android Development] N0ctrnl:
I'll admit I understand a fair amount of this, but am nowhere near tackling any of it myself. As such, I really appreciate you doing it. I can imagine how you must feel talking to yourself on this thread as much as you do, but I know I truly appreciate it, and I'm sure many others do also.

I just thought I'd let you know that we're all rooting for you. :)
[Gen9 Android Development] trevd:
Now then Hackfans!

I've attached a new initramfs to this post although it called initramfs.cpio.gz it is actually initramfs.cpio.lzo, I just couldn't be bothered the F**K about with hotfile. So whats new in initramfs?

1. Well Defined Init files for each bootmode

As I was moving forward with my JellyBean Port I noticed that there was a certain amount of "leakage" from the Standard boot into the recovery, e.g unnecessary properties being set, It was all starting to get a little bit hacky. Not too much of a problem however as the answer was there all the time. we now can use init.recovery.rc for recovery mode and init.android.rc for noraml boot the init.rc file only includes one line, "import init.${persist.sys.bootmode}.rc", the normal init.rc can store settings and services which are common between the 2, but my personal preference leave the init.rc empty

2. checkfs - binary which automatically creates the file system layout this is run before anything else in recovery. It is written In C and writes directly to the framebuffer. From a technical standpoint I can probably name 2 o3 different and better ways of implementing this same functionality but I indulged myself :D as I wanted to do some code which addresses this low level graphic access. checkfs has been added to the ti_archos

device tree repo on my github, If you already have partitions images setup named DATA, SYS and CAC then checkfs will not do anything. It's an early version and needs more work to handle exceptions

WARNING: You Need at least more than 3GB free for checkfs to complete. Unexpected things could happen if you don't have the required space available.

3. Recovery Mode adb shell fixed.

I modified adb to load /sbin/sh when booted into recovery as the /system/bin/sh is not always available

That's about It. I'm going to smash some sleeping in now and dream of jellybean.

As a side note I managed to destroy my OS Install yesterday, No real hassle, only takes about half an hour to be back in buisiness. It did gave me a chance to upgrade to 12.10 (L)ubuntu for this round, I also have got my AOSP code building by not following googles advice on what packages to install. I've totally avoided installing any *:i386 packages, which has cause me conflicts in the past :good:
[Gen9 Android Development] julle131:
I'd install 12.04, because Boot2Gecko(Firefox OS) recommends it for building. 12.10 is not recommended because it has gcc4.7.

Are you coding this everyday? There are so many updates :D
[Gen9 Android Development] trevd:
I'm normally very big on recommended instructions especially too get started but as with most tech related things once you understand WHY you're doing something then WHAT you do can be remixed and reapplied. The fun thing about linux is there well over 9000 ways of doing getting a Job and If I don't find one that suitable I could always write it myself. :D

Pretty much.... That or sleeping!! IRL I'm a freelance Software Development Consultant but I decided to take time out to re-skill in the ways of the Android Platform and Linux....... So It's kind of Work but Not :D. Unless You've got an Address I can send an invoice too? :D
[Gen9 Android Development] trevd:
Hi Folks

Here's a quick updating script to self update the initramfs, you'll need to copy a kernel to ._/kernel ( mounted at /data on normal installs ), I created a script called sbin/update_ramdisk.

#!/sbin/sh
echo "Update Ramdisk"
echo "cleanup previous attempts"
rm -r /tmp/boot
sleep 2
mkdir -p /tmp/boot
mkdir -p /tmp/boot/ramdisk
echo "Copying Kernel"
cp -v /._/kernel /tmp/boot/kernel
echo "Making Standard Ramdisk Structure"
mkdir -p /tmp/boot/ramdisk/data
mkdir -p /tmp/boot/ramdisk/dev
mkdir -p /tmp/boot/ramdisk/proc
mkdir -p /tmp/boot/ramdisk/sbin
mkdir -p /tmp/boot/ramdisk/sys
mkdir -p /tmp/boot/ramdisk/system
echo "Copying sbin"
date > /tmp/boot/ramdisk/created
cp -Rv /sbin/* /tmp/boot/ramdisk/sbin
echo "Copying root files"
cp -v /* /tmp/boot/ramdisk
cd /tmp/boot/ramdisk
echo "creating ramdisk"
find . | cpio -o -H newc | lzop > ../initramfs.cpio.lzo
sleep 2
echo "cleaning up"
rm -r /tmp/boot/ramdisk
echo "backing up ramfs just incase we jaffed it"
cp /tmp/boot/initramfs.cpio.lzo /._/initramfs.cpio.lzo
echo "flashing....."
kd_flasher -k/tmp/boot/kernel -i/tmp/boot/initramfs.cpio.lzo

This allows you to make and persist changes to the rootfs and reflash them back to the SDE.

More Soon! Hack On!
[Gen9 Android Development] Quinny899:
Hey trevd,

I installed it to test using it to flash my ROM on, but I'm getting the black screen on boot issue. How would I go about getting into sde normally? When I try to boot normal Android it bootloops because I'm using the CM10 data. However, it's also not working via ADB and so I can't get anywhere. I did have recovery working, and I can do again, but do I have to flash a ROM from there for it to get around the black screen?
[Gen9 Android Development] trevd:
Hi Quinny,

From what I recall you need to run "adb reboot android" this will attempt to boot the android side of the SDE

"adb shell reboot_into android" will set the boot mode to archos android

"adb shell reboot_into recovery" will set the boot mode to archos recovery

after issuing reboot_into you need to follow that up with a normal adb reboot

There's obviously "adb reboot recovery" which will reboot it into SDE recovery from SDE Android Mode

If you want to go from stock to SDE recovery, you need temp-root on stock and run the following

adb shell reboot_into -s sde
adb reboot recovery

Technically what happens is when you press reboot in recovery nothing is written to the scratch ram so when the tablet reboots it doesn't know what mode to use, that why you have to explicitly "tell it" what mode you want. The bootmode enabled kernel sources on my github have been fixed. Perhaps building yourself a new kernel might be your best bet If you hacking around on it.

As you might know I bricked my tab :( which is a little disappointing because I did miles more work than what is here and had even ported surdu's Clean and Fast Rom to the new structure, plus I had wrapped to bootmode up the handle normal kernels not just my special build.

So the whole thing was/is pretty much done although it might need a bit of polish.

Jigging the Roms about was quite straight so If you're interested In picking this up I'll be able to give you some pointers at least.
[Gen9 Android Development] Quinny899:
Can you give me the info on the structure then please?

adb shell is useless in recovery and so can't tell me the mount points either, so that's a bit annoying.
[Gen9 Android Development] trevd:
are you getting a message like "cannot find /system/bin/sh" ? if you are, there's a cheeky trick you can do

adb pull /sbin/busybox
chmod +x busybox
adb push busybox /system/bin/sh
adb shell

I'm using linux, you can probably leave out chmod if you're on windows unless you've got cygwin :confused:

That should give you a working shell...

The last thing I was doing with it was using a partitioned external sdcard instead the loop mounted ext4 images but obviously that's not a solution for everyone!

I've attached a couple of files for you, The zImage+ramdisk-prefb.7z one looks like the one which uses the modified structure, I've also attached a clean initramfs.cpio.lzo which was the base files I was using which contains the recovery. adb should work on both of them.

To Jig an existing rom.

You can remove /bin /usr /sbin /home without any issues you can remove the contents of /lib but not the /lib/firmware or /lib/modules

That gets rid of the uclibc emedded linux system that archos have on there. You then move /lib/firmware to /system/etc/firmware and /lib/modules to /system/lib/modules

Finally you move the rc files in /etc/init/ into the ramdisk, That's where the fun begins . :laugh:

You need to remove any service references in the *.rc files that point to /usr as these

Finally symlink /system/etc/firmware back to /lib/firmware /system/lib/modules /lib/modules as that's were the kernel looks for the wifi and bluetooth firmwares etc. We do that last bit becuase if we just left /lib intact it wouldn't fit into the initramfs. This pretty much setups up the rom as google intended the layout to be.

After that it's a case of setting up your partitions however you want to ( loop mounted / external sd card )

The *.rc files in the ramdisk contained within zImage+ramdisk-prefb.7z should make things clearer and bascially implements what I've briefly outlined above. Once you get a feel for it , it's a piece of p**s to hack a rom about any which way you choose.

It's clearly also a piece of p**s to remove your bootloader when your not concentrating fully LOL, but meh!!
[Gen9 Android Development] Quinny899:
The error I get is that the device has no adb permissions, it shows up as

?????????? no permissions

in adb devices

---------- Post added at 05:47 PM ---------- Previous post was at 05:43 PM ----------

adb shell doesn't let me in either

---------- Post added at 06:37 PM ---------- Previous post was at 05:47 PM ----------

Also, I'm getting error 0, apparently down to the updater-binary. Which should I be using?
[Sony Xperia T, TL, TX, V] peetr_:
When I bought Xperia T, after a while, I started to be a little disappointed with performance, autobrightness, discharging when playing, etc.

After some digging deeper into this problem, I have found, that cpu is throttled by temperature. And not only the cpu.

A few minutes of playing game, cpu goes to 800MHz, display brightness goes to level 100 (max. is 255), wall charger current is reduced (even when connected, it is discharging), radio power is reduced, etc.

Change it yourself:

Example:

xo_therm 14 -1000 380 20 NOTIFY CAM_NORMAL cpu_perflevel:1728000 charge_current_limit:0 usb_current_limit:1 modem_level0 lcd_brightnesslevel:240

xo_therm 14 = sensor step

-1000 = -100,0°C

380 = 38,0°C

20 = don't know (maybe some kind of sample rate?)

NOTIFY CAM_NORMAL = obvious (camera)

cpu_perflevel:1728000 = cpu frequency

charge_current_limit:0 = obvious (0 is 1300mA I think, 1 is 1100mA, 2 is 900mA, etc.)

usb_current_limit:1 = obvious (has impact on charging too)

modem_level0 = power of modem

lcd_brightnesslevel:240 = obvious (0 - 255)

Set the highest temperatures, with low enough frequencies and charging current values, to let phone cool down.

"gpu_perflevel" can be used too and there are some other thermal sensors in sysmon.cfg, which are also responsible for thermal throttling.

Disclaimer:

Each device is different and I am not responsible, if your device burns with some values from here.

Both CPU cores always on:

Echo 1 in /sys/devices/system/cpu/cpu1/online and change permissions to 444. And if you want to prevent errors from log (and maybe some unwanted wake locks), rename /system/bin/mpdecision to something else or delete it.
[Sony Xperia T, TL, TX, V] Id Arcanum:
what is temp at what cpu throttles (and other things)?

seems it is lower than other devices, something like 40C, i think my sgs3s was at 76C or similar.. not sure, will check later.

sgs3 was a very hot phone.

Sent from my Xperia T
[Sony Xperia T, TL, TX, V] peetr_:
You can see the temperatures in sysmon.cfg - xo_therm 400 500 = 40 - 50°C for example. Cpu temperature, not battery. There is no tool to monitor cpu temperature, but if you set your own frequencies, you can see with Cool Tool, how long it takes to the lowest frequency.
[Sony Xperia T, TL, TX, V] Id Arcanum:
thanks, will check. i am on cm10 and didn't notice throttling yet, but i will check now as it is ****ty if so.

Sent from my Xperia T
[Sony Xperia T, TL, TX, V] LegibleEel:
I have noticed the throttling but it doesn't affect the performance in my case, playing games and watching HD video are fine, just annoying when the screen suddenly does dim.
[Sony Xperia T, TL, TX, V] realfelix:
@OP:

If you don't want throttling, uninstall Androids inbuilt Thermal monitor(No need to tell you the risk by doing that I guess).
[Sony Xperia T, TL, TX, V] peetr_:
Thanks for you valuable advice.
[Sony Xperia T, TL, TX, V] Id Arcanum:
Don't think it would help as that file says 2nd core off values are hardcoded
[Sony Xperia T, TL, TX, V] peetr_:
I think, that it works, because I tested it and I am using my own values. ;)
[Sony Xperia T, TL, TX, V] TimAhKin:
Good thing I won't be playing games when my T will arrive :)
[Sony Xperia T, TL, TX, V] Haldi4803:
https://developer.qualcomm.com/mobile-development/development-devices/trepn-profiler

Still? Damn how long do they take ? -.-

Here is the .apk of the old version. No idea how much works and what doesn't!
[Sony Xperia T, TL, TX, V] nickola:
Hello,

Could it be some kind of default on your device ? or maybe the application ?

Cause I remember Qualcomm's communicating on their S4 being "cooler" than its opponents when under heavy load.

Can someone else confirm ?

What's strange is that the game you mention (Osmos HD, which I bought some time ago for my TF101) does not even use super high end 3D graphics etc etc ... maybe the perf drop could come much quicker with some cpu/gpu intensive apps.

If confirmed, it might even become a big "no go" on this phone for me.

Nickola
[Sony Xperia T, TL, TX, V] LegibleEel:
I've had this phone for a while now and I haven't had a bit of lag while playing any game I have. Everything seems fine except the sudden dimming of the screen when playing games. Don't let this put you off buying the phone, its a great phone :D

Edit: been playing Osmos HD for at least 25 minutes, I'm experiencing no such lag or performance issue. Only the dimming issue I seem to get.
[Sony Xperia T, TL, TX, V] peetr_:
Well, after some more investigation, I have found, that lags in Osmos HD are not caused by cpu throttling, but wifi disconnecting.

Playing the game is fine, but still, with default settings the temperature is going high and except the screen dimming, cpu goes to 800MHz, (1 core disabled on highest temperature), and phone is discharging even when connected to wall charger.

It seems to me, that the overheating is not caused that much by cpu, but gpu. It would be nice, if it could be tested somehow by lowering the frequency of gpu.
[Sony Xperia T, TL, TX, V] Snow_fox:
I wonder if the heating issues could be fixed with software patches. Given Sony's desire to incorporate playstation stuff, I find it hard to believe there is some sort of hardware issue.

Wish we could get some more samples to work with.
[Sony Xperia T, TL, TX, V] peetr_:
Just measured with my settings (in the room - about 23°C):

10 minutes of playing Osmos HD without charging = 62°C CPU temp

With one core running on 1350 MHz and LCD brightness value 150, it's not increasing anymore.

When charging, the temperature will go higher. I will test it too.
[Sony Xperia T, TL, TX, V] Haldi4803:
Have you tried treppn profiler?

Anandtech says a CPU core draws around 450-750mW while gpu goes 800-1200mW!

Seems like 400mhz is a hard Task for an 225.
[Sony Xperia T, TL, TX, V] Snow_fox:
If you are still on ics maybe try jellybean? Perhaps project butter may more efficiently handle the gpu.

Maybe even make a list of "stress test" for people to try and see what the various results are.

If all else fails try undervolting the gpu and cpu.
[Sony Xperia T, TL, TX, V] peetr_:
Yes, I tried trpn profiler provided by you, but there are limited options.

It looks like the GPU cannot handle this frequency.

Undervolting won't help anything, but lowering GPU frequency would help I guess. But this cannot be done without custom kernel, allowing this.
[Sony Xperia T, TL, TX, V] emuX:
Same here. I've been playing Speedball 2 and GTA3 mainly but I have played a few others too and haven't experienced any lag and no performance issues observed at all.
[AT&T, Rogers, Bell, Telus Samsung Galaxy S III] cyphr-6:
I just bought a SGS3 today, and I used this guide to root and install recovery

theunlockr[DOT]com/2012/07/19/how-to-root-and-install-clockworkmod-recovery-on-att-galaxy-s3/

I'm thinking now that this was a big no-no.

I downloaded the latest CM10 nightly and the respective gapps.zip, however when I boot into recovery and try to install it, it tells me this:

-- Installing: /sdcard/cm-10-20121014-NIGHTLY-d2att.zip
Finding update package...
Opening update package...
Installing update...
assert failed: getprop("ro.product.device") == "d2att" || getprop("ro.build.product") == "d2att"
E:Error in /sdcard/cm-10-20121014-NIGHTLY-d2att.zip
(Status 7)
Installation aborted.

I have already (stupidly) factory reset/wiped and formatted cache. What can I do?

Thanks in advance for any help.