Database Users

HTC Dream/G1 Dual/Tri Boot

Hi I am currently running debian on my phone using the method outlines here
http://www.myhangoutonline.com/2009/11/22/install-linux-on-your-g1/
Ive gotta say it quite slow and the method of installation is strange.
Here is a video of someone dual booting NATIVE debian on a G1. Read descrip in video for more info.
http://www.youtube.com/watch?v=tX1BOGl8Fnw
I would really want an option where you boot into recovery (Holding Home) and there is a menu where you can choose to boot into a normal recovery (Amon_Ra's) and the other options would let you choose between what OS you want to boot into like Gnome,OpenMoko,Debian. A normal boot would take you back to android.
Speeking of OpenMoko
there is a tut here
http://wiki.openmoko.org/wiki/OpenMoko_on_HTC-Dream
and i was wonderin weather anyone had tried this because it seems very interesting and would make it possible to bood gnome,debian etc
any opinions are highly appreciated
let me know what you think.

i dunno if im allowed to but bump

donut = 1.6 right?

yes
cupcake = 1.5
donut = 1.6
eclair = 2.0/2.1

Hi!
I've got OpenMoko dual-booting natively on my G1.
When I first looked into the problem, I saw that:
1) OpenMoko option involved boot flashing that would disable booting into Android.
2) Debian option had no ready-to-use rootfs. You had to bring on the usbnet and install debian packages through netinstall. But Debian was able to dual boot, thanks to FukTheRegister's excellent recovery image.
I surely needed something in the middle
I had contacted the OpenMoko port developer, leviathan (a nice guy btw). He's doing some great job of hacking the forked Android kernel to work on HTC Dream together with some other guys. He told me that he was continuing his work on OpenMoko for HTC Dream and that made me want to try it instead of Debian. By the way, FukTheRegister's Debian and Ubuntu ports are based on leviathan's OpenMoko kernel.
What I did to install and dual-boot OpenMoko was:
1) I partitioned my microSD card into three partitions: FAT, ext3, ext3
2) I extracted the OpenMoko rootfs to the third partition (ext3)
3) I made myself a recovery image that would consist of the most recent OpenMoko kernel from gitorious AND FukTheRegister's ramdisk (I just glued them together and threw away some modules to make it fit into 5Mb - maximum for recovery partition images)
4) I copied the recent kernel modules to /lib/modules/ on the 3rd partition of the sd card
5) I copied my recovery image to the sd card and flashed it with flash_image recovery /sdcard/openmoko-recovery-partition3.img right on the phone (under root).
After that I was able to boot OpenMoko with holding HOME + END during the bootup or Android (holding nothing).
See http://vaskas.ru/om-g1/ for all the relevant files.
If you want to try it yourself:
- repeat stage 1) after me
- take the openmoko-rootfs-20091128.tar.gz and repeat stage 2) after me
- copy the openmoko-modules-20100128.tar.gz to /lib/modules/ on the 3rd partition and extract it there
- take the openmoko-recovery-partition3.img and repeat stage 5) after me
P.S. I am not 100% sure that it's going to work for you, because I experimented a lot. It's pretty likely to work though.

hi again vaskas!
thx for work. Tried your setup, it worked for me.
Now it would be nice to have a recovery with an option to boot the second ext3.
Openmoko on Dream ----> nice!
Seems to get a usb connection:
http://wiki.openmoko.org/wiki/Usb_networking
Is a ssh/dropbear server already running on boot?

vaskas thx so much for the huge leap forward ecept im a little confused. so when i hold home + power using ur method it will boot into openmoko, butif i boot normally it wouild go into android, but what if i wanted to boot into normal recovery like amon_ra's?
if i boot into android normally and then run quickboot app and select recovery will it boot opoenmoko or amon_ra's recovery. also with your method does keeping apps on the first ext3 still work? while the second ext3 is for openmoko?
also when making second ext3 partition what size should i make it?
p.s this is sooooooo sick with open moko the possibilities are endless aswell as for people who prefer they can turn openmoko into debian and some time in the future android
so future = openmoko installed instead of android and then being able to boot debian/android or stay in openmoko environment.
also if it's not to much trouble vaskas can u please make a vid and put on you tube or here thx in advance andthx for ur hard work

