" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Great work! With this base, can yout get something like CW to run?
I'm so waiting for him to come back and say April fools.
I'm gonna screw him up if this was an april fool
First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?
vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.
)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.
Don't know alot about the bootloader, but what advantage does this have?
SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.
He said root with r/w access. Archangel won't do that, the file system is still protected.
pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.
Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.
Related
I want to try developing for the DSTL1 / N21
There are quite a few interesting things we can do...
Success has been been seen by xda-devs such as JesusFreke, Amon_RA, Haykuro, and Cyanogen (yes there others) in the field of Android ROMs. The ground work is there, porting and developing can commence.
Why do this?
Current ROM 1.5 - has many problems...
Unofficial ROM 1.6 - is a GREAT improvement, but makes one hungry for something better...
It would be awesome to have some success in this field. I know this device is capable of so much more, but I believe the implementation of the system is the issue. This is not the phone developers fault, as they have their own company agenda, but we could improve our own performance and satisfaction .
For example, my device (1.6 rooted) lags with having only ~50% CPU utilization and ~50MB RAM free...
Overclocking (i mean forcing full CPU capacity - 624Mhz) the CPU has barely helped and only aided battery drain...
Relevant comparison of G1 vs DSTL1 (N21) are
RAM - G1: 192MB vs DSTL1: 128MB
CPU - G1: 528Mhz vs DSTL1: 624Mhz
These specification comparisons say that G1 can run a better ROM than DSTL1? I don't think so. DSTL1 only loses in RAM, which can be made up for using swap!
Devs had success with techniques using: App2SD, swap, ext3, and BFS (faster file system). I believe we could do something impressive here! There are pros and cons to this.
Developers and Testers would be needed. A team of 5 developers and a few testers should be able to get us on the right track. We would definitely need Linux experience, or the desire and ability to soak up all the info on Google
A Linux kernel is a must for this phone, we would have to compile our own... It would be nice to preserve DUAL SIM, but in reality we might have to give up this luxury, as it is proprietary code, unless a new ROM is made backwards compatible (which is possible).
Cyanogen's Github is available for knowledge osmosis http://github.com/cyanogen
A DSTL1 Recovery by Amon_RA (based on Cyanogen's Recovery) is already in Beta...
Cool things are possible. Could I find some developers willing to donate their free time?
Please limit responses to dev talk.
reserved for later
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
chrismotto said:
crzyruski,
Believe it or not the very luxury you talk about giving up(dual sim) is the reason why may of us bother to buy these phones(DSTL1\N21) in the first place. Other wise we might as well go with a mainstream phone such as hero etc.
Click to expand...
Click to collapse
Its a possibility that I'm not going to ignore, so I stated it.
The point is that the current OS is lacking. Initially we would want to port and learn from porting of the quality ROMs available now. Those obviously don't support dual-SIM.
Progress needs to start from somewhere. When someone releases a new port or ROM not all pieces work... look at the Eclair (2.0) port, half the features don't work!
If enough heads came together we could probably retain dual-SIM, common this is linux and I've seen the most amazing development come to realization. I just need the teamwork because it might take me a whole year in my spare time...
Having a kernel working
Hi,
the most important IMHO is having a kernel working, built from sources.
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
My first attempt of booting with a custom kernel was unsucessfull (black screen), which brings to the second point: the lack of some sort of console for kernel debuging.
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Any idea also regarding kernel debugging in the N21/DSTL1?
sfabris
@sfabris
I will try to find info for the questions you have.
My initial work will be to make an emulator so we can test on PC and not our devices (because we need them functional for every day life )
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
sfabris said:
Obviously, some closed source drivers must be rewritten, notably the NXP5209 (the GSM modem), if we want the device to be useful (i.e. if we want to make phone call).
Any idea regarding the NXP? Anyone is aware of some opensource driver or specs?
Click to expand...
Click to collapse
Maybe we have it all wrong???? Maybe its PNX?
PDA DB reports DSTL1 as having Nexperia PNX5209 (ARM946) Phone Controller.
http://pdadb.net/index.php?m=specs&id=1714&view=1&c=general_mobile_dstl1
A similar Android with this phone controller is WayteQ X-Phone (TechFaith Lancer)
http://pdadb.net/index.php?m=specs&id=1801&view=1&c=wayteq_x-phone_android_techfaith_lancer
crzyruski said:
@sfabris
Have you checked out how other modders have done kernel modifications?
Namely JF and Cyanogen?
I can't begin to comprehend so I'm glad you took the initiative with this.
Lets make some progress
Click to expand...
Click to collapse
As I'm forced to HTC G1 until I'll wait the replacement for my N21 I'll go in detail on the kernel boot process on other hardware.
A fast way to test kernel in our every day device is kexec which should work also on ARM.
sfabris said:
A fast way to test kernel in our every day device is kexec which should work also on ARM.
Click to expand...
Click to collapse
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
crzyruski said:
As far as I understand, kexec is a program that can run a new kernel on the fly...
So I could try a new kernel right from my device without reflashing?
have you tried this? Or is this still theory?
Click to expand...
Click to collapse
I've tried it on x86, never on arm.
Support is there also for arm, but this not imply that also the Marvell PXA is supported.
It's basically the same way of booting Android from WM via haret.
Fastest way to boot your new kernel or to crash your machine
I have created an emulator.
FYI, LCD density should be 120.
Edit: Technically the density is 133...
files prevent recovery-RA-DSTL1-v1.2.3 from loading
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
is there any ways to update the firmware of N21
hi,
i'm just buy a sciphone n21 (actually is already in our office for 2 weeks but find it now:-( )
and i've to face myself in a situation that i can't use this phone:-( since i buy this phone because:
- i assume that google apps auto sync contact and calendars. unfortunately this phone has not google apps by default.
- and has dual sim support.
so my question: is there any way to upgrade it to a firmware which support is?
can i do anything to use my phone?
thanks in advance.
regards.
crzyruski said:
I have been wrestling with the beta recovery-RA-DSTL1-v1.2.3
Amon_RA retrofitted his own recovery image to work for the DSTL1 (N21)...
IT HAS AWESOME POTENTIAL.
Currently ADB RECOVERY SHELL + ROOT is the only thing that is functional.
But I haven't been able to get in touch with him to continue work on it.
The following files prevent me from booting into RA's Recovery, so I remove them:
- e2fsck
- mke2fs
- parted
- tune2fs
Once I am in ADB RECOVERY SHELL I can push them back on and do what I need to do.
Unfortunately the changes are persistent so if I were to reboot and try Recovery Mode again, it won't load
What is so special about those four programs that prevent my recovery from loading?????
Click to expand...
Click to collapse
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
andferno said:
e2fsck is a filesystem check utility for ext2
mke2fs is for ext2 filesystem creation
parted is a partitioning tool
tune2fs is for change some filesystem parameters (usually checking interval)
I've read that recovery from Amon-Ra creates automatically 3 partitions (ext2, swap and FAT32). So those commands whould probably mean ext2 filesystem creation. I'm sure Amon-Ra could give us more information on this subject because he added them to the image.
Have you checked your SD card?.
PD: I'm waiting for my N21 . So I can't test yet.
Click to expand...
Click to collapse
Thank you for that insight.
I am not sure what RA's recovery would have done on its own...
but I have initiated and completed successfully a partition of my SDCard that includes FAT32, swap, and ext2.
Now that I have done this, for experimentation really, I don't know how to use it and what it gives me.
Obviously the swap is useless because I would need a cooked Android ROM that would actually utilize swap.
ext2 is probably for apps2sd... which I tried unsuccessfully - probably because of my own mistake.
I will continue trying and report again later.
As far as Amon_RA, he mentioned he was working on upgrading all the recovery images he has put out to the next version - thus we will be in queue until this comes to pass. Maybe we can just skip this version and go to the next
N21 vs DSTL1: stock comparisons
I have completed the comparison of recovery images of the DSTL1 and N21.
For this test I used an original mtd2.img from my DSTL1 and an original mtd2.img from Slemmen's N21.
The recovery images are identical:
Both mt2.img are 4,194,304 bytes
Both mtd2.img-kernel are 2,141,616 bytes
Both mtd2.img-ramdisk.gz are 386,645 bytes
What is also interesting to note is that the two boot images i inspected were also identical.
The DSTL1 boot image is one that came with the 1502 update from General Mobile (which may or may not be identical to the original).
The original N21 boot image, thanks to ikarishinjisan, is identical to the DSTL1 boot image:
Both mt1.img are 4,194,304 bytes
Both mtd1.img-kernel are 2,141,816 bytes
Both mtd1.img-ramdisk.gz are 148,671 bytes
*Notice how both recovery and boot are the same size... must be padded?
*Notice how boot kernel is 200 bytes more than recovery kernel.... interesting...
On a side note:
Bootloader is identical as expected: both ikarishinjisan's and my mtd0.img are 1,048,576 bytes.
If things are going to go custom, it might make some sense to put ext3 filesystems on these things.. ext3 is just ext2 with journalling, which could be helpful since phones can just die/get dropped/lose connection with battery/whatever.
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
dnfm said:
Also, this can be done with the tools already there..
mkfs.ext2
tune2fs -j
Click to expand...
Click to collapse
Are you referring to the Amon_RA's custom recovery?
I can't get tune2fs onto the recovery without trickery, definitely not noob friendly... until we figure out why.
But great suggestion
I'm guessing the ROM must be coded to make use of ext3, otherwise its worthless?
The kernel would need to be configured to support ext3.
Given the law about releasing the source for their OS implementation, I.e. kernel and hardware drivers, when do we expect to have the 2.1 source, giving us a feel for the 2.2 implementation? Should have released the 2.1 by now for the 70 and 101....
EDIT: Looks like Android 2.2.1 (Firmware 2.0.54) was released Nov 30, 2010 - so we should expect to see the source for it by the end of this year.
EDIT: Looks like the source has been released - http://www.archos.com/support/download/software/sources/gen8-gpl-froyo.tgz
Now we need someone with good Linux abilities to start helping us compile a custom kernel.....
Sent with my fingertips and voice on my Evo
no custom kernel till we get rooted for the phone...once we get rooted we can do watever to it..im gonna have me a ball with this once we do...lmao
txtmikhail said:
no custom kernel till we get rooted for the phone...once we get rooted we can do watever to it..im gonna have me a ball with this once we do...lmao
Click to expand...
Click to collapse
So does the SDE not look attractive? We have root that way and can do kernels and such....
But I would rather have FULL root (NAND unlocked like we do with HTC phones) enabling us to fully take over the device - instead of essentially a dual boot environment that leaves the stock build on the device and takes up space....
There seem to be some people who think we can't unlock NAND - and don't see why we would want to.
Sent with my fingertips and voice on my Evo
jerdog said:
So does the SDE not look attractive? We have root that way and can do kernels and such....
But I would rather have FULL root (NAND unlocked like we do with HTC phones) enabling us to fully take over the device - instead of essentially a dual boot environment that leaves the stock build on the device and takes up space....
There seem to be some people who think we can't unlock NAND - and don't see why we would want to.
Sent with my fingertips and voice on my Evo
Click to expand...
Click to collapse
i dont know much about the SDE but i know i dont want to install it. with a lil work and time i think we can get this thing fully rooted .. The kernel
is most important to me cuz this thing needs to be overclocked to atleast 1.2ghz..
you don't want to fully root and reformat everything and may brick your device. it's just not worth it.
use the SDE: install custom kernel and if your satisfied remove default kernel and it will boot only custom kernel (until you install any archos firmware again)
with SDE you can use full internal storage (kernel is stored in another very little flash chip: /dev/mmcblk0, mmcblk1 = internal storage, mmcblk2 = sdcard), reformat it and install and do whatever you want. if you're not satisfied, start in recovery mode reformat the device and start all over again or install the archos firmware again. no real chance to brick your device.
why would anyone try to brick his device if he has full device access for free?
@topic building custom kernel and cross compile some linux libraries is quite easy, I'll post an HowTo and some shell scripts today or tomorrow, ok?
I want full root to do wat I want..I have a epic 4g wit root and a custom rom..one ...I don't need to boot up wit dual boot for the same os...
Sent from my A101IT using the XDA mobile application powered by Tapatalk
chulri said:
you don't want to fully root and reformat everything and may brick your device. it's just not worth it.
use the SDE: install custom kernel and if your satisfied remove default kernel and it will boot only custom kernel (until you install any archos firmware again)
with SDE you can use full internal storage (kernel is stored in another very little flash chip: /dev/mmcblk0, mmcblk1 = internal storage, mmcblk2 = sdcard), reformat it and install and do whatever you want. if you're not satisfied, start in recovery mode reformat the device and start all over again or install the archos firmware again. no real chance to brick your device.
why would anyone try to brick his device if he has full device access for free?
@topic building custom kernel and cross compile some linux libraries is quite easy, I'll post an HowTo and some shell scripts today or tomorrow, ok?
Click to expand...
Click to collapse
Once we get root and a recovery image installed bricking the device is pretty hard to do. I seriously haven't heard of any people bricking their phones (other then people flashing different radios - gsm for cdma and vice versa). Rooting and making a 100% ASOP rom would kick ass. Not sure what archos was thinking for making it impossible to root. dumb decision. fail
how would you install a recovery image to a bricked Gen8 device??
there is no need for dual boot but an option in the recovery menu called something like "remove android kernel" which removes the default kernel so the device boots custom kernel only, no dual boot if you don't want it.
You have full root access with SDE, tell me what you can't do with SDE?
SDE = recovery bootloader --> nearly unbrickable device
chulri said:
you don't want to fully root and reformat everything and may brick your device. it's just not worth it.
use the SDE: install custom kernel and if your satisfied remove default kernel and it will boot only custom kernel (until you install any archos firmware again)
with SDE you can use full internal storage (kernel is stored in another very little flash chip: /dev/mmcblk0, mmcblk1 = internal storage, mmcblk2 = sdcard), reformat it and install and do whatever you want. if you're not satisfied, start in recovery mode reformat the device and start all over again or install the archos firmware again. no real chance to brick your device.
why would anyone try to brick his device if he has full device access for free?
@topic building custom kernel and cross compile some linux libraries is quite easy, I'll post an HowTo and some shell scripts today or tomorrow, ok?
Click to expand...
Click to collapse
A HowTo on this device would be great. Thanks!
As to custom ROMs, etc. - I echo other comments above. I have never had anyone truly brick their device doing custom ROMs - I work at a carrier and have not seen a truly bricked device that couldn't be undone with a custom recovery and/or reflash back to stock and locking NAND again and noone is the wiser. We can put together custom kernels all we want, but a lot of the holdup in devices is the bloatware that the manufacturers put in - and a lot of it is behind the scene in the frameworks. Just doing a custom kernel is great - but to unleash the real potential of the device is to remove all the unnecessary options and software and libraries that are not needed.
Not sure who all here has dealt with Android phones and the custom/AOSP/CM environment, but going to AOSP (or CM) without all the manufacturer bloat and only including the necessary drivers and such will show you how much of a performance boost and unending promise a device truly has. The possibilities are endless.
THAT is why we desire to have NAND unlocked and the ability to move this device to take full advantage of it's hardware.
HowTo is online: [HOWTO] Build custom kernel, libraries and applications on your own
jerdog said:
We can put together custom kernels all we want, but a lot of the holdup in devices is the bloatware that the manufacturers put in - and a lot of it is behind the scene in the frameworks. Just doing a custom kernel is great - but to unleash the real potential of the device is to remove all the unnecessary options and software and libraries that are not needed.
Click to expand...
Click to collapse
you can replace the whole operating system, archos ships per default some buggy angstrom linux with SDE. maybe someone is able to put ubuntu or windows phone 7 onto it if he is crazy enough
jerdog said:
THAT is why we desire to have NAND unlocked and the ability to move this device to take full advantage of it's hardware.
Click to expand...
Click to collapse
What do you mean with NAND? The Internal Storage (A101IT - 8 or 16 GB) or the flash chip where the kernels and the default android OS are stored?
eitherway, both are NOT locked. you can remove and replace the (signed by archos) squashfs from /dev/mmcblk0p2 and put your own android or any other operating system in it. or reformat /dev/mmcblk1 (internal storage -> 8 / 16 GB) and install your own operating system (e.g. some stripped ubuntu)
Gen8 devices aren't locked. Install SDE und you can do whatever you want with only little possibility of permanently brick it. you always can reinstall the archos firmware to restore default android OS
I'm looking forward to a clean/vanilla 2.2 rom with all bloat removed!
chulri said:
What do you mean with NAND? The Internal Storage (A101IT - 8 or 16 GB) or the flash chip where the kernels and the default android OS are stored?
eitherway, both are NOT locked. you can remove and replace the (signed by archos) squashfs from /dev/mmcblk0p2 and put your own android or any other operating system in it. or reformat /dev/mmcblk1 (internal storage -> 8 / 16 GB) and install your own operating system (e.g. some stripped ubuntu)
Gen8 devices aren't locked. Install SDE und you can do whatever you want with only little possibility of permanently brick it. you always can reinstall the archos firmware to restore default android OS
Click to expand...
Click to collapse
NAND refers to the flash chip where Archos (and all other manufacturers) put their system files.
When you delete something from the Archos OS (i.e. /system) and then reboot, does it show back up or is it permanently removed? Are you able to remove ALL traces of Archos' stock Android implementation?
jerdog said:
When you delete something from the Archos OS (i.e. /system) and then reboot, does it show back up or is it permanently removed? Are you able to remove ALL traces of Archos' stock Android implementation?
Click to expand...
Click to collapse
yes you are.
install SDE
boot up the shipped angstrom linux
mount /dev/mmcblk0p2 and remove the androidmerged.squasfs.secure file inside
reboot to recovery mode and "uninstall android kernel"
reboot
without the default archos android kernel it boots always to the custom kernel (default: angstrom linux, but can be replaced with any other OS)
now you have a gen8 device without any archos android os and can use for whatever you want it
if you want it back to normal: recovery mode -> reformat device & install archos android firmware
chulri said:
yes you are.
install SDE
boot up the shipped angstrom linux
mount /dev/mmcblk0p2 and remove the androidmerged.squasfs.secure file inside
reboot to recovery mode and "uninstall android kernel"
reboot
without the default archos android kernel it boots always to the custom kernel (default: angstrom linux, but can be replaced with any other OS)
now you have a gen8 device without any archos android os and can use for whatever you want it
if you want it back to normal: recovery mode -> reformat device & install archos android firmware
Click to expand...
Click to collapse
Aren't you just removing the kernel and putting your own in? The partition with the actual system still exists though, correct?
What it seems to me, is that Archos has given the ability to use your own kernel with their /system still in place - but this doesn't give the ability to install a completely vanilla system (ala AOSP and/or CM) or to strip out the bloatware and modify the existing frameworks....
I hate to repeat myself.. ( is my english really that bad? )
You DON'T replace the kernel, you install just another one (called custom kernel).
You CAN remove the archos' kernel (but you don't have to)
You CAN remove the archos' android filesystem (location: /dev/mmcblk0p2 -> androidmerged.squashfs.secure)
You have WRITE ACCESS to all flash devices (/dev/mmcblk[0-2])
When you install SDE it ships a vanilla angstrom linux, this has nothing to do with android and shows that you are ABLE TO INSTALL A COMPLETELY VANILLA SYSTEM (even side by side with archos' android if you want to)
chulri, I think you're missing the point. He wants the entire system opened up. Even though you can use SDE to write to any of the flash devices, can you use it to remove a single App from the existing android setup?
They (and I actually) are wanting a custom recoery (something ALA Clockworkmod would work fine for me), and have full access to the internal nand, so they can flash a completely custom ROM, or a pre-rooted factory rom, etc. They want this WITHOUT having to use SDE. With the squashfs secured like it is now, this makes it a bit more difficult to get what we're wanting... If we have a full system rom that's not secure like the existing one, then any app could be removed, upgraded, or themed however you want.
If you don't already own a rooted android phone, then I don't think you really understand the WHY of what they are asking for.
and again...
you can install whatever you want, and even if it is a customizied archos android
the squashfs is not encrypted, you can unpack, copy and replace it with an unsigned squashfs image or even another filesystem, install a custom kernel which ignores the signature (change one or two lines in initramfs.cpio.gz) and there you go...
why do you need another recovery image when you have SDE? it IS a recovery image..
chulri said:
and again...
you can install whatever you want, and even if it is a customizied archos android
the squashfs is not encrypted, you can unpack, copy and replace it with an unsigned squashfs image or even another filesystem, install a custom kernel which ignores the signature (change one or two lines in initramfs.cpio.gz) and there you go...
why do you need another recovery image when you have SDE? it IS a recovery image..
Click to expand...
Click to collapse
I had thought the squashfs image was secured, which it's good to know it's not.
As for the custom recovery, it's more of a personal preference. Most people would rather have some sort of AOSP rom installed on their system, with none of the custom Archos stuff on it, no dual-booting, etc. And while it may be your opinion that it's not necessary, people want it. Being condescending whenever people request it or even ask about it doesn't help at all (all the , or is my english that bad, etc).
I use clockworkmod on my Incredible, and it's never once told me i had to have my device plugged into power to flash something, but I'm stuck at work right now with my Archos telling me that to flash my system with their SDE I have to have it plugged into the power adapter (even though I have 100% battery). That alone to me (again, TO ME) is justification for a seperate custom recovery...
after you have installed the sde you don't have to plug in power to flash custom kernels
anyway: only because some people want some own recovery image, go ahead, hack the sh!t out of gen8 and may brick it but for god sake don't tell the world you couldn't do the same with SDE and claim about the bad bad fail fail company not letting some stupid users brick their devices the ones who know how still can do whatever they want, with or without SDE. the ones who doesn't.. um.. nevermind
Can you dual boot or any other way to have 2 different roms installed at the same time,so i can switch back and forth?Like windows either at boot or logging in and out of 2 different desktops.
Maybe find a way to split the partitions.Any suggestions would be great.
Duel= 2 roms fighting. Make it dual. Thought it was funny, no malice intended.
lol - duel - dual...
It would be interesting if that was possible. There would have to be another program in there to act as the buffer between both OS's though - that would take control of the start-up, hold on a page that has both options and then would boot the option you want.
Not sure if that's possible since some files are right on the root and in order to have an OS work it can't have files in the same directory - they would just overwrite each other.
But, I too, have wondered if it would ever happen. Be a great way to test new ROM's if you didn't always have to overwrite the existing ROM but rather, you could place a new ROM in a special directory and then run it from that - or partition the internal memory with the new partition available to boot from and store.
partition the internal memory with the new partition available to boot from and store.
Click to expand...
Click to collapse
Thats exactly what i was thinking,partition the system os,i rebuild computers and a little system modding in windows,but this is a linux based os,so it would be a little odd for me.I'm gonna look into this a little more.
You may try to contact the guys who developed boot manager. www.init2winitapps.com they have a listing of supported devices and a request form. Works on the thunderbolt 5 slots for 5 roms, I'm unsure how difficult it would be to add support for the iconia.
Sent from my A500 using XDA Premium App
ibsk8 said:
You may try to contact the guys who developed boot manager. www.init2winitapps.com they have a listing of supported devices and a request form. Works on the thunderbolt 5 slots for 5 roms, I'm unsure how difficult it would be to add support for the iconia.
Sent from my A500 using XDA Premium App
Click to expand...
Click to collapse
Thanks,i submitted the idea,lets see if they will run with it,hopefully they will find interest.
Hello Diabblo,
Any update on that?
I think the idea of dual boot (or 5al boot) is just fantastic!
I have beside my iconia a501 a poor old zt180s and it can triple boot on android, ubuntu and WinCE!
Best,
Inji.
inji75 said:
Hello Diabblo,
Any update on that?
I think the idea of dual boot (or 5al boot) is just fantastic!
I have beside my iconia a501 a poor old zt180s and it can triple boot on android, ubuntu and WinCE!
Best,
Inji.
Click to expand...
Click to collapse
Im guessing that device has a open non encrypted boot loader. The Iconia was encrypted at birth with the 3.2 push they tightened security even more from whqt I have read.So this is likely never happening unless acer changes ttjere boot loader policy.not likely to happen.
hope this helps you understand more of this issue.
I'm dual-booting my A500 right now with ICS and Ubuntu. The method for dual-booting is a replacement recovery.img which contains a Linux kernel and acts as a bootloader for Linux. Ubuntu itself runs from a rootfs.img on the internal storage (there's also recovery.img's available to run from external SD too). If I want to run Android, I just boot my tab normally. When I wanna run Ubuntu, I hold vol+ as I'm turning it on to force the modded recovery to load. It's a pretty cool setup more info in this thread: http://forum.xda-developers.com/showthread.php?t=1158260
Dear Erica Renee and Bloodflame,
Thanks a lot for your answers. Ok, I got it with the encrypted bootloader.
Will try the method described by Bloodflame.
Actually, since I got these tablets my main use of them is flashing new ROMs... I don't really have the use of new ROMs but I think it's so exciting!
Cheers,
Inji.
I don't believe the encryption is the problem.
The current boot loader is available unencrypted in update packages if anyone want to have a look at it.
Replacing the boot loader on the device is done as part of a down grade procedure described elsewhere on this forum.
So unless I'm missing something, the problem is more likely time and interest. Someone need to care enough about it and have the time to make some other boot loader work. Or patch Acer's. Either way it is likely to require quite a bit of time and patience.
So let me see if I have this correct. Acer's hardware bios code is 'locked down' enough to keep the average code manipulator out? A custom boot loader needs to be dev'd that can communicate correctly to be able to handle Android recovery and a linux/android boot screen etc. ? Could someone elaborate more blatantly if I am incorrect...
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
webdawg said:
Where is the BIOS in this thing? I get that it has /boot /system and /recovery but where is the firmware that the device very first utilizes?
Does the streak even have any type of NVRAM memory?
Click to expand...
Click to collapse
What are you attempting to do?
Understanding and Hacking
I am trying to understand the device and search for potential exploit vectors. If I take out the inner SD card what type of data does the device still have on it?
It has to have something that starts the boot from the inner SD card. Does this something insert anything into the running code on the device? Can it?
Can, if the device has the type of storage I am talking about, the device record and store even a small amount of data?
I have heard of reference to NAND backups and even seen a quote about how the NAND backup util included in the recovery utils does not backup something. The something I am referring to is not the external SD card.
Web...
Strephon Alkhalikoi said:
What are you attempting to do?
Click to expand...
Click to collapse
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
TheManii said:
Why would you need exploit vectors when the system is completely open/unprotected?
the innerSD holds the /data and /cache partitions
Click to expand...
Click to collapse
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Okay Then
cdzo72 said:
Unfortunately for you it seems you don't know what you're doing or why you're even asking about it
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Please. Unless you have an answer please do not reply. I know exactly what I am talking about. If the device does not have any NVRAM in it that one could flash to and only internal memory via SD card then just say this.
webdawg said:
It is like I am not making myself clear enough. A computer has a BIOS which passes boot to the OS/bootloader. Would not the phone have the same thing. If you do not know this answer do not ask anymore questions.
Stop asking why I am asking.
Click to expand...
Click to collapse
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Strephon Alkhalikoi said:
Manii knows far more about the Streak than you do, so if you want your questions answered, I suggest you check that attitude of yours at the door.
Click to expand...
Click to collapse
Your right. Did not realize it was him, work has an affect on my attention. Sorry Manni.
I am at home now. Let me try and expain myself.
I just do not get it. All the pages I have read and the research I have done everything tells me that everything is stored on the internal SD card.
But I still have this nagging thought from this page: http://www.rdtk.net/2011/06/25/using-streakmod-recovery/ that says this: the firmwares reside on the nand but in an entirely separate area. only stock recoverys can write to them under normal circumstances, you can probably read/write them manually but it’s dangerous as you can super-brick if you don’t know what you’re doing
What the hell is that guy talking about? The way I read it is that an entire subset of firmware exists on the device that only that one webpage has ever talked about. (That I have read)
I have read alot about BIOS hacks and how they function inserting code into Windows. Even legitimate code for paid services. Computrace.
I know about the Carrier IQ software. What I do not know about is the software outside the rom, recovery, boot partitions and such that exists on the Dell streak or any Android device.
I suppose my attitude comes from the ton of forum posts that I read with unanswered questions because people wanted to know why the OP is asking such a question.
I took Manii's post the wrong way because of your question Steven. Not to offend you and I understand why you ask. For example I just hate going into support channels and asking questions about an iptable rule and being told that I should relearn Linux networking because...well just because I did not understand one concept. I took it the same way here.
I apologize to all.
Web...
MTD based nands are more complicated then eMMC nands in this aspect, as MTD nands you simply cannot read from the 'hidden' portions of the nand. eMMC ones you can.
eMMC devices you can always read from any eMMC partition, so you can likely make complete backups including your modem (though no custom recovery does this by default, it's still a bad idea)
Fortunately for us, MTD seems to be 'obsolete', every device that launched with GB installed or newer uses eMMC.
Dell Streak 5/Partition layout - XDA wiki
Dell Streak Pro/Partition layout - XDA wiki
The S5 is a MTD device, the SPro is eMMC, note how the SPro has many more partitions.
The majority of them also exist on the S5, but the only way to access them (safely) is though a stock recovery.
You can write to them with fastboot, but some of them must be unpacked by an updater in the stock recovery. Simply flash them (specific ones) and you'll super-brick that would require JTAGging at a minimum to fix.
You simply cant read the other MTD partitions without JTAGing (it might be possible with a specificly modified kernal, but you dont gain anything doing this, if at all), assuming that the hidden parts are MTD partitions even. For all we know the controller could be directly writing onto NAND pages with their locs hardcoded (which would kinda be like partitioning, but without the formal partition tables(?) )
There's also is a small amount of memory that can only be written (afaik) via JTAG.
It contains your device's ID, such as Service tag and IMEI.
On tegra devices (at least the S7 and S10) it's the WP1 and WP2 partition.
It could be possible that it's on the NAND as a MTD partition, but if it is we dont know about it. It would be insane (and illegal, as changing your IMEI is illegal in most countries) to write to it, but so there's never been an example of it. I dont know where they are on the SPro, i'd need a live device to check.
The modem OS itself is stored on the nand, the modem processor knows (or the bootloader knows) how to feed it it's OS image.
Location breakdown:
NAND: <everything on the partition layout above, including the below>
/system
/firstboot
boot.img
recovery.img
amss.mbn
appsboot.mbn
dbl.mbn
dsp1.mbn
fsbl.mbn
osbl.mbn
DT.img
The innerSD
/data
/cache
Modem storage (lock state)
Device unique data (IMEI and Service tag)
RTC (the clock)
I dont know the exact terminology or the exact order of booting on qualcomm snapdragons (it's likely to be the same with all at least in the same generation)
But it's something like:
Press power button
CPU powers up
IPL loads <hardwired onto cpu>
Check if innerSD is valid (this is streak specific, device also locks up if it fails as the loader isnt robust enough to work around it)
Init modem and it's firmware <amss.mbn on older devices, non_hlos.bin on newer devices> (FYI modems are themselves complete 'system's in that they have their own ram and OS, basebands are complete OS images in most devices)
Check what button combos are pressed
Start booting:
If you pressed the recovery mode combo:
Load recovery SPL <dbl.mbn? + DT.img>
Display SPL menu:
Reboot
Load Recovery ("update from update.pkg")
Read from recovery.img and load it
Caliberate screen
If you pressed fastboot mode combo:
Load the fastboot loader <fsbl.mbn?>
If you pressed the download mode combo:
Go into download mode (for QDLtool)
If you did not press any combo: begin booting normally
Load dsp1.mbn
Load boot.bin
Linux kernal mounts and starts reading:
/system
/cache
/firstboot
/data
Android boots normally
Boot completes, you're at the lockscreen/home screen
I'm just making educated guesses at which *.mbn does what, as noone's really studied them to the point that they are willing to modify them.
Regardless they're signed so you cant modify them (we dont know per-se that the CPU checks the signatures on *.mbns, but I dont think any is willing to risk their device to try anyway)
The kernal images arnt signed, you can simply toss any kernal that is valid (otherwise it wouldnt boot)
When your device boots, the logo flashes 4 times:
1st logo: IPL and it's logo (possibly hardwired onto chip)
2nd logo: SPL and it's logo (stored in one of the *.mbns)
3rd logo: UBOOT and the kernal logo (stored with the kernal, sounds like a band name)
4th logo: bootimage.zip (whatever boot splash is with the installed rom
TheManii,
Thanks for the information. This is everything I wanted to know. If I have anymore questions I will ask later.
Web...
Hello everyone,
This thread previously was a discussion area for the Ouya Boot Menu feature during its early development.
It's now being transitioned to a support area. The new project description/download page is at:
http://forum.xda-developers.com/showthread.php?t=2499673.
Thanks!
CWM Bootloop
Hal9k+1 said:
Hello everyone, attached is the ZIP of an updated CWM Recovery IMG file.
This image is based on the latest stock Ouya kernel in GitHub. The kernel contains some newer HDMI code, which will hopefully increase the chance of getting the CWM graphics showing up properly. I also turned off HDMI’s HDCP in the compile (not needed for a utility partition such as this), and grabbed a patch from Kulve’s Ouya kernel fork to really ensure HDCP bypass.
More importantly, the image contains Tasssadar’s excellent work involving KExec-HardBoot. This technology should allow for the implementation of a “fastboot boot”-related capability from a running ROM, enabling kernel chain loading. The recovery image in particular will be a place to practice with KExec-HardBoot, and come up with a booting method that could eventually be flashed to the boot/kernel partition.
It is fine (and recommended) to fastboot to this image as a quick verification of things. However, it will be necessary to flash to the Recovery (“SOS”) partition for proper testing of KExec-HardBoot, since there’s an embedded reboot (to Recovery in this case) in there. Do *NOT* flash this to the Boot.
A simple chain load test can be done by extracting “zImage” from this image, and “initramfs.cpio.gz” from your current ROM kernel. (Included is “unmkbootimg” that can help here - runs on Linux.) Push these to /tmp on the Ouya while it is running this image. Then enter the Ouya shell and do:
kexec --load-hardboot zImage --initrd initramfs.cpio.gz --mem-min=0xA0000000 --command-line=”$(cat /proc/cmdline)”
kexec -e
It should come up with this new kernel under your current ROM’s environment. As verification, you should see kexec files under /sys/kernel.
I’m looking to implement a basic chain loading application. It would come up before the Recovery and ADB services, and do the following:
% Pause for a bit, to allow any Alt-SysRq keyboard action (jump to Recovery or Bootloader) that may be needed.
% Check for any attached USB mass-storage devices (e.g., thumb drive), and look for the file “kernel.img”. Pull it in and boot it if present.
% If that failed, then look to “/system/kernel.img” on the Ouya itself, and boot it.
% And if that didn’t pan out, then exit and allow Recovery/ADB services to come up.
I hope all of this will be of help to others along the way!
Click to expand...
Click to collapse
Will this help with the problem I have?..
New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz
View2Askew said:
Will this help with the problem I have?..
New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz
Click to expand...
Click to collapse
Sorry, I'm not sure I understand. It sounds like the new stock firmware update is failing to go in, perhaps because of consistent download corruption. Whether you're actually being dropped in to the recovery partition is unclear. You might try the download again with the other networking type (Ethernet vs WiFi). You might also just disconnect from the network for the time being, and see if you remain in the firmware without interruption. From there you can consider setting up ADB to see if you can administer the Ouya from a PC.
My post is more for the developers at heart, just in case my investigation piqued anyone's interest. Ideally the post would go in the Development section, but I evidently need a few more posts here to unlock that area.
Best of luck!
Dual booting
Yes, please do enable dual/multi booting
Is there something I can do to help in that regard?
kulve said:
Yes, please do enable dual/multi booting
Is there something I can do to help in that regard?
Click to expand...
Click to collapse
Thanks kulve, and thank you for the kernel patch set. I need to get familiar with the offerings there.
I don't see any blockages in my plan so far; I just need to start in and see what comes up. At least it's a better feeling than the dead-ends encountered with the U-Boot and regular KExec investigations.
Someone more enterprising could possibly port in the MultiROM project, but I'll stick with this. Will let you know if I get stuck.
My findings so far...
- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)
- I see how to pull the kernel and ramdisk out of an Android image (on the Ouya itself), so that they could be passed to KExec-HardBoot. I've done it with a script as a test but it may end up in an executable.
- I tried out a USB thumb drive. It's detected but no block device is made available under /dev -- I've finally decided that support is likely in a kernel module, which does not exist on the Recovery image. I'm probably not going to sweat this due to the next item.
- I notice that the CWM application can read the Ouya power button as something comparable to a keyboard key press. Borrowing this capability may allow us to count the button presses in a limited time range, and thus boot an appropriate image. (Would be easier than dealing with the pairing of the controller, but at least still wouldn't require a keyboard.) With this line of thought, I'm thinking the main image could sit in /system while any alternates could be in /sdcard or /data.
So in general, studying the code of the CWM application appears to be the next direction. Thanks - feel free to send any ideas.
Hal9k+1 said:
- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)
Click to expand...
Click to collapse
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).
kulve said:
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).
Click to expand...
Click to collapse
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!
Hal9k+1 said:
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!
Click to expand...
Click to collapse
I noticed your comments related to this on the "Ouya CWM Recovery" thread but I'm not allowed to post there, so I'll post here.
Or actually repost as I'm mostly repeating myself. I had all kinds of issues in getting output using /dev/graphics/fb0 in Linux with the stock Ouya kernel but after some fixes the fb1 seems to work quite reliable. I get the output even if I don't have HDMI plugged in during the boot and it chooses the right resolution both for my TV (1080p) and for my monitor (1680x1050).
To all: I have updated the attachment that's present on the first post. I've synced to the latest Ouya kernel and pulled in the next HDMI patch set from Kulve. My HDMI issue now appears to be fully resolved.
Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.
With this handled and due to my thinking in general, I'm going to back away from trying to compile CWM itself -- I don't want to invest in CM10.1's environment at this time. Instead I will borrow CWM's UI and input technology to build an independent front-end with this Ubuntu/glibc environment I have working. My idea is to release another Recovery image when that's ready so we'll have a chance to practice/debug before moving to the Boot image.
Hal9k+1 said:
Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.
Click to expand...
Click to collapse
Hit the Thanks button
Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.
ooo nice, ill try it out and see what happens
kulve said:
Hit the Thanks button
Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.
Click to expand...
Click to collapse
Done! :laugh:
My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.
Hal9k+1 said:
Done! :laugh:
My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.
Click to expand...
Click to collapse
Any chance of getting some concise installation instructions?
zondajag said:
Any chance of getting some concise installation instructions?
Click to expand...
Click to collapse
Here's a quick executive summary until I can update the 1st post.
I'm reminded there's another XDA project (Ouya Safe Recovery) with a very similar goal as this, and works by reversing the Boot and Recovery concepts. However it's completely incompatible with us, and those users should not be doing any flashing -- at least not until we have a Boot image ready.
First step is to get rcvy092613.img to the Ouya in its /tmp directory. This may be done with an "adb push rcvy092613.img /tmp" command, or can by done through Secure Copy if an appropriate SSH server is set up.
Next step is to access the Ouya shell, either running from the main ROM or from a Recovery ROM. Be sure to become root (ensure "#" in the prompt) as needed.
Run the following to back up the old image:
cd /dev/block/platform/sdhci-tegra.3/by-name/
dd if=SOS of=/sdcard/old_rcvy.img
Make sure the new image is correct - should see "2a882d1ba8c2d543503cacb49ab0d397":
md5sum /tmp/rcvy092613.img
On to flashing Recovery:
dd if=/tmp/rcvy092613.img of=SOS
Now wait at least a full minute in case there is any internal flushing still taking place. And to finish up:
sync
reboot recovery
Aye....never enough time to tinker it seems, especially with getting over this flu.
At this point I have my own compiled code splitting the boot image file, as well as counting the power button clicks.
I want to see if I can make a welcome/instruction screen, probably by getting CWM's minui down to its core essence. From there it will hopefully just be normal integration work to achieve a new Recovery for testing.
Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.
Hal9k+1 said:
Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.
Click to expand...
Click to collapse
Did I read correctly that the image support multibooting?
kulve said:
Did I read correctly that the image support multibooting?
Click to expand...
Click to collapse
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.
So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.
Hal9k+1 said:
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.
So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.
Click to expand...
Click to collapse
My kernel is hard coded to mount the Debian (or whatever) rootfs from /dev/sdaX so Ouya's internal partitioning doesn't matter. It would be really cool to be able to put kernelA1.im to /sdcard, an USB flash drive to the USB port and boot to Debian without tinkering with adb/fastboot/etc. on a PC.
I'm not currently using any initrd-images but adding something simple should be straightforward.