Related
Tonight I managed to get my first Android build, 2.0.1, compiled myself from AOSP, up and running on the Vogue from NAND.
I made some small changes, most notably, updating the build.prop to adjust the DPI to 120 and adding the libhtcgeneric_ril.so library, as well as adding the necessary (or.. is it necessary?) build.prop entry to get the radio functioning.
I proudly present my first Android build.
NOTE: This is purely for testing/evaluation purposes.
Working:
Radio
Data
Screen resolution is accurate
Not Working:
Audio
Power Functionality (buttons do not wake the phone?)
GPS
Anyone up for pointing out what I need to do differently to get the non-working aspects functioning? Any tips on optimization? Clues to setup and take full advantage of build.prop?
Additionally, do we have a central repository of Vogue (or MSM7k) drivers that've been ported as source, ready to be compiled for different versions?
There's probably a lot missing here that I'm not even considering.. so please feel free to make any comments, give any advice, or point me towards any documentation.
All help is appreciated. Thanks!
I think this is the repo you're looking for:
http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi
It contains Audio & GPS drivers, among other things. Can you wake the phone over adb shell with the command echo "wake" > /sys/android_power/request_state ? I'm also interested in getting an AOSP build running from source, I'd like to get the camera working for Eclair.
EDIT: Also, in the zenulator's eclair mod, the /system/etc/keychars directory contains these files:
Code:
htcvogue-ts.kcm.bin
qwerty2.kcm.bin
qwerty.kcm.bin
sapphire-keypad.kcm.bin
trout-keypad.kcm.bin
trout-keypad-qwertz.kcm.bin
trout-keypad-v2.kcm.bin
trout-keypad-v3.kcm.bin
tuttle2.kcm.bin
vogue-ts.kcm.bin
Perhaps that vogue binary is needed? That's my shot in the dark.
Those files are just for the keymapping, nothing more..
polyrhythmic said:
I think this is the repo you're looking for:
http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi
It contains Audio & GPS drivers, among other things. Can you wake the phone over adb shell with the command echo "wake" > /sys/android_power/request_state ? I'm also interested in getting an AOSP build running from source, I'd like to get the camera working for Eclair.
EDIT: Also, in the zenulator's eclair mod, the /system/etc/keychars directory contains these files:
Code:
htcvogue-ts.kcm.bin
qwerty2.kcm.bin
qwerty.kcm.bin
sapphire-keypad.kcm.bin
trout-keypad.kcm.bin
trout-keypad-qwertz.kcm.bin
trout-keypad-v2.kcm.bin
trout-keypad-v3.kcm.bin
tuttle2.kcm.bin
vogue-ts.kcm.bin
Perhaps that vogue binary is needed? That's my shot in the dark.
Click to expand...
Click to collapse
What's responsible (or handles) power management, then?
And why are there so many keymapping files? According to AOSP, Android will default to qwerty.kl, and certainly with the Vogue being as simple as it is, a single qwerty.kl set up for the Vogue would be sufficient.
So what gives? Or are these files all leftover as this was "ported", and they existed to support previous devices, etc.?
first off great job. this is exactly how i started out by building my own builds from source and then taking apart others to see what fits together. if i have time this weeked i'll have a look at it.
There are an awful lot of moving parts in power management in Android (and any OS, really) - there's the kernel's power subsystem which controls deep sleep / suspend, and which Android attaches a "wakelock" system to, each radio lib (Bluetooth, WiFi, phone) has power management (which hooks up to kernel interfaces), there's the panel driver which controls brightness, etc.
I think the keymapping files are just there so that no matter which one the framework looks for, it always finds one, speeding things up - rather than having to try to find each one and failing down until it finds its eventual failsafe qwerty, it loads the Vogue one straight away.
Awesome man, way to go!
Can you throw in links for rootfs/zimage, I will try later today on my wife's phone.
Thanks sshark, I would, but I've been tweaking that image continuously and at it's current state, it's broken.
Here are the major hurdles I'm facing right now:
How do I determine which drivers are and are not necessary in a build? If we use an AOSP build, or someone else's port, obviously we don't want audio drivers from the Nexus One or generic Goldfish sensors from AOSP, so how can we know what we need to be able to keep images clean?
Along the same vein, how does one incorporate drivers accordingly, such as audio?
Is power management really a dark art right now? Plemen's AOSP build is fantastic, but I typically have to push the power button four times to get the OS to wake up, whereas a 2.1 build I just played with on the Vogue would power up right away on one click. What gives?
When compiling images using genext2fs, does 80000 vs 160000 matter, NAND vs HaRET booting? What's the maximum?
Lastly, I've recently tried unsquashing others images, making changes, and then trying to re-ext2 them, mount them, and squash them. However, when I do this, my images no longer boot fully on my Vogue--instead they'll get as far as the boot animation, it'll run for a bit, and then the boot animation will pause for a second or two, and restart. This happens endlessly. Is this a problem with my process, be it ext2, sqsh (sqsh version, perhaps?) anyone have an idea?
Shidell said:
Thanks sshark, I would, but I've been tweaking that image continuously and at it's current state, it's broken.
Here are the major hurdles I'm facing right now:
How do I determine which drivers are and are not necessary in a build? If we use an AOSP build, or someone else's port, obviously we don't want audio drivers from the Nexus One or generic Goldfish sensors from AOSP, so how can we know what we need to be able to keep images clean?
Along the same vein, how does one incorporate drivers accordingly, such as audio?
Is power management really a dark art right now? Plemen's AOSP build is fantastic, but I typically have to push the power button four times to get the OS to wake up, whereas a 2.1 build I just played with on the Vogue would power up right away on one click. What gives?
When compiling images using genext2fs, does 80000 vs 160000 matter, NAND vs HaRET booting? What's the maximum?
Lastly, I've recently tried unsquashing others images, making changes, and then trying to re-ext2 them, mount them, and squash them. However, when I do this, my images no longer boot fully on my Vogue--instead they'll get as far as the boot animation, it'll run for a bit, and then the boot animation will pause for a second or two, and restart. This happens endlessly. Is this a problem with my process, be it ext2, sqsh (sqsh version, perhaps?) anyone have an idea?
Click to expand...
Click to collapse
i cant answer all of those questions, with that said ill tackle the last two
4. when using genext2fs to compile builds it doesnt matter what the -b count is we just use
Code:
genext2fs -d ./system -b [B]180000[/B] -a system.ext2
to make sure we could fit a ~180 mb system so if your system folder is ~120mb(uncompressed), using -b 125000 should work.
5. make sure you arent using squashfs-tools 4.0 because it isnt supported in our kernel version. so use 3.3 or 3.1 .
5b. when you see the boot logo looping, that means the build has crashed and like i said to you before i strongly recommend you setup adb on you box so you can run logcat to see what the phone is actually doing and to debug what went wrong and why it is looping
Thanks Jamezelle. So NAND users need to make sure it's -b 90000 (or less), as NAND only supports 90 mb. max, correct?
Shidell said:
Thanks Jamezelle. So NAND users need to make sure it's -b 90000 (or less), as NAND only supports 90 mb. max, correct?
Click to expand...
Click to collapse
right i would keep it around 88 to be safe.
I'm trying to get ADB to work (using ubuntu 9.10) and I've followed the instructions here, including restarting udev, but even still when I try to start adb, I get "command not found" in terminal.
Any ideas on what I'm missing?
EDIT: I'm missing a ./. I'm really starting to wish I could do this natively in Windows.. geeze.
Shidell said:
I'm trying to get ADB to work (using ubuntu 9.10) and I've followed the instructions here, including restarting udev, but even still when I try to start adb, I get "command not found" in terminal.
Any ideas on what I'm missing?
EDIT: I'm missing a ./. I'm really starting to wish I could do this natively in Windows.. geeze.
Click to expand...
Click to collapse
did you make sure you added the path to adb in .bashrc
# On Linux, edit your ~/.bash_profile or ~/.bashrc file. Look for a line that sets the PATH environment variable and add the full path to the tools/ directory to it. If you don't see a line setting the path, you can add one:
Code:
export PATH=${PATH}:<your_sdk_dir>/tools
Click to expand...
Click to collapse
that should clear up the "Command not found" issue
jamezelle said:
did you make sure you added the path to adb in .bashrc
that should clear up the "Command not found" issue
Click to expand...
Click to collapse
Yep, that was the issue. It needs to be there, or launched as ./, I presume.
Thanks much for your help tonight, Jamezelle.. I'm happy to report that I'm steadily making progress for a working release.
Shidell said:
Yep, that was the issue. It needs to be there, or launched as ./, I presume.
Thanks much for your help tonight, Jamezelle.. I'm happy to report that I'm steadily making progress for a working release.
Click to expand...
Click to collapse
thats great to hear, also thanks for your additions to the libgps.so! its nice to still see some android enthusiasm in this community
Hi All,
Unfortunately as a new user I can't post this in the Dev forum. So I'll put it here for now and perhaps can move it later.
I'm wanting to tinker with uboot on the Iconia. Ideally what I'm hoping to achieve is;
A versatile and usable port of uboot to the iconia complete with documentation (both how to get/build as well as use) and binary files available for download.
1) uboot to replace the default bootloader or the existing kernel image in flash and have the uboot able to load the standard kernel image from the system partition.
2) To have uboot able to run an interactive shell, either over USB or on the local console with a USB keyboard.
3) A boot menu would be nice with control by builtin buttons.
For my build box I'm using the current Debian with GCC 4.1 available
Anyway, if any anyone can help at all please fell free to respond. It is my intention to update this thread as I go, documenting the journey and ultimately publishing the results with how to info.
Tonight I will edit this with a better outline (more verbose) of what I'm attempting to do and some info regarding what my build env is and what info I already have.
Hope to create something useful here for everyone.
Owen.
OK. I'm still checking things out... eppeP, did you get anywhere with the SBK? if not uboot will just have to replace the android kernel and maybe be patched so it can load it from the system partition instead. One guy (lost the thread) said he had to mod the patch to get it to complile, but didn't say how.
As far as a boot menu goes, I'm thinking of a script that will search the boot folder of all mountable volumes and present a menu, much like the Apple boot selector does. Still don't know if its possible though and is somewhat secondry issue anyhow.
Can anyone give info on uboot env storage. also I need to know the partition layout for the internal MMC (got a good idea already but need to be sure and whats the partition layout?)
Have you talked to sp3dev and sc3k? Ive been followng the native linux thread and i believe they are trying to do just that. They would be your best source of help i think
Thanx gh123man,
Yep, I've seen good & exiting posts from sp3dev, muromec and hexeh about this stuff. Unfortunately I can't post in the dev threads cause I'm new to xda forum.
I was kinda hoping they might spot this thread and respond
Sounds like fun, I might be interested in helping.
So far I've been looking into generating the SBK, decrypting BCT/EBT and are just about to start looking at the partition format (there seems to already be some code for this, so that should not take long to get an idea of). So I guess unless I find something more interesting, trying to pick apart the bootloader to get a better understanding of that part might come soon anyway.
Hi everyone,
If you have any questions relating to Arch on the TF300, please post them here and not in the dev thread
I'll do my best (as well as others, I'm sure) to answer them, but bear in mind that you should have some basic Linux knowledge before flashing!
this is awesome!
cb22 said:
Hi everyone,
If you have any questions relating to Arch on the TF300, please post them here and not in the dev thread
I'll do my best (as well as others, I'm sure) to answer them, but bear in mind that you should have some basic Linux knowledge before flashing!
Click to expand...
Click to collapse
I can't thank you enough for this, it's been fantastic so far! I only have a few questions, as I am extremely new to arch linux...as in this is the first time I've used anything aside from debian in the linux world.
To start, how would we go about changing DE's? I've downloaded a couple, but i get errors every time i try to start one saying that another window manager is already running. With ubuntu one just logged out and chose from the log in screen, but there doesn't appear to be a log out process for this, i get a black screen every time i do. Other than that, are there any general programs/settings/tweaks that you would suggest applying? While this is very nice, it still seems to be missing some basic functions, such as putting the screen to sleep and having a set system time.
Despite all of that, this has breathed new life into my tablet, you're doing fantastic work and I hope you only continue to make it more amazing!
fankuan19 said:
To start, how would we go about changing DE's? I've downloaded a couple, but i get errors every time i try to start one saying that another window manager is already running. With ubuntu one just logged out and chose from the log in screen, but there doesn't appear to be a log out process for this, i get a black screen every time i do. Other than that, are there any general programs/settings/tweaks that you would suggest applying? While this is very nice, it still seems to be missing some basic functions, such as putting the screen to sleep and having a set system time.
Click to expand...
Click to collapse
Take a look at the .xinitrc file in the home directory. It's a hidden file so you may need to "show hidden" or give an editor the full path (/home/user/.xinitrc)
The file runs the following by default:
Code:
exec startxfce4 --with-ck-launch
You can change everything after `exec` to the script for a different DE, such as `startkde`. If you don't know the command, there should be a list of session templates in /usr/share/xsessions/. Inside each .desktop file there's an "Exec=" line, everything after that is the command to sub in.
My crappy bash skills threw together a quick command to get a list of installed xsessions:
Code:
grep "Exec=" /usr/share/xsessions/*.desktop | sed -E 's/^Exec=(.+)$/\1/'
The output on the default rootfs will just be "startxfce4". If you have KDE another line should output "startkde", and so on. Put the command in your .xinitrc (making sure to replace the current one) and then reboot as there's no proper way to log out.
whoops
timothyb89 said:
Take a look at the .xinitrc file in the home directory. It's a hidden file so you may need to "show hidden" or give an editor the full path (/home/user/.xinitrc)
The file runs the following by default:
Code:
exec startxfce4 --with-ck-launch
You can change everything after `exec` to the script for a different DE, such as `startkde`. If you don't know the command, there should be a list of session templates in /usr/share/xsessions/. Inside each .desktop file there's an "Exec=" line, everything after that is the command to sub in.
My crappy bash skills threw together a quick command to get a list of installed xsessions:
Code:
grep "Exec=" /usr/share/xsessions/*.desktop | sed -E 's/^Exec=(.+)$/\1/'
The output on the default rootfs will just be "startxfce4". If you have KDE another line should output "startkde", and so on. Put the command in your .xinitrc (making sure to replace the current one) and then reboot as there's no proper way to log out.
Click to expand...
Click to collapse
First of all, thanks for the help! Unfortunately, I appear to have done something incorrectly, as the Linux partition will no longer boot. That code didn't return anything but a ">", although as I type this i realize I may have needed to be root...haha, regardless, I tried to edit the .xinitrc file with "exec /bin/usr/startlxde", which is what was after "exec=" in the xsessions directory, nothing happened after waiting quite a while after boot.
I suppose I'll have to reflash the entire partition, considering i can't access the filesystems to change it back. Ah, the wonders of linux!
Sorry if I repeat my question,but how can i activate the keyboard without using a pc with linux ?
fankuan19 said:
First of all, thanks for the help! Unfortunately, I appear to have done something incorrectly, as the Linux partition will no longer boot. That code didn't return anything but a ">", although as I type this i realize I may have needed to be root...haha, regardless, I tried to edit the .xinitrc file with "exec /bin/usr/startlxde", which is what was after "exec=" in the xsessions directory, nothing happened after waiting quite a while after boot.
I suppose I'll have to reflash the entire partition, considering i can't access the filesystems to change it back. Ah, the wonders of linux!
Click to expand...
Click to collapse
You should be able to gain access easily via Recovery. Just adb shell in, mount /dev/mmcblk0p8 /mnt and look in /mnt/linux - that's your root file system...
Razorbacktrack5535 said:
Sorry if I repeat my question,but how can i activate the keyboard without using a pc with linux ?
Click to expand...
Click to collapse
Without using a PC... Hmm, that could be tricky. If you're in Android, and you add this line to the top of /data/linux/home/user/.xinitrc
Code:
maliit-server &
(before the exec line)
It should give you the virtual keyboard when you restart into Linux.
cb22 said:
You should be able to gain access easily via Recovery. Just adb shell in, mount /dev/mmcblk0p8 /mnt and look in /mnt/linux - that's your root file system...
Click to expand...
Click to collapse
I was actually able to just use the terminal emulator in android to navigate back to the .xinitrc file, turns out i wasn't supposed to leave the "--with-yadda-yadda" bit, so i got lxde working...and as it turns out, i don't like it nearly as much as the DE you included, so i'll be switching back to that!
First off: thank you SO much for your hard work at this! My tab has never browsed the web this well. It's better than the desktop I'm sitting next to. Arch is amazing!
Just a few questions. Do we have basic tab controls yet? I'm looking for, specifically:
Brightness Control
Enable/Disable Touchpad
Volume Control
Sleep/Suspend/Hibernate
Especially that last one! As far as I can tell, if I'm not going to use the tab for more than a couple minutes, it's apparently best to shut it down or reboot back into Android so it can "sleep". Or plug it in. I know we're rough around the edges yet, but is this stuff in, or no?
koiulpoi said:
First off: thank you SO much for your hard work at this! My tab has never browsed the web this well. It's better than the desktop I'm sitting next to. Arch is amazing!
Just a few questions. Do we have basic tab controls yet? I'm looking for, specifically:
Brightness Control
Enable/Disable Touchpad
Volume Control
Sleep/Suspend/Hibernate
Especially that last one! As far as I can tell, if I'm not going to use the tab for more than a couple minutes, it's apparently best to shut it down or reboot back into Android so it can "sleep". Or plug it in. I know we're rough around the edges yet, but is this stuff in, or no?
Click to expand...
Click to collapse
I don't think sleep/suspend/hibernate is implemented at all quite yet. The backlight seems to turn off completely when the screen times out though so you can fake having a low power mode, though obviously true sleep would be nice.
As for volume control, use pavucontrol. You may need to install it with `pacman -S pavucontrol`.
For brightness ... there's no good way to do this as far as I can tell. XFCE has a brightness control applet you can add to the bottom panel but it doesn't seem to work, and most of the usual packages (e.g. xbacklight, etc) don't detect the backlight device. Oddly enough I gave e17 a try and its builtin brightness applet worked fine, I wonder what they do differently ...
At any rate you can control it manually: the file /sys/class/backlight/pwm-backlight/brightness has a 0-255 value which controls the screen brightness. Note that you need to run the echo command as root
Code:
# echo "1" > /sys/class/backlight/pwm-backlight/brightness # minimum brightness
# echo "255" > /sys/class/backlight/pwm-backlight/brightness # maximum brightness
# echo "0" > /sys/class/backlight/pwm-backlight/brightness # completely turns off backlight. use with care
Setting it to zero makes it next to impossible to see the screen. I ended up having to ssh into the device (or reboot) to get it back.
I modified the file through a PC and It works ! Thanks, no problems with wifi
Sleep / Suspend isn't implemented yet.
But, I did a bit of testing, and the TF should last for about ~40 hours with the screen off, and the processor in the Low Power mode (which it does automatically. Obviously, it's still wasteful compared to proper suspend, but it's not too bad.
Really liking this so far, other than managing to break wifi once, which I fixed by doing a quick re(install I guess is the proper term). Any chance of a future release having SLiM or something setup out of the box(I'd do it but looking at some of the guides, we are missing some files(?) :s) either that or is there a way to autologin a new user other than the default one named user?
(edit for more info) I've tried following a guide I found on the arch wiki which had me modify [email protected], but it didn't boot so I had to edit it back to the default.
Thanks for all your work cb22, and thanks for taking my advice and switching file hosts
This may be a dumb question
But I can't for the life of me find out how to flash the hybridkernel.blob, I've already done every other thing, but i'm lost as to what to do there. Can I get a bit of guidance please?
:Nevermind: Silly me forgot to go to fastboot, I was trying to do it with adb, for any others though, reboot to fastboot on your tf300t and then run go to the location of fastboot on your pc and hold shift and right click and select open comand line here. Then move the hybridkernel.blob to the same location as the fastboot and run fastboot -i 0x0B05 flash staging blob
Shingaling said:
But I can't for the life of me find out how to flash the hybridkernel.blob, I've already done every other thing, but i'm lost as to what to do there. Can I get a bit of guidance please?
:Nevermind: Silly me forgot to go to fastboot, I was trying to do it with adb, for any others though, reboot to fastboot on your tf300t and then run go to the location of fastboot on your pc and hold shift and right click and select open comand line here. Then move the hybridkernel.blob to the same location as the fastboot and run fastboot -i 0x0B05 flash staging blob
Click to expand...
Click to collapse
Disregard, didn't see the edit until after you posted essentially the same thing I did.
So, does Adobe Flash support work at all in Chromium? I haven't gotten it to recognize the plugin at all. Any way to get this working, or is it just gonna keep bugging me to install it?
koiulpoi said:
So, does Adobe Flash support work at all in Chromium? I haven't gotten it to recognize the plugin at all. Any way to get this working, or is it just gonna keep bugging me to install it?
Click to expand...
Click to collapse
I don't think it works at all, I've tried every permutation sudo pacman -S flash-plugin that I could think of and I've gotten notwhere.
They is no flash for ARM for pure Linux.
Wysyłane z mojego ASUS Transformer Pad TF300T za pomocą Tapatalk 2
Itege said:
Any chance of a future release having SLiM or something setup out of the box(I'd do it but looking at some of the guides, we are missing some files(?) :s) either that or is there a way to autologin a new user other than the default one named user?
(edit for more info) I've tried following a guide I found on the arch wiki which had me modify [email protected], but it didn't boot so I had to edit it back to the default.
Click to expand...
Click to collapse
In theory you should be able to install a proper display manager without too many issues:
Code:
# pacman -S lightdm lightdm-gtk-greeter
# systemctl enable lightdm
...though when I tried this the DM would never actually be run. I was able to run it manually over SSH without issues (both lightdm and slim worked, more or less). I'm in the process of investigating why it isn't run at startup like it should be, whatever the issue is doesn't seem to be related to the display manager itself.
I have an issue with wifi.
1: The WLAN do not find any Network with Channel 12 or 13.. I think I must change the region in germany, but where?
2. The WLAN do not connect, they search for an network adress and after 30seconds they ask for wlan key again.. the key is correct and my router shows the connection.. but archlinux means the key is wrong.. testet with router und smartphone wlan hotspot..
3. 3G not connecting, i have create a profile for BASE Germany, but they do not connect.
UPDATE:
for 2: Sometimes they connect and I can surf. But the ping are more then 600ms.. After few seconds the connection lost, sometimes they connect again, sometimes say ask for wlan key again.
Maybe you can help me. Sorry for my bad english.
Yours Sincelery
Robert
Could any of you guys find out if you have a process running in "interruptible" state named "kinteractive_lo"?
You can check that using "top" in CLI or installing gnome-system-monitor. I guess the standard xfce task manager works as well.
It's driving me nuts and I believe is one of the reasons why I have to hard-reboot my tablet, since invoking reboot with --force works perfectly.
Thanks in advance!
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.
I've been trying different ways of entering bios and/or disabling secure boot, but can't figure out exactly if it has a BIOS menu at all.
Connected a keyboard to it and tries different keys during boot but I can't find the right combination.
Does anyone know how to enter the BIOS menu, or how do we go about disabling secure boot?
Thank you,
cocacola2015 said:
I've been trying different ways of entering bios and/or disabling secure boot, but can't figure out exactly if it has a BIOS menu at all.
Connected a keyboard to it and tries different keys during boot but I can't find the right combination.
Does anyone know how to enter the BIOS menu, or how do we go about disabling secure boot?
Thank you,
Click to expand...
Click to collapse
Keyboard is disabled(no driver installed, thanks Lenovo). Bios is usless.
From my LG-G4, Rooted running Stock 5.1
I was afraid that this would be the case. There seems to be no way to circumvent it either to boot a linux kernel.
http ://i.imgur.com/Tfd9U3i.jpg
Am I right to assume that the only thing we have that are signed are the stock Lenovo Yoga kernels, making them the only thing we can boot?
Also, does anyone know if these are the Microsoft keys, or some Lenovo keys, that they use for secure-boot. http ://i.imgur.com/dm1i16B.jpg
I'm wondering, because linux grub distributions do have a signed grub "shim" with the Microsoft key, maybe making us able to execute that at boot.
Ok, I've found out that it does have the microsoft keys, among other keys, which means it should in theory be possible, in theory. Will be looking into this more.
cocacola2015 said:
I was afraid that this would be the case. There seems to be no way to circumvent it either to boot a linux kernel.
http ://i.imgur.com/Tfd9U3i.jpg
Am I right to assume that the only thing we have that are signed are the stock Lenovo Yoga kernels, making them the only thing we can boot?
Also, does anyone know if these are the Microsoft keys, or some Lenovo keys, that they use for secure-boot. http ://i.imgur.com/dm1i16B.jpg
I'm wondering, because linux grub distributions do have a signed grub "shim" with the Microsoft key, maybe making us able to execute that at boot.
Click to expand...
Click to collapse
actually the problem is not in the unlocking but in making a working kernel for this tablet... because you see... Lenovo released the "source code" so they won't risk being sued for breaking the opensource (kernel) licenses, yet what they released is crap, broken drivers (i had to download all the source packages from all the YT2 models because they didn't even un-tarred crap and each one was 400MB and move things around and still it wont do the job as it should) they intentionally crippled the mk files, removed others, stupid and not working configs and so on... driver files missing... you get the picture and this was intentionally (not to say that this is only the kernel, not a chance to see in their source whats even more interesting: the code for the libraries, binaries etc) i am not saying it cannot be done but the amount of work it requires... hmm does it justify? in the end there are few people on this tablets and even lesser with the knowledge/available time to try and do something that will look like a custom rom
i thought at some point in making a rom but the hassle and time required don't justify it (what would i have? except that it's trendy to have a costom rom) so i for one will stay on my Android+Linux combo but who want to go further has my help
a better approach would be to build a custom rom based on the stock kernel/initramfs, this way you will start having the drivers in order and do your custom system (while no longer used in these days still it was cyanogenmod's way of making custom roms in the past) yet this one too is difficult and requires lots of work (and again for what? what's the gain?) but this one is much more acceptable than the rebuilding all previous one
the secure boot is passed (pm and you will understand) but to what end? see... the problem isn't so much in opening the door but in what you will do once inside (and i am inside that room for some time now yet no better bed than my Linux+Android combo) but feel free to continue on the road..
this is not to discourage you but to warn you about issues others (me) had on the road you're stepping now.
Thank you for the reply.
You're right, going the route of compiling whatever Lenovo has put out, is not the most streight forward option, but I disagree on not putting Linux on this tablet. This is the biggest and highest resolution tablet I've seen, and having Android on it instead of a full-blown Linux distribution, is a waste. Things like X forwarding to use it as a thin clinet, does not work well, I've tried all options. The only viable thing for using this as a thin client, is to run Linux on it, with its native input methods on the display server.
The gain is not having to pay twice as much for a Microsoft Surface tablet to install linux on, with it even being lower resolution and smaller screen.
well in this area @workdowg can give you more details as he is the one who loves X on this tab me i'm more like an Y type (aka windows gui/y) (i am happy with my openvpn and sshd) but again consider the unlocking part done and start collecting stuff for making your kernel
ionioni said:
well in this area @workdowg can give you more details as he is the one who loves X on this tab me i'm more like an Y type (aka windows gui/y) (i am happy with my openvpn and sshd) but again consider the unlocking part done and start collecting stuff for making your kernel
Click to expand...
Click to collapse
Very exciting. Need to boot a compatible kernel with the provided drivers, as you also suggested, and eventually get a full fedora distribution up and running.
Since this is an x86 tablet, no cross-compilation will be needed so it will allow for more flexibility with getting tools into initramfs to make it bootstrap systemd, and eventually run a full distribution from the system partition.
Would be very interested if workdowg can also provide some input on the issue.
cocacola2015 said:
Thank you for the reply.
You're right, going the route of compiling whatever Lenovo has put out, is not the most streight forward option, but I disagree on not putting Linux on this tablet. This is the biggest and highest resolution tablet I've seen, and having Android on it instead of a full-blown Linux distribution, is a waste. Things like X forwarding to use it as a thin clinet, does not work well, I've tried all options. The only viable thing for using this as a thin client, is to run Linux on it, with its native input methods on the display server.
The gain is not having to pay twice as much for a Microsoft Surface tablet to install linux on, with it even being lower resolution and smaller screen.
Click to expand...
Click to collapse
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
cocacola2015 said:
Very exciting. Need to boot a compatible kernel with the provided drivers, as you also suggested, and eventually get a full fedora distribution up and running.
Since this is an x86 tablet, no cross-compilation will be needed so it will allow for more flexibility with getting tools into initramfs to make it bootstrap systemd, and eventually run a full distribution from the system partition.
Would be very interested if workdowg can also provide some input on the issue.
Click to expand...
Click to collapse
ionioni said:
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the (huge)work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
Click to expand...
Click to collapse
I purchased my tablet with intention of dual booting Linux and Android and eventually going with Linux alone (being x86 I thought this would be a piece of cake). Now after getting Linux running (with Android in a chroot).... My vision has changed. TTY Linux is great, I have so much I can get done when not home. Using Xsdl, X runs well enough ( I had wine installed to run a Windows app) and I don't think it would be all that much better on the framebuffer.
The problem ends up being.... (and it has been stated before).... Touch still sucks on a small screen! Android just excels at it. So for me, if someone were to develop kexecboot or such I would definitely play with it (proof of concept) but I'm positive I'd go right back to my current setup.... ssh and the Xsdl for X as needed are perfect.
ionioni said:
as short as it was yet i still read it on fast-forward
i wasn't saying to not put linux on it (i have linux on mine too) i'm saying that putting ONLY linux was not worth (for my needs) the work required for (maybe i was too subtle ) i mean even if i had a full linux distro solution for my 1380 tablet i would still go for my current Android on Linux set-up that i have. yet, each has his own needs
oh boy it's getting late
Click to expand...
Click to collapse
Oh I see. The highest priority for me at least, is to get any linux distribution to boot.
workdowg said:
I purchased my tablet with intention of dual booting Linux and Android and eventually going with Linux alone (being x86 I thought this would be a piece of cake). Now after getting Linux running (with Android in a chroot).... My vision has changed. TTY Linux is great, I have so much I can get done when not home. Using Xsdl, X runs well enough ( I had wine installed to run a Windows app) and I don't think it would be all that much better on the framebuffer.
The problem ends up being.... (and it has been stated before).... Touch still sucks on a small screen! Android just excels at it. So for me, if someone were to develop kexecboot or such I would definitely play with it (proof of concept) but I'm positive I'd go right back to my current setup.... ssh and the Xsdl for X as needed are perfect.
Click to expand...
Click to collapse
Touch will probably work better on the larger screens, I've got the 13inch one.
---------------
So I got the latest kernel from kernel.org to boot but I'm not sure why it doesn't find the initramfs, I assume it has to do with it not existing on a partition, but being built into the boot.img.
http://i.imgur.com/IxdwXre.jpg
I'm trying to make it boot a live OS directly from USB, without initramfs. It's a bit difficult because I don't know how the block devices are named, maybe if anyone knows the kernel command line for booting the live linux using the custom kernel, using sdhci or normal usb.
Basically, instead of the normal LiveUSB sequence:
grub from USB -> kernel from USB -> root filesystem from USB
I want
custom kernel with android boot.img -> root file system from USB/SD card
cocacola2015 said:
I want
custom kernel with android boot.img -> root file system from USB/SD card
Click to expand...
Click to collapse
there's something wrong with your boot.img, and from the image there not enogh info
link the boot.img you make
ionioni said:
there's something wrong with your boot.img, and from the image there not enogh info
link the boot.img you make
Click to expand...
Click to collapse
What's wrong is you need the root= kernel argument, and I'm not sure how the block devices are named (For example, it doesn't have /dev/block/ like on the android kernels). The initramfs isn't modified yet, it's a custom compiled kernel with the source at kernel.org.
Created a boot.img that one can add root= kernel arguments to, to test booting from other media:
https://anonfiles.com/file/177753c2344c3c64c200cdb3803236bd
It has these kernel command line arguments built into the kernel:
Code:
oops=panic panic=360 vmalloc=172M debug_locks=0 bootboost=1 vga=ask i915.modeset=0 drm.vblankoffdelay=1 selinux=0 nomodeset ro debug noinitrd
Another one with UHCI (USB2.0) driver, instead of xHCI (USB3.0), because it might not reach init sometimes otherwise when plugged in, for some reason.
https://anonfiles.com/file/d41f495d118ab1e5ccef961baeb1bcce
No command line arguments built into the kernel, all in boot.img, boot_delay= disabled
Code:
oops=panic panic=360 vmalloc=172M debug_locks=0 bootboost=1 vga=ask i915.modeset=0 drm.vblankoffdelay=1 selinux=0 nomodeset ro debug noinitrd root=/dev/mmcblk0