olvap377 said:
vaskas thx so much for the huge leap forward ecept im a little confused. so when i hold home + power using ur method it will boot into openmoko, butif i boot normally it wouild go into android, but what if i wanted to boot into normal recovery like amon_ra's?
Click to expand...
Click to collapse
No, normal recovery won't be there, since my image replaces it. As far as I know, it's the only way to dual-boot now. If you wish to use your normal recovery image (amon_ra's or cyanogen's), just flash it with flash_image recovery my.img. When you're done with it, flash it back to openmoko's.
olvap377 said:
if i boot into android normally and then run quickboot app and select recovery will it boot opoenmoko or amon_ra's recovery. also with your method does keeping apps on the first ext3 still work? while the second ext3 is for openmoko?
also when making second ext3 partition what size should i make it?
Click to expand...
Click to collapse
I haven't tried quickboot yet.
Yes, Apps2SD still works perfectly with the first of ext3 partitions. I suggest that you make the second one at least 700Mb in size. I've got 500Mb taken by OpenMoko, for instance.
olvap377 said:
also if it's not to much trouble vaskas can u please make a vid and put on you tube or here thx in advance andthx for ur hard work
Click to expand...
Click to collapse
Well, you shouldn't really thank me since I only built a recovery image It's the kernel and ramdisk hackers who rock.
I'll make a vid when I have some free time, but I really suggest that you try it yourself

scheich said:
hi again vaskas!
thx for work. Tried your setup, it worked for me.
Now it would be nice to have a recovery with an option to boot the second ext3.
Openmoko on Dream ----> nice!
Seems to get a usb connection:
http://wiki.openmoko.org/wiki/Usb_networking
Is a ssh/dropbear server already running on boot?
Click to expand...
Click to collapse
FukTheRegister's ramdisk has such an option. I can try to make such a recovery if you need it.
Yes, dropbear is started automatically.

I'd love to see a solid and stable distro that would provide all the things that Android doesn't have, with:
- A compact desktop environment, supposedly e17 or LXDE
- Midori or Google Chrome
- Pidgin
- Sylpheed or Claws for GPG-secured e-mail
- MPlayer or VLC
- FBReader
- evince
- AbiWord
- Gnumeric
- Conky
- Gpodder for podcasts
- Some music player like Sonata
- Cron, sshd, gcc, scripting languages like Python and Ruby
- Zhone for making calls, texting, storing the address book
See, I'm not advocating touch-oriented software. I think we still need touch-capable apps for calling, texting and the address book. The others can be easily manipulated with the trackball and keyboard on G1.
That's what we should aim for IMHO: http://wiki.openmoko.org/wiki/Image:Debian_lxde_zhone.png
OpenMoko project has all this stuff. And that's really awesome. The question is if such an OS should be based on Angstrom (like OpenMoko SHR) or Debian (see http://wiki.openmoko.org/wiki/Debian). My preference is Debian since I'm a long-time Debian/Ubuntu user.

i prefer debian too and i will try this when i get home

i'm sorry for my really dumb question.
but how can i copy something from windows (7) to a ext2 partition?
and if you are creating those partitions, do both ext2 have to be primary or
one primary and one secondary?
thx in advance

lolmensch said:
i'm sorry for my really dumb question.
but how can i copy something from windows (7) to a ext2 partition?
and if you are creating those partitions, do both ext2 have to be primary or
one primary and one secondary?
thx in advance
Click to expand...
Click to collapse
They both have to be primary. I also recommend you to upgrade them to ext3 which is more stable thanks to journaling.
As far as I know, it's not possible to write to extX partitions from Windows. You can copy the files you need to the FAT partition and move them within the phone using Astro or other file manager.
You can mount the second ext3 partition from Terminal Emulator in Android like this:
$ su
# cd /sdcard
# mkdir SD2
# mount /dev/block/mmcblk0p3 /sdcard/SD2
Then it will be accessible from Astro in /sdcard/SD2.

i followed all the steps correctly but it just gets stuch at boot screen if i try to boot into recovery
any advice
maybe this has something to do with the fact that i have ebi1 phone?
pls help i really want this
EDIT:
wow im dumb i figured it out if u look at my sig ull see the way my partitions are setup
i followed all ur steps except each time i changed instructions from p3 to p4 becasue i also have a linux swap so when i installed this recovery it tried to boot from part3 which is my swap and obviously didn;t work
so vaskas can u please for everyone who has a linux swap release another recovery except that boots from part4?

