Related
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
" 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.
So, let's get linux installed natively on our Iconia.
As some of you I have been working on porting Iconia to chromeos 2.6.38 kernel (to get rid of Acer crappy moron-written drivers (well.. nothing personal, but most code written for commercial embedded devices is a pile of crap and you have to rewrite everything to update kernel or integrate upstream))
For now, I have hardcoded the kernel command line in the boot config to boot off /dev/mmcblk1p2 (that is, you must create ext4 (this is also hardcoded.. uhh)) second primary partition on your sd card with the root fs). For now, until all hardware is working fine and userland is ready, let's boot off micro sd. We don't have nvflash yet so let's leave repartitioning internal storage aside.
Flash the kernel image instead of boot.img to LNX or instead of recovery to SOS. And make sure to write your UID in a secure place before messing with the device - this is the only way to flash your device if you have checksum errors (you should contact sc2k in that case). Okay, even if you eff up here, there is still a way to get UID from a brick so take it easy. But if you do screw it, be prepared to work hard and use some command-line tools.
You should be able to use any armel rootfs. For X11, use fbdev driver and evdev for touchscreen.
For the proprietary NVIDIA accellerated drivers for X11, OpenGL ES and OpenMAX, download the nvidia-tegra package from AC100 PPA https://launchpad.net/~ac100/+archive/ppa (probably you have to manually download using this link http://ppa.launchpad.net/ac100/ppa/...dia-tegra_12-0ubuntu1~alpha1monson6_armel.deb as the package didn't show in aptitude for me after adding to sources.list.. or i was doing sth wrong) or the tarball from nvidia. A newer package of tegra drivers is available at https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra. You may just add an alternative to mesa EGL/GLES library path via update-alternatives to always use nvidia libs.
precompiled kernel image [15 August 2012]
http://www.mediafire.com/?p32l949n2s7la43
xorg.conf
http://pastebin.com/0a6T6c18
Here is some video
http://www.youtube.com/watch?v=NlGHZ5VTAr8
And now - we need developers, developers, developers.
The git is https://github.com/astarasikov/iconia-gnu-kernel
The main branch is chromeos-2.6.38 that is more stable. The 3.0 branch is unstable (network traffic causes virtual memory trashing).
For now, the following stuff works
-Panel/framebuffer/backlight
-Touchscreen
-Internal eMMC
-microSD slot
-usb gadget
-usb host
-gpio keys/buttons [rotation switch acts as wifi/bluetooth power blocker. iirc, left position disables wireless, right - enables]
-charger
-battery
-shutdown
-LEDs
-bcm4329 wifi (don't forget to copy bcm4329-fullmac-4.bin to /lib/firmware/brcm and nvram.txt from android's /system/etc to the same dir as bcm4329-fullmac-4.txt) [causes lockups with 3.0 kernel]
-nct1008 temperature sensor for cpu throttling
-sound. external speakers and headphones.
-bcm4329 bluetooth. accessible at 115200 on /dev/ttyHS2. Look at http://htc-linux.org/wiki/index.php?title=Ubuntu/Leo/Bluetooth to get it running at higher speeds with proprietary firmware patches (hcd files from android)
-suspend. Although will probably drain a bit more power than android because mmc power is not disabled (due to a race condition in kernel. and because we have rootfs on micro sd). Two glitches are: sometimes, the device freezes for several seconds after suspend (will test later if playing with wifi clock fixes it) and fonts get corrupted after suspend if using proprietary nvidia X11 driver. [suspend works in 2.6.38 only]
-kxtf9 accelerometer
-mpu3050 gyroscope
-ak8975 magnetometer
The following stuff is broken or not implemented at all
-hdmi video. May be working but no one has tested. hdmi audio is not implemented.
-light sensor
-video cameras, focus, torch.
-gps. To turn on the chip, it should be enough to enable gpio 203 via sysfs. Unfortunately it uses the proprietary MEIF protocol which can probably be obtained from Nokia under NDA. And I don't feel like disassembling the whole megabyte of the gps daemon
-3G. I don't have the modem in my iconia. So I don't care. But should be easy to add.
And one notice for those who want to join in. I don't care if hardware works properly. I want 'beautiful' code. That is, please, when you make patches to add functionality, do not follow the path of corporate coders and do not invent custom interfaces and sysfs hacks. Use rfkill for bt/3g power control, for example. And don't be selfish - please share your patches and userland stuff.
TODO:
-fix framebuffer issues (no console till X boots, X fonts and window decorations get corrupted after suspend with proprietary drivers) it kinda works.
-video camera
-port meego or build the list of good software in ubuntu for handling sensors, virtual keyboard etc
I'm not currently working on the project and don't have the device anymore. Feel free to PM me if you need help with some tegra hackery
good job...
Hi sp3dev,
Cooooool, you rock
Thanks
FANTASTIC WORK!!!!
Guys... I'm not so clued up on the bootloader here, but is dual boot possible with this setup?
"so I guess I need to switch distro to try out this cool stuff"
What distro are you considering switching to?
tholmewood said:
FANTASTIC WORK!!!!
Guys... I'm not so clued up on the bootloader here, but is dual boot possible with this setup?
"so I guess I need to switch distro to try out this cool stuff"
What distro are you considering switching to?
Click to expand...
Click to collapse
Yes, dual boot is possible - the android is in internal memory, our stuff is on micro sd card. It should be possible to even dual boot from internal memory, but not right now
I am switching to ubuntu because it has a lot of packages prebuilt
sp3dev said:
Yes, dual boot is possible - the android is in internal memory, our stuff is on micro sd card. It should be possible to even dual boot from internal memory, but not right now
I am switching to ubuntu because it has a lot of packages prebuilt
Click to expand...
Click to collapse
Man I cant wait to get Netbook Remix dual booting on this badboy... Living the dream I tell ya...
Thanks again
Would booting a distro from say the usb work?
Sent from my HTC HD2 using XDA Premium App
M..N said:
Would booting a distro from say the usb work?
Sent from my HTC HD2 using XDA Premium App
Click to expand...
Click to collapse
I see no reason why not. But you'd have to hardcode the uuid of the boot partition in kernel command line or build a ram disk. Anyway having to use a heavy and power consuming external storage sounds like an extremely stupid and useless idea
what about Gentoo?
This is great! i would love a dual boot. and ubuntu! i just got done reading that the asus got this and was like. i want it now. now we almost have it keep up the great work!
sp3dev said:
I see no reason why not. But you'd have to hardcode the uuid of the boot partition in kernel command line or build a ram disk. Anyway having to use a heavy and power consuming external storage sounds like an extremely stupid and useless idea
Click to expand...
Click to collapse
Not even from a USB flash drive? Wouldn't it be the same as say booting it from a microsd card?
Sent from my A500 using XDA Premium App
Have Anyone seen this LINK?
Hope it can help!
OrionBG said:
Have Anyone seen this LINK?
Hope it can help!
Click to expand...
Click to collapse
That sounds like the place to start!
Thanks
Thanks man you really rock !
I cant wait to try it out. Hope you will continue working onto this.
can you share the steps after compiling the kernel ?
I would like to try with different kernels but I'm still not confident on how to do this.
If I use dd if=zImage of=/dev/mmcblk00p1
will this effectively boot this kernel after pressing power and vol- keys ?
Hello, do you think that Dvb t is possible if Linux is running on the acer?
yodor said:
can you share the steps after compiling the kernel ?
I would like to try with different kernels but I'm still not confident on how to do this.
If I use dd if=zImage of=/dev/mmcblk00p1
will this effectively boot this kernel after pressing power and vol- keys ?
Click to expand...
Click to collapse
No.. You need to build boot image with android's mkbootimg and flash instead of recovery. And then, mkfs.ext4 on your sd card on partition mmcblk1p2 and untar rootfs there
Thanks man, this is really getting clear to me now.
I'm going to try and post results here. I will love to try and see how arch, fedora and ubuntu will run on A500.
http://dev.gentoo.org/~armin76/arm/tegra2/install.xml
There are two apps in the Android market that will install either Ubuntu or Backtrack for you- they are not native installs though I can confirm they perform well even if it is chroot and I can also confirm they work on the iconia great! Search ubuntu installer or backtrsck5 linux install in the mmarket....
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...
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.