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.
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
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...
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.
Want to try Nougat on your Nook HD+ or HD?
Installing Nougat has never been easier. Procedure described in post 239 of this thread.
Development for unofficial CM-12.1 for Nook HD and Nook HD+ has ceased.
The author @amaces has moved on to Marshmallow (Android 6), and the zip files for these progressive releases are what you now see at the collaboration link. If you wish to install CM-12.1 look instead through the pages of his "obsolete" folder for "cm-12.1-20151018" and "twrp-2.8.7.4" final releases. CWM should install these properly but later versions are likely to fail due to deficiencies in the CWM recovery utility.
Better yet try the latest Marshmallow and TWRP versions. For this you must create a new bootable microSD card using these files provided by @belfastraven and the downloaded zip files "cm_hummingbird-ota-MHC19Q.160407.zip" and "twrp-3.0.1-0-hummingbird.zip". These versions may advance by the time you happen to do this. The procedure is the same as described in the .pdf guide for CM-12.1, except with the new files.
And use a current GApps file for the ARM platform, Android 6.0 from http://opengapps.org/.
This is a detailed tutorial for beginners. Seasoned users may find it overly verbose.
My toy box contains some Nook HD and Nook HD+ tablets, and I recently became aware of CyanogenMod. I studied about it for a while and finally tried a CM-12.1 installation. It was successful, and I was so impressed by the improvements that I told some Nook-owning friends about it. They quickly decided to do likewise and asked for instructions.
My friends and I are all retirees, so we have seven Saturdays a week to spend as we wish. I decided to spend a few of mine re-writing my notes into an instruction manual. As of today, September 25, 2015, there are eleven formerly stock Nook tablets whose beginner-owners have followed the instruction and successfully installed CM-12.1. Several of these are being regularly updated as revisions are released. No bricks have been cast so far.
During the study period I spent a lot of time on xda developers pages, and it eventually occurred to me that there might be other beginners who could make good use of Nook-specific instructions. So I am pleased to offer this manual to anyone interested, and hope it will save you some time and trouble.
The procedure uses the technique and boot files by @leapinlar. The ROM and TWRP zip files used are those created by @amaces. Profound thanks to these experts for their diligent work and generosity.
Below is a synopsis of the instructions. The complete PDF document is attached to this post.
This document will guide you through the steps of installing a pure modern version of the Android operating system on your Nook HD or Nook HD+ tablet. The installation is done from a bootable microSD card using the ClockWorkMod recovery utility to install the contents of zip files. This straightforward method does not require ADB or rooting the Nook. The result is CM-12.1 installed with basic Google apps and your choice of TWRP or CWM for your resident recovery utility.
There's room for improvement.
If I could learn how to create a bootable microSD that would boot to TWRP instead of CWM the procedure could be reduced to four easy steps. I have found no help for this, and my own attempts have all failed. I would be most grateful for any help so I can update the instructions.
This is brilliant!
Where was this three days ago ? I really could have used this when I finally got around to fixing my dead Nook HD+ with spare parts from an ebayed broken on, and decided to finally go for broke on EMMC (after SD Boot killed the device twice on me while charging overnight.) Not a fun initial teardown to pull out that mainboard, but manageable with a good deal of care.
My own fumbling around led me to using verygreen's external recovery image here (Note, they are the Initial sdcard Images located at the very top) as recommended by amaces writing it to the SDcard using Win32DiskImager for a bootable sdcard (On Windows 10 here). Then using that, I went and installed amaces' TWRP and CM12.1 onto the Nook HD+ followed by finding a set of gapps to install as well.
I missed the backup/wipe parts of your guide, sadly. Though I do have a stock copy laying about, and my device has been out of warranty for a while by now. I just didn't think of doing the wipe (though looking back, the broken one I took the mainboard from and its EMMC already had that done). Further, I was lost seeing that "Root" fix note and ended up hitting yes. Fortunately, it doesn't appear to have done anything for my tablet.
In the end? I got my Nook HD+ up and running using amaces' CM12.1 ... even if in a manner that may make those more experience wince at my errors. Still, its nice to have my large tablet for reading and watching videos once more rather then needing to spend a couple hundred dollars on a decent large tablet. Gaming isn't up to par (older games still does decently), but its an old device and not exactly what I wanted it for anyways.
I just wish I held off a couple more days so I had this guide to help me through this. Still, for anyone that comes after I hope your efforts help them.
Thank you for taking your time and writing such a useful guide. I am currently on cm11 m12. Are there any noticeable difference between 12.1 and cm11? Is the update from cm11 to 12.1 the same as from stock to 12.1?
Holy crap that is awesome. Looks like I picked the perfect day to upgrade the kids YouTube machine from 4.4
Sent from my SAMSUNG-SM-G920A using XDA Free mobile app
Thank you for taking the time to put together this extremely easy to follow guide! It helped me breath new life into my Nook!
Thanks so much for writing up a document us older folks can handle. (and say hello to Sequim for me!)
:good:
Cheers.
This looks like exactly what I need. I've finally reached the point of frustration with my Nook HD+ that I'm ready to go through with a reflash. Thanks so much for providing this great resource.
But, one question. You advise not modifying the user interface after flashing CM 12.1 to the device. This is because the ROM is still under development, and making chages of that sort will make upgrading to newer images more difficult. In principle, I understand this. But is this a permanent condition?
In other words, I suppose development on CM 12.1 will go on until interest in it is lost and the project goes moribund. No one can predict when that will happen, but if things go as they have for the past couple of decades, this project is likely to be abandoned sooner rather than later. So is there some projected point when the project reaches stability and when users can make interface changes without worry of having problems upgrading? Or is the inadvisability of making such personalization modifications a permanent condition?
i got it installed simple enough but cant seem to login to my google account, it just tells me something went wrong and wont sign in, any ideas what i can do?
I used this manual to put CM 12.1 on my Nook HD+ and it worked great. What a wonderful resource you've provided.
A couple of minor issues I encountered are as follows. The directions in step 5e call for rebooting the system, but the menu I encountered did not correspond precisely to the description, What is described in step 5e is a two-step process, first slecting "reboot," then "power off." However, when I tapped the "reboot" button, there was no subsequent option to power off; the device simply rebooted. That didn't prove to be much of an issue since, realizing the Nook would be trying to boot from the SD card, I simply quickly removed it in a very early stage of the boot process.
Another minor issue is that the file system is kind of strange, with the backed up data being located under /storage/emulated, with a couple of symlinks in other locations to that same directory. It's kind of puzzling to find my way around the system. That said, so far everything works and all my previous data seems to have been preserved.
As far as improvements to the guide, you might want to add the additional directive that developer options can be gained by going to Settings > About table and tapping on "build number" seven times. I wanted to change the hostname on the new installation, and I needed developer options to do that. I don't know how many retirees are going to want to do things like that but, age wise, I'm not too far away from that category, and I needed that. So, maybe something you could add at the end of your nice manual.
As to booting directly into TWRP, I found an img file at twrp.me under /devices/barnesnoblenookhdplus.html. It looks like directives there are for writing it to the internal recovery partition, but I don't see why it could not be written to an sd card by slightly adapting those same directives. I'm new enough to this to not quite understand whether the recovery image would answer to your issue, but it's something you might want to consider.
All in all, you've provided a nice resource with this guide. It worked well for me on a first try, so it's something I'd definitely recommend to others.
Question about step 3b from the manual (Backup the existing system and data to the microSD card). Let's say this is a brand new Nook HD+ that contains no data or configuration that the user wishes to preserve: can that step just be skipped in such a case?
I'm asking because my current Nook HD+ has a pretty badly cracked screen and I'm thinking of replacing the unit with another Nook HD+. Doing this upgrade to CycanogenMod has got me thinking more seriously about getting a unit with an intact screen. If I end up replacing the unit, there will be no data or configuration on the replacement unit that I'll be wanting to preserve.
wayover13 said:
Question about step 3b from the manual (Backup the existing system and data to the microSD card). Let's say this is a brand new Nook HD+ that contains no data or configuration that the user wishes to preserve: can that step just be skipped in such a case?
Click to expand...
Click to collapse
It wouldn't hurt to have a backup of Stock, imo. Further, its useful habit to get into as you upgrade to any new image that is released and not loose everything. If only to allow you to reset to the default state and try again.
wayover13 said:
But, one question. You advise not modifying the user interface after flashing CM 12.1 to the device. This is because the ROM is still under development, and making chages of that sort will make upgrading to newer images more difficult. In principle, I understand this. But is this a permanent condition?
Click to expand...
Click to collapse
I'm a bit lazy when it comes to installing incremental releases, so I prefer to do simple "dirty installs". This means re-flashing without wiping the old installation, which can be done in seconds with no consequences.
But a dirty install will probably fail if you have made user-interface changes, even if you try to reverse out those changes before flashing. You can still install revisions anytime you wish, but you must do the wipes first. This means you will have to go through the setup procedure all over again, which takes a lot longer than a dirty install.
CM-12.1 for our Nooks should eventually be offered among the official nightly releases, and hopefully a milestone release now and then. I might consider UI tweaks after installing one of these, then settle down for a long quite period of no more updates.
If a stable CM-12.1 ever happens, we'll all be installing CM-13 by then.
wayover13 said:
The directions in step 5e call for rebooting the system, but the menu I encountered did not correspond precisely to the description, What is described in step 5e is a two-step process, first slecting "reboot," then "power off." However, when I tapped the "reboot" button, there was no subsequent option to power off; the device simply rebooted.
Another minor issue is that the file system is kind of strange, with the backed up data being located under /storage/emulated, with a couple of symlinks in other locations to that same directory. It's kind of puzzling to find my way around the system. That said, so far everything works and all my previous data seems to have been preserved.
As far as improvements to the guide, you might want to add the additional directive that developer options can be gained by going to Settings > About table and tapping on "build number" seven times. I wanted to change the hostname on the new installation, and I needed developer options to do that.
As to booting directly into TWRP, I found an img file at twrp.me under /devices/barnesnoblenookhdplus.html. It looks like directives there are for writing it to the internal recovery partition, but I don't see why it could not be written to an sd card by slightly adapting those same directives. I'm new enough to this to not quite understand whether the recovery image would answer to your issue, but it's something you might want to consider.
All in all, you've provided a nice resource with this guide. It worked well for me on a first try, so it's something I'd definitely recommend to others.
Click to expand...
Click to collapse
I too was puzzled a few times. There are two "Reboot" buttons: One in the TWRP entry menu and the other is deeper in where the flash process ends. The one in the entry menu will present a Reboot menu with includes a Power Off button. Use the tablets move-back triangle below the screen to navigate back to the entry menu.
I think you refer to the stock backup made by CWM before flashing CM-12.1. My stock Nooks were under-used with no data worth recovering, so I never looked into this. If you'd care to share any details about your findings it might be helpful so some subsequent readers.
This one is covered on Page 15 (actually sheet 17 including cover page and Table of Contents) under the heading Reboot to Recovery.
Once TWRP is installed its pretty easy to use it to install a newer version of it. But getting the boot files prepared on a microSD to boot to this image turned out to be more complicated than my very limited experience could manage (I'm a retired orchardist). The CM-12.1 installation procedure would be greatly improved if I can make this work, but I really need some professional help to make this happen. I keep hoping for a knowledgeable person to come forward.
Thank you very much. There are so many helpful members on this forum, and it is gratifying that I've been able to make a tiny contribution.
zspeciman said:
Thank you for taking your time and writing such a useful guide. I am currently on cm11 m12. Are there any noticeable difference between 12.1 and cm11? Is the update from cm11 to 12.1 the same as from stock to 12.1?
Click to expand...
Click to collapse
I tried CM-11 briefly on one of my Nooks before I became aware of CM-12.1, so I can tell you there is a huge difference. The move is from Android 4.4 to Android 5.1. And in my opinion all of this huge difference is for the better.
If you use the instructions, you can follow them exactly to move from CM-11 to CM-12.1. You are going to wipe the existing installation entirely, so it matters not what it is.
siccoblue said:
i got it installed simple enough but cant seem to login to my google account, it just tells me something went wrong and wont sign in, any ideas what i can do?
Click to expand...
Click to collapse
I've been pondering this, but nothing has yet come to mind. I'm presuming you did the full wipe before starting the install.
Which GApps did you install? If, for example, you chose one of the more sophisticated packages (tk_gapps or open_gapps) you would have had to defer installing it until Step 5. If so, and if you were distracted for a while and forgot to install it, I suspect the setup process would not offer an opportunity to log in to your Google account. This is probably not your issue since you were able to attempt a login.
Were you replacing the stock Android? Any other clues you can offer?
I managed to fix it, I had to completely wipe everything as opposed to just a normal reformat and it fixed the issue, but I actually have another problem now, I'm trying to do this on my second nook and when I attempt to flash twrp, cwm recovery now throws me an error on both my tablets, along the lines of "cannot install recovery this was designed for ovation and you are on ." it says that the device is . and won't let me flash it, any ideas?
PeteInSequim said:
I'm a bit lazy when it comes to installing incremental releases, so I prefer to do simple "dirty installs". This means re-flashing without wiping the old installation, which can be done in seconds with no consequences.
Click to expand...
Click to collapse
I understand vaguely what you're talking about here, but I'm pretty new to flashing Android devices and find myself wanting to know more. Is there some link you can point me to that explains in greater detail about dirty versus other types of installations? What I'm most interested in learning is how much configuration is too much to permit a dirty install. For example, the tablet is of little use to me if I can't install certain apps on it; will installing apps, for example, obviate the possibility of the sort of dirty install you're speking of?
PeteInSequim said:
But a dirty install will probably fail if you have made user-interface changes, even if you try to reverse out those changes before flashing. You can still install revisions anytime you wish, but you must do the wipes first. This means you will have to go through the setup procedure all over again, which takes a lot longer than a dirty install.
Click to expand...
Click to collapse
For example, I want a battery percentage monitor in the taskbar. If I enable that, is that the sort of user interface change after which I will be unable to do a dirty install? How about deleting what I would call desktop icons and/or adding others from newly-installed apps? Is that the sort of user interface change that will cause me to be unable to do a dirty install? If so, it seems like I would need to become a sort of beta tester in order to retain the possibility of doing further dirty installs, rather than using my Nook for my everyday needs.
PeteInSequim said:
CM-12.1 for our Nooks should eventually be offered among the official nightly releases, and hopefully a milestone release now and then. I might consider UI tweaks after installing one of these, then settle down for a long quite period of no more updates.
If a stable CM-12.1 ever happens, we'll all be installing CM-13 by then.
Click to expand...
Click to collapse
I'm obviously not too well versed in CynaogenMod/Android development. I wasn't aware that CM-12.1 was at such an early stage of development. Let me see if I'm, understanding correctly: is the CM-12.x series tracking Lollipop, while the projected CM-13 will track Marshmallow (Marshmallow being, as I understand it, the next Android release)?
I've obvioulsy got a lot to learn on this front.
---------- Post added at 11:24 PM ---------- Previous post was at 10:55 PM ----------
PeteInSequim said:
I too was puzzled a few times. There are two "Reboot" buttons: One in the TWRP entry menu and the other is deeper in where the flash process ends. The one in the entry menu will present a Reboot menu with includes a Power Off button. Use the tablets move-back triangle below the screen to navigate back to the entry menu.
Click to expand...
Click to collapse
Yes, on a second attempt I realized I needed to hit the move-back trinagle to get to the reboot button to which the manual was referring. Thanks for the clarification.
PeteInSequim said:
This one is covered on Page 15 (actually sheet 17 including cover page and Table of Contents) under the heading Reboot to Recovery.
Click to expand...
Click to collapse
You're right. I should have kept reading
On my second try, I realized I'd noted another discrepancy in the manual, one that occurs between steps 5a and 5b. After step 5a (successfully booting to TWRP by holding the power and home buttons down for the correct interval) I actually get an "Unmodified System Partition" screen. There, I have the option of either keeping the system partition read-only, or swiping another option to allow modifications. It is only after either tapping the read-only item or swiping the allow modifications item that I get a subsequent screen where I can tap the Install button (step 5b).
PeteInSequim said:
Once TWRP is installed its pretty easy to use it to install a newer version of it. But getting the boot files prepared on a microSD to boot to this image turned out to be more complicated than my very limited experience could manage (I'm a retired orchardist). The CM-12.1 installation procedure would be greatly improved if I can make this work, but I really need some professional help to make this happen. I keep hoping for a knowledgeable person to come forward.
Click to expand...
Click to collapse
I have a fair amount of experience writing image files to disks/partitions. Does it seem like that's what's needed? I also know how to mount an image file as a looped file system in order to, for example, copy files from it. That's something like what was done with the unrar'ing of CWM and copying files over to the SD card. If any of that experience sounds helpful, I could probably conduct some experiments to see if I could succeed at this. I'm just not sure what the TWRP image file I found is: is it a bootable image? If so, I'm not sure copying files from it to a bootable partition, like you instructed to do for CWM, would work. Writing a bootable image to an SD card should, on the other hand, cause that SD card to become a bootable medium.
In any case, as I said, I could conduct some experiments if it seems like any of my suggestions would be helpful. I'm not really any kind of professional either, btw. I got into computing when I undertook, at a later stage of life, some graduate studies in the humanities, during which I developed the crazy notion that I could somehow gain the upper hand over the machines. That attempt ended in failure, but I have kept up my doomed insurgence and learned some things along the way.
siccoblue said:
I managed to fix it, I had to completely wipe everything as opposed to just a normal reformat and it fixed the issue, but I actually have another problem now, I'm trying to do this on my second nook and when I attempt to flash twrp, cwm recovery now throws me an error on both my tablets, along the lines of "cannot install recovery this was designed for ovation and you are on ." it says that the device is . and won't let me flash it, any ideas?
Click to expand...
Click to collapse
Well, sounds like the zip file you're attempting to flash is mismatched to your model Nook. "designed for ovation" means the zip file is intended for the 9-inch Nook HD+. Are you trying to install on hummingbird, which is the 7-inch Nook HD?
I understand vaguely what you're talking about here, but I'm pretty new to flashing Android devices and find myself wanting to know more. Is there some link you can point me to that explains in greater detail about dirty versus other types of installations? What I'm most interested in learning is how much configuration is too much to permit a dirty install. For example, the tablet is of little use to me if I can't install certain apps on it; will installing apps, for example, obviate the possibility of the sort of dirty install you're speking of?
Click to expand...
Click to collapse
The best explanation I can offer is on page 17 of the instructions. Basically if flashing an incremental CM-12.1 revision a dirty install is fine (no need to wipe the system partition) UNLESS you have altered the user interface with things like theme, colors, wallpaper, boot animation, sounds, etc. If you have, you must wipe both the Data and System partitions.
Or if you are installing an OS version for which the existing one is not a close relative. The most outrageous example of this would be re-installing the old stock Barnes & Noble Android in place of your CM-12.1. Review the information on pages 16 and 17, and I think you'll get a good handle on this.
I've been called to dinner; will address your other questions after that.
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