Have also a swap as the fourth partition.. That doesn't matter, I think. Its only important, that the second ext3 is the third partition.
Heres my partition table:
fdisk -l /dev/mmcblk0
Code:
Disk /dev/mmcblk0: 1977 MB, 1977614336 bytes
255 heads, 63 sectors/track, 240 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000ac1bc
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 64 514048+ b W95 FAT32
/dev/mmcblk0p2 65 131 538177+ 83 Linux
/dev/mmcblk0p3 132 223 738990 83 Linux
/dev/mmcblk0p4 224 240 136552+ 82 Linux swap / Solaris

olvap377 said:
i followed all the steps correctly but it just gets stuch at boot screen if i try to boot into recovery
any advice
maybe this has something to do with the fact that i have ebi1 phone?
pls help i really want this
EDIT:
wow im dumb i figured it out if u look at my sig ull see the way my partitions are setup
i followed all ur steps except each time i changed instructions from p3 to p4 becasue i also have a linux swap so when i installed this recovery it tried to boot from part3 which is my swap and obviously didn;t work
so vaskas can u please for everyone who has a linux swap release another recovery except that boots from part4?
Click to expand...
Click to collapse
Ok, try http://vaskas.ru/om-g1/openmoko-recovery-partition4.img - it should work.
I'll try to make a multiple-choice one soon.

thx alot il try when i get home from school
EDIT: still dosent work just freezes at boot screen
plzzzz help any advice

olvap377 said:
thx alot il try when i get home from school
EDIT: still dosent work just freezes at boot screen
plzzzz help any advice
Click to expand...
Click to collapse
Do you mean you're stuck into the "G1" screen? If so, it's a recovery/kernel problem, not really connected with partitioning and stuff. I'm not sure if this openmoko kernel supports EBI1/32A, may be it's the problem

Well I have a dream which is 32b but with ebi1 radio I think this is the problem because amon_ra has a special recovery just for rogers dreams meaning something is different between them
If u could compare amon's rogers to normal recovery and find the differences could u chabge yours to make the latest part 4 file ebi1 compatible?

olvap377 said:
Well I have a dream which is 32b but with ebi1 radio I think this is the problem because amon_ra has a special recovery just for rogers dreams meaning something is different between them
If u could compare amon's rogers to normal recovery and find the differences could u chabge yours to make the latest part 4 file ebi1 compatible?
Click to expand...
Click to collapse
Frankly speaking, I don't think I'm going to have much time for this Since my radio is different, I won't be able to test it properly too.
Actually, I hope that more people join the thread so that we'll be able to solve much more problems together. I wonder where the guys from "Installing Debian on G1" are gone, I saw 2-3 people really interested in native Linux there.
Can you still rename the thread? If so, what do you think about appending something like " - Native OpenMoko and Debian" to it?
EDIT: compared Amon_Ra's recoveries in hex editor, they seem quite different

Eris Dual Boot ROM

I'm posting this in General as I don't have the knowledge to port this or develop a similar version for the Slide and I don't want to clutter up the Development forum.
Team ADX over in the Droid Eris forum came up with this gem; a dual boot Eclair Sense/2.2 AOSP ROM. http://forum.xda-developers.com/showthread.php?t=824072
I don't know if this can be done on our phones, but I thought it possible as you don't need to flash a custom recovery.

man this would awesome... the best of both worlds, run and "stock" ROM so we can still receive updates and still have CM.

i was actually thinking about dual boot just the other day! i dont feel like id be switching back and forth from 2 roms but itd be a great feature for those who do. unfortunately i dont think we have that much developers :/

I was reading the instructions for it and it looks like we'll have to wait for S-OFF before we can try it.
Part of the scripting is telling the phone how to partition the phone, sizes of those partitions, and so on. The slide is, generally speaking, un-brickable and it's the measures used to give us that luxury that also prevent us from doing so much like R/W on the system while in a non-recovery boot and changes we do make while booted are just wiped on reboot *sigh* man I love that ramdisk image.
Once we get S-OFF let's get this project started

KCRic said:
I was reading the instructions for it and it looks like we'll have to wait for S-OFF before we can try it.
Part of the scripting is telling the phone how to partition the phone, sizes of those partitions, and so on. The slide is, generally speaking, un-brickable and it's the measures used to give us that luxury that also prevent us from doing so much like R/W on the system while in a non-recovery boot and changes we do make while booted are just wiped on reboot *sigh* man I love that ramdisk image.
Once we get S-OFF let's get this project started
Click to expand...
Click to collapse
I don't think S-OFF is the issue. The partitioning instructions only refer to sdcard. This command:
Code:
mkpartfs primary fat32 0 3500 (can be adjusted to your needs. This partition will be used by the 2.1 rom and by recovery)
I think is only for the phone ROM storage and the for the recovery to find the boot scripts. According to the instructions, they're only partitioning the sdcard to run the AOSP ROM in it. They install the 2.1 Sense ROM to the phone, get it set up, run the boottosd script to boot into the 2.2 AOSP ROM on the sdcard, then set that up and run the boottophone script to go back to 2.1 Sense. They're running a ROM on the sdcard!
As I said before, I think something like this can work for our phones because it doesn't require flashing a recovery. The problem is we don't have the devs to do it.

heybobitsme said:
I don't think S-OFF is the issue. The partitioning instructions only refer to sdcard. This command:
Code:
mkpartfs primary fat32 0 3500 (can be adjusted to your needs. This partition will be used by the 2.1 rom and by recovery)
I think is only for the phone ROM storage and the for the recovery to find the boot scripts. According to the instructions, they're only partitioning the sdcard to run the AOSP ROM in it. They install the 2.1 Sense ROM to the phone, get it set up, run the boottosd script to boot into the 2.2 AOSP ROM on the sdcard, then set that up and run the boottophone script to go back to 2.1 Sense. They're running a ROM on the sdcard!
As I said before, I think something like this can work for our phones because it doesn't require flashing a recovery. The problem is we don't have the devs to do it.
Click to expand...
Click to collapse
I'll take a look. No promises as I'm an übernoob but I would love to have this.
Sent from my T-Mobile myTouch 3G Slide using XDA App

migueltherocker said:
I'll take a look. No promises as I'm an übernoob but I would love to have this.
Sent from my T-Mobile myTouch 3G Slide using XDA App
Click to expand...
Click to collapse
You won't be able to do a simple port. I posted about it more of as a proof of concept. Take the same idea, but obviously using our espresso sense and CM6.

heybobitsme said:
I don't think S-OFF is the issue. The partitioning instructions only refer to sdcard. This command:
Code:
mkpartfs primary fat32 0 3500 (can be adjusted to your needs. This partition will be used by the 2.1 rom and by recovery)
I think is only for the phone ROM storage and the for the recovery to find the boot scripts. According to the instructions, they're only partitioning the sdcard to run the AOSP ROM in it. They install the 2.1 Sense ROM to the phone, get it set up, run the boottosd script to boot into the 2.2 AOSP ROM on the sdcard, then set that up and run the boottophone script to go back to 2.1 Sense. They're running a ROM on the sdcard!
As I said before, I think something like this can work for our phones because it doesn't require flashing a recovery. The problem is we don't have the devs to do it.
Click to expand...
Click to collapse
Ok that makes sense. I thought it was pointing to the partitions on the phone telling it to format to a different size for some reason. Then what's preventing us from doing this? Just a lack of a proper script?

I have not poked around with how they are going about doing everything, but I was the one who got the ball rolling with my dual boot linux script. Conap took the basic setup and made some changes to just install them both on the phone and sdcard. Here is the basic of what it is doing....
The init.rc file found in boot.img has been modified for the froyo rom on the sdcard. The lines where it mounts [email protected] , [email protected], and [email protected] have been changed to the partitions on the sdcard (/dev/block/mcblk0px) The updater-script for froyo has been modified to flash the rom to the partitions on the sdcard. There are some gscripts which are ran from the phone that either modify or replace the boot.img for the rom you want to boot into.
The froyo ROM is running completely off the sdcard and the recovery is left untouched. The script that is required if you are using clockworks is because clockworks sbin and folder locations are setup a little different. I was running into some problems with froyo not recognizing the sdcard after making more than 4 partitions. Several had reported to me that their phones also did not recognize the sdcard, but the Eris phones somehow still did. I am working on something that should run from all android phones and allow you the option of installing whatever ROM you want.
One Last Thing..
Anyone is capable of learning how to do some development work. It just takes some patience and "Google". I had no knowledge of linux or any other scripting languages, except windows batch scripts, until 3 months ago.
There is not much activity on my thread, but once I get a working version finished it will be posted there-----Dual Boot Android

When you get it done and own working, post it in development. I only posted the thread in general because I knew I wasn't going to be the one to develop it. I'm a welder by trade and java and linux are a little beyond me. Although I am trying as I'm using Ubuntu as my main OS and starting reading java tutorials.
Sent from my CM6 Slide

heybobitsme said:
You won't be able to do a simple port. I posted about it more of as a proof of concept. Take the same idea, but obviously using our espresso sense and CM6.
Click to expand...
Click to collapse
If there was ever a reason to get a dev started on a project, this would be it. I would reconsider upgrading from the Slide if we had something this awesome.

unCoRrUpTeD said:
I was running into some problems with froyo not recognizing the sdcard after making more than 4 partitions. Several had reported to me that their phones also did not recognize the sdcard, but the Eris phones somehow still did. [/URL]
Click to expand...
Click to collapse
From what I understand, android can not *see* more than 4 partitions so they had to do something a bit different. Somewhere in the thread that's linked it states what they did to get it to work.

s off is tmobs response to....
KCRic said:
I was reading the instructions for it and it looks like we'll have to wait for S-OFF before we can try it.
Part of the scripting is telling the phone how to partition the phone, sizes of those partitions, and so on. The slide is, generally speaking, un-brickable and it's the measures used to give us that luxury that also prevent us from doing so much like R/W on the system while in a non-recovery boot and changes we do make while booted are just wiped on reboot *sigh* man I love that ramdisk image.
Once we get S-OFF let's get this project started
Click to expand...
Click to collapse
The "companies" wanted s-off due to the large number of brix getting returned for handest exchange and assurion claims, just to figure out somebody pooched sumthin up trying to be a HAXOR, if you haven't done anything like this before. Id suggest peeps get a g1 or some other root & rom-o-matic type for and play with it till you take on your brand new handset trying to install some bleenin edge hack...
You gotta learn to wank off before you can try it with somebody else in the room.
I remember my early days at xda, hacking my mda, xcaliber, and esato hacking SonyEricsson fones before they jumped the shark. People who had the ability to read and follow directions (emphasis on the read part) would study till they were sure they would still have a working fone at the end. Hung out and did great stuff with there handsets. And the noobs were wary enough to investigate before they just started mucking about.
So the handset manu. Had to do sumthin and now we have s-off.
the moral of my high and mighty rant an rave, if you don't know how to do sumthing or if you understand what to do but not the why, then keep reading, read more do less

KCRic said:
From what I understand, android can not *see* more than 4 partitions so they had to do something a bit different. Somewhere in the thread that's linked it states what they did to get it to work.
Click to expand...
Click to collapse
In the newest builds they have 2.1 system on the phones system partition and froyo system on the phones data partition. The data is moved to the SD. 2.1 and previous Rome had no problem with extra partitions on the sdcard.froyo changed the way it mounts the sdcard and could only see 4.
I am actually releasing a dual boot method very shortly that should work on any android phone with very little setup required on your part. I am in the process of finalizing it. Anyone interested in testing please let me know as I want to test on as many devices ad possible
Sent from my HERO200 using XDA App

Archos gen8 bootloader crack (disable signature check)

" 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.

LolBoot xD SGS2 dualboot - NEW 12.12.11: Easy-Setup App v2.51

(I wasn't really sure if this might fit into "Development", so I put it here, maybe a mod will move it, if it's a dev topic )
Anyways, here we go, I DUALBOOTED two different, independant ROMs on the S2
Video of dualboot in action: http://www.youtube.com/watch?v=l9-V_6Ua_D0
** THIS IS NOT (YET) COMPATIBLE **
** WITH ICS (ANDROID 4.0.x) ROMS! **
-- this goes for custom ROMs as well as stock ROMs --
Icey Sammich compatibility will be added once Sammy released their ICS kernel sources.​
!!! There now is an app for more convinient and easy setup of the dualboot !!!
(04.11.2011) DualBoot setup app v2.00: http://forum.xda-developers.com/showpost.php?p=19049047&postcount=94
(12.12.2011) App has been updated to 2.51, lot's of good new stuff! >> Free Version -- Donate Version <<
Click to expand...
Click to collapse
First off:
This is only a little experiment I did like "c'mon, has to be possible" - this is NOT (at least yet) tweaked for usability and anything the like, just a humble experiment.
That said, don't flame me if things are rather complexicated to do this ATM.
Maybe I'll come up with a more userfriendly way of setting this up, maybe someone else does, maybe no one does.
Also now that I found a base on what to do, there might be different ways (more easy ones maybe) to set this up, I'll keep toying around with it.
But let's cut to the chase, shall we
So, how was this set up? I'll give a brief rundown of what I did:
I edited a few .rc files in the initramfs of the kernel to make it actually perform a full boot when recovery mode was triggered and to fire up recovery mode when in battery-charging mode.
I also edited a few mounts in the boot .rc for the 2nd OS (in "recovery" mode) to use different partitions for /system and /data, so that we'd end up with really independant installs.
What partitions did I missuse for that:
partition 12 (mostly unused, only when installing a stock ROM AFAIK) for /system - that's a neat choice IMO as p12 is 512MB in size, just as p9 where /system usually sits on
partition 7 (which is usually /cache) for /data
gives us only 100MB of user data space, but for now that's OK, as said, it's only an experiment on how such a thing could be done.
with the original partition for /cache "gone", I mounted a tmpfs for it.
So the OS still has a usable /cache
Then I set up the two OSes:
(dualboot kernel not yet flashed)
Launchprep part 1:
I made a CWM backup of my normal installation I was running (stock XXKG6 at the time).
I installed DevNull-Test AOSP as to it's instructions
Some su'ed voodoo via a terminal while having the 2nd OS (the DevNull AOSP one, in this case) installed - best done in recovery mode via ADB:
rm -Rf /cache/*
cp -Rp /data/* /cache/
dd if=/dev/block/mmcblk0p9 of=/dev/block/mmcblk0p12 bs=4096
That did "set up" the 2nd OS to where it's supposed to go.
Launchprep part 2:
Then, "advanced restore" of the backup made a few minutes earlier:
- boot
- system
- data
Reboot
At this point OS #1 is running again and OS #2 is sitting in hiding, prepared to roll - so, let's roll:
Flashed the modified "dualboot kernel" (via an App or Odin or magic, doesn't matter).
---> DONE <---
reached the point to where everything works as shown in the video.
As said above already, yes it needs some manual work to set it up, yes there's a lot of things that might not work, yes there are other/better ways to set it up.
It's only a humble experiment - lot's of space for improvement.
Maybe you like it - for those who do, I wanted to share this
Attached to this post you find the modified kernel I used, it's based on my v1.20 custom kernel (see sig) but with the above mentioned changes.

I've seen the video m8, this is totally different approach, ur giving this device a new dimension. love u "in a straight way" hahaa

there currently an app called Bootmanager which also handle up to quadruple booting. But sadly currently only support HTC phones.
http://www.appbrain.com/app/bootmanager/com.drx2.bootmanager
well, one can hope!

Thanks OP this is an awesome concept! Very happy to see you posted it with a video! and nice boot animation!

sunwee said:
there currently an app called Bootmanager which also handle up to quadruple booting. But sadly currently only support HTC phones.
Click to expand...
Click to collapse
Yeah, that's the thing.... that app is HTC only.... but we have Samsung S-II and want dualboot as well.
I'm already brainstorming on how to enhance the actual usability of this, i.e. flashing a 2nd OS directely to it's place instead of first installing it to the main system partition. But there is problems when /data is not mounted to the original partition, at least stock doesn't like it on initial boot.... well, well....

That is great. Going to use this for sure. This should be in development for sure.
Congratulations already.
Sent from my GT-I9100 using Tapatalk

This is impressive bro sure will use it
but i want to ask one thing
SD card needed for this or not ?

That would be really cool (and definitely should goes to original development). Does it work with CM7/MIUI + custom rom?

vikas776 said:
SD card needed for this or not ?
Click to expand...
Click to collapse
No, so far this completely works with all internal storage.
But I have a few ideas I have yet to try to get mounted from other places - like images in /sdcard for example (I *so* hope that'll work.... )

Hi
Does this kernel include any of the Hellcat kernel tweaks or are they work in progress.
Sent from my GT-I9100 using Tapatalk

Tricky103 said:
Does this kernel include any of the Hellcat kernel tweaks or are they work in progress.
Click to expand...
Click to collapse
I made this build based on my v1.20 custom kernel, so it has everthing that one has - plus the touchfix already

exactly what i was hoping for.
great job - pls continue your work

Hi i tried this with instanity rom last night. When I use the three buttons to boot it just sits there not booting. My guess is the kernel is not compatible. Unless I made a mistake somewhere.
Sent from my GT-I9100 using Tapatalk

Hm, yah, might be that the kernel isn't fully compatible with that ROM, what kernel does the ROM usually use?
Did you boot it up fully at least once before copying /data to /cache ?

Yes I did fully boot up. But his kernel didn't have advanced activated in recovery so I flashed your kernel and moved the cache okay. But it said /data not found when I ran the 2nd command line.
I will flash aosp later. I like that rom.
I am not sure what kernel nitr8 uses. I think it is his own, Insane.tar would you like it to see if they can work together.
Sent from my GT-I9100 using Tapatalk

Tricky103 said:
But it said /data not found when I ran the 2nd command line.
Click to expand...
Click to collapse
Hm, yeah, that sounds like something didn't work.... make sure you run those commands as root, i.e. "su" as very first command (I'll add that to the first post).
Give me a direct link to the ROM and I'll try it.
Make take a few days though as I'm away from my computer a lot because of work the next two days, but I'll try once time permits.
Well yeah, and this still is in highly experimental stage, if I (or someone else) should ever get this to more stable and reliable state, I'll make an easy to use installer/setup tool
But I got a few other ideas on setting it up I have to try first....

http://goo.gl/2uZCh
This is the complete rom. Only 47mb. I thought you would like the whole rom

Tricky103 said:
Hi
Does this kernel include any of the Hellcat kernel tweaks or are they work in progress.
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
May be someday WINDOWS Mo 7 and Android on our sweet beast

Hi
I tried again with Aosp Dev-null. I still get this error "cp: can't stat '/data/*': No such file or directory "
after running this command line " cp -Rp /data/* /cache/ "
Any Ideas ?
It still doesn't boot if I press 3 button it brings up the boot logo and then black screens until it boots to the 1st partition.

Thanks for the link, will download and try as soon as time permits.
Also, try this command sequence, I got an idea what the issue maybe might be, give it a shot:
Code:
su
rm -Rf /cache/*
busybox cp -Rp /data/* /cache/
dd if=/dev/block/mmcblk0p9 of=/dev/block/mmcblk0p12 bs=4096
(use "busybox cp" instead of plain "cp", maybe it helps)
And some update on my ongoing thoughts for those interested:
- got an idea on how to make a more easy to use App for prepping and setting up the dualboot environment
- managed to do a neat thing I didn't really think it would work: issued a "mount" command and the OS thought it was mounting a partition of the internal flash (/dev/block/mmcblk0p12 in this test, but was testing for later on actually doing it with p9 - you might see where I'm headed here ) but instead of the partition it actually mounted from an .img file! (loopback)
i.e. "mount /dev/block/mmcblk0p12 /somedir" actually mounted "/somepath/someimage.img" to "/somedir" instead of the partition from /dev/block/... (you just gotta love Linux and it's flexible way of handling things....)
NOW, imagine /dev/block/mmcblk0p9 (the partition carrying the system) and p10 (data) being (kinda) transparently mounted from an IMAGE FILE
I "only" have to find a way to sneak this in before init starts mounting stuff.
If there's a way to do THAT.... unlimited multiboot from OS images, anyone?
(so far this is kinda dreaming, but would be cool to get it working )

[SUPPORT] Ouya Boot Menu Support Thread

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.