Database Users

MMC_CAP_ERASE Verification

Chainfire kindly created a small app that verified and displayed the firmware revision number - 0x19 being the fatal version. Almost all of our GN's have this firmware revision and basically this means that all of our Gn's can be bricked. For the moment we do not have the possibility of upgrading the firmware so we are stuck with this as a "feature".
However it be interesting to know if the currently installed kernel possesed MMC_CAP_ERASE functionality or not, since it is the Kernel that "intitiates" the bricking process.
Does anyone know if it would be possible to create such an app ?
I can imagine the scenario where one day a kernel is released which has MMC_CAP_ERASE functionality active but that the kernel is annonced as having it inactive or vice versa.
It would also allow us to know when the official kernels will have this functionality removed.
Unfortunately I do not have experience/knowledge necassary to write such an app.

Roy_W said:
Chainfire kindly created a small app that verified and displayed the firmware revision number - 0x19 being the fatal version. Almost all of our GN's have this firmware revision and basically this means that all of our Gn's can be bricked. For the moment we do not have the possibility of upgrading the firmware so we are stuck with this as a "feature".
However it be interesting to know if the currently installed kernel possesed MMC_CAP_ERASE functionality or not, since it is the Kernel that "intitiates" the bricking process.
Does anyone know if it would be possible to create such an app ?
I can imagine the scenario where one day a kernel is released which has MMC_CAP_ERASE functionality active but that the kernel is annonced as having it inactive or vice versa.
It would also allow us to know when the official kernels will have this functionality removed.
Unfortunately I do not have experience/knowledge necassary to write such an app.
Click to expand...
Click to collapse
Not an Android developer, but my educated guess is that it will be improbable, if not impossible, to build such an App. As I understand it, this property is embedded in some .c code of a Kernel, so not possible to read it via an App. If this property is stored in some config file which Kernel reads/uses then possibly an App can be written to read the same config file. As I said, not a dev in this field.

Good idea! Not an expert in the field either, but I believe some kernels have their settings available at /proc/config or /proc/config.gz, but that's not necessarily the case (depending on settings actually used at compilation). I'd also venture guessing that Samsung kernels don't do it , but can't check as I'm on a CM9-based ROM right now. We would need to check if any of the two locations above exist using a Samsung kernel.
Well that's one way to go around it anyway, there may be others

cooldoud said:
Good idea! Not an expert in the field either, but I believe some kernels have their settings available at /proc/config or /proc/config.gz, but that's not necessarily the case (depending on settings actually used at compilation). I'd also venture guessing that Samsung kernels don't do it , but can't check as I'm on a CM9-based ROM right now. We would need to check if any of the two locations above exist using a Samsung kernel.
Well that's one way to go around it anyway, there may be others
Click to expand...
Click to collapse
Samsung kernels do not enable /proc/config.gz
In addition, even if they did, MMC_CAP_ERASE is a flag within the source code of mshci.c - not a config item in the defconfig.
The only way to check if MMC_CAP_ERASE is present is to attempt to issue an erase command and see if it returns an error or not... The problem with this approach is pretty obvious...
There's no way to verify that a recovery or update-binary is safe without testing it against an instrumented kernel.
There's no way to verify that a kernel is safe without performing dangerous tests. It might be that a small erase is far less likely to cause damage than a large one - but this is too risky.

Entropy512 said:
In addition, even if they did, MMC_CAP_ERASE is a flag within the source code of mshci.c - not a config item in the defconfig.
Click to expand...
Click to collapse
Oh well, bad suggestion it seems, didn't think this was so deep the source. Thanks for the knowledge sharing though!

Byte code signature
From what I now understand MMC_CAP_ERASE is a flag that is either set or not.
If a kernel was compiled with the flag set and then the same kernel was compiled with the flag unset, would this not allow for a byte code signature to be detected.
This byte code signature could then be used in a binary search of an installed kernel.
This is guess work on my behalf and I could be completely wrong with my approach .

Roy_W said:
From what I now understand MMC_CAP_ERASE is a flag that is either set or not.
If a kernel was compiled with the flag set and then the same kernel was compiled with the flag unset, would this not allow for a byte code signature to be detected.
This byte code signature could then be used in a binary search of an installed kernel.
This is guess work on my behalf and I could be completely wrong with my approach .
Click to expand...
Click to collapse
Too much else changes from kernel to kernel. It's one bit set in a single variable, it's not like the MC1N2 initialization data which are huge fixed data structures.
Searching for a single bit set in a single integer variable when you don't know where that int is stored is impossible to reliably do.
Sent from my GT-P7510 using Tapatalk 2

mmc->caps
Entropy
I have googled copy of the mshci.c file and I see that the MMC_CAP_ERASE of used in order to initialise or not a struct named mmc->caps.
I can't find the declaration of mmc->caps but would it be possible to interogate
mmc->caps in order to read it's current state. This would allow us to see if the MMC_CAP_ERASE had or not been included in its initilisation ?
R

this is nearly impossible. yes there are ways to do it but i will take too much time and effort and will not worth it. my advice is look kernels which states it removed that flag like speedmod. if you want to be sure about the official kernels you need to wait until samsung releases source codes so you can look if that flag is set or not.

Having given a little bit more thought to the replies.
1 : The mmc-caps is a struct that is held at the kernel level.
2 : The Andoird SDK does not provide APIs that allow us to directly obtain information from the kernel level.
Therefore not an easy program to write.
Question : What method/language/technique would Chainfire have used in order to read the firmware level when he wrote his app?

Roy_W said:
Having given a little bit more thought to the replies.
1 : The mmc-caps is a struct that is held at the kernel level.
2 : The Andoird SDK does not provide APIs that allow us to directly obtain information from the kernel level.
Therefore not an easy program to write.
Question : What method/language/technique would Chainfire have used in order to read the firmware level when he wrote his app?
Click to expand...
Click to collapse
The chip cid/name are exported in the sysfs even on stock kernels. The fwrev is part of the cid string.
That capabilities variable, I am fairly certain, is not exported anywhere in sysfs. One could add exporting of it to the source, but that's kind of pointless - it's easy enough to verify open source kernels for safety, it's Samsung's binaries that are difficult.

Thanks for replying guys, you have made things clearer.
This bug is interesting even though it is potentially fatal.

[Nook Simple Touch][FW1.2.1] Kernel with Two Point Touch Mod for Download

Hi all,
Thanks to the huge discount on Nook Simple Touch earlier this month in UK, hopefully the device will regain some popularity and draw more attention from the XDA community. Unfortunately all the new devices come with firmware v1.2.0 while most posts in the forum were for the outdated v1.1.x, including the brilliant multitouch mod from wheilitjohnny. I know there is a way to downgrade to v1.1.x but I still prefer v1.2.1 after I tried v1.1.0. So I decided to port wheilitjohnny's mod to v1.2.1. After one week's hard work as I'm a newbie to the Linux world, I finally built the kernel and saw no more boot loop. All the multitouch test tools from Market correctly reported up to 2 fingers.
Before put the kernel to your device, make sure it's already running 1.2.1 firmware and rooted. You can find the link to the official upgrade file in the forum and you can use Nook Manager to root your device which is also available in the forum.
Then please found the kernel attached as zip file. You need to unzip the file and follow arkusuma's post on how to install it.
http://forum.xda-developers.com/showthread.php?p=24168019#post24168019
All credits go to wheilitjohnny. It's all his work.
One lesson I learned for all the developers who may be interested in more mod development is, to make a bootable kernel you MUST use toolchain from "http://www.codesourcery.com/sgpp/lite/arm/portal/release1293". Select the IA32 GNU/Linux TAR one (MD5: c6930d14801b4fab6705d72df013e58b). Any other toolchains including Google's own or even another version from codesourcery won't work. The generated kernel built with any other toolchains will only cause boot loop.
[UPDATE] Oh forgot to say, you need to add one more line to your /etc/permissions/required_hardware.xml on your device. You should be able to find the first line already in the file, just add the second line.
<feature name="android.hardware.touchscreen" />
<feature name="android.hardware.touchscreen.multitouch" />
More info please check http://forum.xda-developers.com/showthread.php?t=1563645

Does this kernel work with NoRefresh (I assume debug2 version for FW 1.2.x)?

koltshin said:
Does this kernel work with NoRefresh (I assume debug2 version for FW 1.2.x)?
Click to expand...
Click to collapse
Yes. I have NoRefresh_Debug2 and Fast Mode mod running together with this kernel. No problem so far.

Thx. Does this kernel works for both Nook Simple Touch and the Glow light model?
Sent from my GT-N7100 using xda app-developers app

waynesi said:
Hi all,
One lesson I learned for all the developers who may be interested in more mod development is, to make a bootable kernel you MUST use toolchain from "http://www.codesourcery.com/sgpp/lite/arm/portal/release1293". Select the IA32 GNU/Linux TAR one (MD5: c6930d14801b4fab6705d72df013e58b). Any other toolchains including Google's own or even another version from codesourcery won't work. The generated kernel built with any other toolchains will only cause boot loop.
I've had good success with the toolchain on Ubuntu; just install the gcc-arm-linux-gnueabi packages, and add the Makefile and head.S changes that were in the fastmode2 patch; I've not tried building this touch mod, but it has let me build my own kernels with usb host and with TLS support.
Click to expand...
Click to collapse

I can confirm that this kernel works on a NST with Glowlight on FW. 1.2.1 Thanks for the hard work.

Can I use this kernel for 2 fingers zoom in? I tried it with aldiko, but do not work with pdf.

You need to unzip the file and follow arkusuma's post on how to install it.
http://forum.xda-developers.com/showthread.php?p=24168019#post24168019
Click to expand...
Click to collapse
Could somebody please help me installing this without adb over wifi? Because i have internet only over ethernet. I was thinking of CWM.
Thanks

Sagittarius0 said:
... without adb over wifi?
Click to expand...
Click to collapse
Well, how about ADB over USB?

Renate NST said:
Well, how about ADB over USB?
Click to expand...
Click to collapse
Can you please help me exactly how to do it? I have tried it once for some other reason and it didn't work... :crying: And after that I searched for it here and found a post which said that adb works only over wi-fi.
And I am quite new with android so please explain the process well.

waynesi said:
Yes. I have NoRefresh_Debug2 and Fast Mode mod running together with this kernel. No problem so far.
Click to expand...
Click to collapse
Fast Mode don't works on my NST fw 1.2.1. What app exactly are you using to activated the fastmode?
update: this kernel don't have / sys/devices/platform/omap3epfb.0/graphics/fb0/fmode so fastmode is not possible

tebra said:
Fast Mode don't works on my NST fw 1.2.1. What app exactly are you using to activated the fastmode?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=39529578&postcount=140

Step one, use noogie and do a full backup of your Nook.
It should be almost 2GB file size.
Using noogie, copy uRamdisk.
Use bootutil.exe (in signature):
Code:
bootutil /x /v uRamdisk init.rc
[i]edit init.rc[/i]
bootuil /r /v uRamdisk init.rc
The line you edit out (with a number sign) is
Code:
[color=red]#[/color] setprop service.adb.tcp.port 5555
(uncomment this line to go back to using WiFi ADB)
Copy uRamdisk back to the Nook.
Reboot your Nook.
Read up about getting the ADB drivers working on your desktop here:
http://forum.xda-developers.com/wiki/BN_Nook_Simple_Touch/Installing_ADB

This thread is old, I know, but hopefully someone will spot this. So I took the plunge and installed Multi-Touch (running FW 1.21 and rooted). I followed the instructions for the ADB wireless method and also changed the required_hardware.xml file, resetting the permissions of the edited file to match those of the original.
Nothing is different? My original hope was that the pinch-zoom function in Dolphin 10.2.6 might work with this mod. It doesn't seem to work on either Android or Desktop settings in that browser. I can't see that it works anywhere. Maybe I need to reinstall Opera Mobile and test it there?
...
O.K., I just reinstalled Opera Mobile. No effect at all that I can discern.
Hmm....I am underclocking with No-frills CPU Control to 300 MHz. Is that the problem? Nope....changed back to 800 MHz and no effect.
So...what am I missing? Is there something I can check to be sure I did the ADB thing correctly (after I'm done using the "shell" do I just close it down or is there some closing command I should have used?). Does this mod have to be used in conjunction with something else?

I usually jump out of an ADB shell with ^C
There's an interim release of UsbMode-1.7a.apk in the signature.
If you touch the left 3/4 of the screen it will report touch coordinates.
It will indicate multiple touches.
That's the easiest way to see how many simultaneous touches your device supports.
My Nook: 2, my Kyocera: 4, my ZTE: 5

I installed a multi-touch test app from the Market and it showed that two fingers were recognized (no more), although the recognition was somewhat spotty.
I've been fussing around with it and sure enough it has begun to work with Opera Mobile, both at 800 MHz and 300 MHz (no discernible difference there). It also works very well with Perfect Viewer. It does not work with Google News and Weather (which really needs it), at least not the version that came with NookManager rooting.
Alas, it does not work with Dolphin, which was my main impetus for trying this. I've got Dolphin to the point where it is much more reliable than Opera Mobile but the only way to zoom is via a gesture which requires going to a blank screen, drawing the gesture and then returning to the current page. It makes one want to draw gestures that are not found in children's books. Although Dolphin claims pinch-to-zoom, it doesn't seem to work with the NST, at least not this version of Dolphin. Maybe I need to delve back into the past versions (which will probably be less stable in other respects...).
Well, anyway it works. I'll have to see if it affects the battery life in any significant way (I read on my Nook, too!). If not, I may as well keep it although its utility to me is limited.
Now to look at "no-refresh"......

nmyshkin, what about Google Maps?

Yes, I forgot to mention Google Maps (I was using "Places" but it amounts to the same thing). That works with multi-touch as well. I also noticed that to some extent multi-touch zooming in Opera Mobile is web-site dependent. For example, it does not seem to work at all on Wikipedia but worked OK on some other sites I tried. I just wish it would work in Dolphin
I just tried it with Orion Viewer (which I like for PDFs) and it also works there. It seemed to want to work with Kingsoft Office on the same PDF file but then the app crashed. There are other ways to magnify in both, of course.
I finally tried NoRefresh, and while it worked, I was left wondering what it is for other than as a "we can do this" feature. Lots of flickering while it made up its mind as a white-listed app was launched and then the image degradation thing. After I exited the app my screen was such a mess I had to reboot. I guess I'm used to the way the e-ink display sort of tears when scrolling (or even zooming now, for that matter). The NoRefresh just doesn't seem to give me anything I want. I have not tried FastMode. As I currently underclock to 300 MHz I am reluctant to overclock the Nook just so it will (sort of) work like something it is not and run down the battery really fast.

[SUPPORT] Ouya Boot Menu Support Thread

Hello everyone,
This thread previously was a discussion area for the Ouya Boot Menu feature during its early development.
It's now being transitioned to a support area. The new project description/download page is at:
http://forum.xda-developers.com/showthread.php?t=2499673.
Thanks!

CWM Bootloop
Hal9k+1 said:
Hello everyone, attached is the ZIP of an updated CWM Recovery IMG file.
This image is based on the latest stock Ouya kernel in GitHub. The kernel contains some newer HDMI code, which will hopefully increase the chance of getting the CWM graphics showing up properly. I also turned off HDMI’s HDCP in the compile (not needed for a utility partition such as this), and grabbed a patch from Kulve’s Ouya kernel fork to really ensure HDCP bypass.
More importantly, the image contains Tasssadar’s excellent work involving KExec-HardBoot. This technology should allow for the implementation of a “fastboot boot”-related capability from a running ROM, enabling kernel chain loading. The recovery image in particular will be a place to practice with KExec-HardBoot, and come up with a booting method that could eventually be flashed to the boot/kernel partition.
It is fine (and recommended) to fastboot to this image as a quick verification of things. However, it will be necessary to flash to the Recovery (“SOS”) partition for proper testing of KExec-HardBoot, since there’s an embedded reboot (to Recovery in this case) in there. Do *NOT* flash this to the Boot.
A simple chain load test can be done by extracting “zImage” from this image, and “initramfs.cpio.gz” from your current ROM kernel. (Included is “unmkbootimg” that can help here - runs on Linux.) Push these to /tmp on the Ouya while it is running this image. Then enter the Ouya shell and do:
kexec --load-hardboot zImage --initrd initramfs.cpio.gz --mem-min=0xA0000000 --command-line=”$(cat /proc/cmdline)”
kexec -e
It should come up with this new kernel under your current ROM’s environment. As verification, you should see kexec files under /sys/kernel.
I’m looking to implement a basic chain loading application. It would come up before the Recovery and ADB services, and do the following:
% Pause for a bit, to allow any Alt-SysRq keyboard action (jump to Recovery or Bootloader) that may be needed.
% Check for any attached USB mass-storage devices (e.g., thumb drive), and look for the file “kernel.img”. Pull it in and boot it if present.
% If that failed, then look to “/system/kernel.img” on the Ouya itself, and boot it.
% And if that didn’t pan out, then exit and allow Recovery/ADB services to come up.
I hope all of this will be of help to others along the way!
Click to expand...
Click to collapse
Will this help with the problem I have?..
New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz

View2Askew said:
Will this help with the problem I have?..
New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz
Click to expand...
Click to collapse
Sorry, I'm not sure I understand. It sounds like the new stock firmware update is failing to go in, perhaps because of consistent download corruption. Whether you're actually being dropped in to the recovery partition is unclear. You might try the download again with the other networking type (Ethernet vs WiFi). You might also just disconnect from the network for the time being, and see if you remain in the firmware without interruption. From there you can consider setting up ADB to see if you can administer the Ouya from a PC.
My post is more for the developers at heart, just in case my investigation piqued anyone's interest. Ideally the post would go in the Development section, but I evidently need a few more posts here to unlock that area.
Best of luck!

Dual booting
Yes, please do enable dual/multi booting
Is there something I can do to help in that regard?

kulve said:
Yes, please do enable dual/multi booting
Is there something I can do to help in that regard?
Click to expand...
Click to collapse
Thanks kulve, and thank you for the kernel patch set. I need to get familiar with the offerings there.
I don't see any blockages in my plan so far; I just need to start in and see what comes up. At least it's a better feeling than the dead-ends encountered with the U-Boot and regular KExec investigations.
Someone more enterprising could possibly port in the MultiROM project, but I'll stick with this. Will let you know if I get stuck.

My findings so far...
- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)
- I see how to pull the kernel and ramdisk out of an Android image (on the Ouya itself), so that they could be passed to KExec-HardBoot. I've done it with a script as a test but it may end up in an executable.
- I tried out a USB thumb drive. It's detected but no block device is made available under /dev -- I've finally decided that support is likely in a kernel module, which does not exist on the Recovery image. I'm probably not going to sweat this due to the next item.
- I notice that the CWM application can read the Ouya power button as something comparable to a keyboard key press. Borrowing this capability may allow us to count the button presses in a limited time range, and thus boot an appropriate image. (Would be easier than dealing with the pairing of the controller, but at least still wouldn't require a keyboard.) With this line of thought, I'm thinking the main image could sit in /system while any alternates could be in /sdcard or /data.
So in general, studying the code of the CWM application appears to be the next direction. Thanks - feel free to send any ideas.

Hal9k+1 said:
- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)
Click to expand...
Click to collapse
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).

kulve said:
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).
Click to expand...
Click to collapse
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!

Hal9k+1 said:
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!
Click to expand...
Click to collapse
I noticed your comments related to this on the "Ouya CWM Recovery" thread but I'm not allowed to post there, so I'll post here.
Or actually repost as I'm mostly repeating myself. I had all kinds of issues in getting output using /dev/graphics/fb0 in Linux with the stock Ouya kernel but after some fixes the fb1 seems to work quite reliable. I get the output even if I don't have HDMI plugged in during the boot and it chooses the right resolution both for my TV (1080p) and for my monitor (1680x1050).

To all: I have updated the attachment that's present on the first post. I've synced to the latest Ouya kernel and pulled in the next HDMI patch set from Kulve. My HDMI issue now appears to be fully resolved.
Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.
With this handled and due to my thinking in general, I'm going to back away from trying to compile CWM itself -- I don't want to invest in CM10.1's environment at this time. Instead I will borrow CWM's UI and input technology to build an independent front-end with this Ubuntu/glibc environment I have working. My idea is to release another Recovery image when that's ready so we'll have a chance to practice/debug before moving to the Boot image.

Hal9k+1 said:
Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.
Click to expand...
Click to collapse
Hit the Thanks button
Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.

ooo nice, ill try it out and see what happens

kulve said:
Hit the Thanks button
Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.
Click to expand...
Click to collapse
Done! :laugh:
My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.

Hal9k+1 said:
Done! :laugh:
My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.
Click to expand...
Click to collapse
Any chance of getting some concise installation instructions?

zondajag said:
Any chance of getting some concise installation instructions?
Click to expand...
Click to collapse
Here's a quick executive summary until I can update the 1st post.
I'm reminded there's another XDA project (Ouya Safe Recovery) with a very similar goal as this, and works by reversing the Boot and Recovery concepts. However it's completely incompatible with us, and those users should not be doing any flashing -- at least not until we have a Boot image ready.
First step is to get rcvy092613.img to the Ouya in its /tmp directory. This may be done with an "adb push rcvy092613.img /tmp" command, or can by done through Secure Copy if an appropriate SSH server is set up.
Next step is to access the Ouya shell, either running from the main ROM or from a Recovery ROM. Be sure to become root (ensure "#" in the prompt) as needed.
Run the following to back up the old image:
cd /dev/block/platform/sdhci-tegra.3/by-name/
dd if=SOS of=/sdcard/old_rcvy.img
Make sure the new image is correct - should see "2a882d1ba8c2d543503cacb49ab0d397":
md5sum /tmp/rcvy092613.img
On to flashing Recovery:
dd if=/tmp/rcvy092613.img of=SOS
Now wait at least a full minute in case there is any internal flushing still taking place. And to finish up:
sync
reboot recovery

Aye....never enough time to tinker it seems, especially with getting over this flu.
At this point I have my own compiled code splitting the boot image file, as well as counting the power button clicks.
I want to see if I can make a welcome/instruction screen, probably by getting CWM's minui down to its core essence. From there it will hopefully just be normal integration work to achieve a new Recovery for testing.

Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.

Hal9k+1 said:
Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.
Click to expand...
Click to collapse
Did I read correctly that the image support multibooting?

kulve said:
Did I read correctly that the image support multibooting?
Click to expand...
Click to collapse
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.
So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.

Hal9k+1 said:
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.
So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.
Click to expand...
Click to collapse
My kernel is hard coded to mount the Debian (or whatever) rootfs from /dev/sdaX so Ouya's internal partitioning doesn't matter. It would be really cool to be able to put kernelA1.im to /sdcard, an USB flash drive to the USB port and boot to Debian without tinkering with adb/fastboot/etc. on a PC.
I'm not currently using any initrd-images but adding something simple should be straightforward.

My setup with Ubuntu and a custom permissive Kernel

Hey everyone. I bought this device specifically because I do a lot of work on linux in command line world and I though it would be the perfect device when combined with the Logitech Pro keyboard and Complete Linux Installer (it's an app on Google Play). It turned out to be quite a bit of work getting everything working because of Knox and SELinux. Eventually I got a custom kernel working that allows me to toggle SELinux between permissive and enforcing.
I attached an Odin flashable tar that works on the SM-P900 (wifi version). I am on the North American version, so I have no idea whether it will work in other regions. If you flash this kernel then there are a few things you need to know:
I'm assuming you already have root on your device.
When you boot it will still be in "Enforcing" mode. This change simply allows you to use the "setenforce" terminal command or any of the apps on Google Play that do this for you.
You might experience some wifi weirdness after you flash the kernel. You just need to open up /system/build.prop and change ro.securestorage.support from true to false and then reboot to resolve the issue.
If you have a different version of the device or want to compile it yourself for any reason I wrote an article describing how I compiled it here:
http://graemehill.ca/compiling-permissive-android-kernel/
I also did a few other things to fix the keyboard and get linux running properly, so if you're interested in that I described my setup in more detail here:
http://graemehill.ca/turning-a-galaxy-note-pro-into-a-linux-laptop/

Thank you for this!
Sent from my SM-P900 using Tapatalk

trying to build kernel
I'm trying to follow your guide to compile a kernel from source. I have installed (on my Win 8.1_64 PC) Android SDK/NDK. GnuWin32, JavaJRE, and downloaded SM-P900 kernel source.
I'm getting errors at "Apply Kernel Config" step.
here's the output: http://pastebin.com/yFqDrNY8
Thanks for your help
Don :good:

dodo99x said:
I'm trying to follow your guide to compile a kernel from source. I have installed (on my Win 8.1_64 PC) Android SDK/NDK. GnuWin32, JavaJRE, and downloaded SM-P900 kernel source.
I'm getting errors at "Apply Kernel Config" step.
here's the output: http://pastebin.com/yFqDrNY8
Thanks for your help
Don :good:
Click to expand...
Click to collapse
It looks like you're in Windows. To my knowledge it is not possible to compile a Linux kernel in windows. I would recommend downloading virtual box and installing some Linux distro in there. This is what I was talking about in the "environment" section at the top of the article.
For android development I find that you need access to a lot of tools where some are only available on Windows and others are only available on Linux so a Windows PC with a Linux VM is ideal in my opinion.

Oh ok, no problem. I just misread the guide. I've setup a build environment in a vm before to compile aosp for my Nexus 10. Shouldn't be too hard to do it again. I recently rebuilt my pc so the vm I had got nuked.
Sent from my SM-P900 using Tapatalk

ok I got my Ubuntu VM up and running using this guide
http://forum.xda-developers.com/showpost.php?p=50748836&postcount=25
installed android NDK to ~android/NDK, and unzipped the kernel source to ~android/kernel
followed your guide to build a SELinux permissive kernel but i'm getting some errors when trying to compile. here's the output:
http://pastebin.com/Npdu7J5h
EDIT: retried doing the EXPORT command and now it seems to be compiling

dodo99x said:
EDIT: retried doing the EXPORT command and now it seems to be compiling
Click to expand...
Click to collapse
When you export a variable in the terminal it only exists for that one session, so if you open a new terminal instance you need to run the command again. If you want to set it permanently normally you can just put the export command into ~/.bashrc

Oh I see. I'll give that a try. I was able to create a new boot.img following the rest of your guide. I have yet to try flashing it though. Will have to find some info about all the kernel options that can be set. Hopefully be able to integrate HMP to get all eight cores running at the same time.
Sent from my SM-P900 using Tapatalk

Cool, let us know how that goes. I wonder how much it would affect battery life.

Graeme H said:
Hey everyone. I bought this device specifically because I do a lot of work on linux in command line world and I though it would be the perfect device when combined with the Logitech Pro keyboard and Complete Linux Installer (it's an app on Google Play). It turned out to be quite a bit of work getting everything working because of Knox and SELinux. Eventually I got a custom kernel working that allows me to toggle SELinux between permissive and enforcing.
I attached an Odin flashable tar that works on the SM-P900 (wifi version). I am on the North American version, so I have no idea whether it will work in other regions. If you flash this kernel then there are a few things you need to know:
I'm assuming you already have root on your device.
When you boot it will still be in "Enforcing" mode. This change simply allows you to use the "setenforce" terminal command or any of the apps on Google Play that do this for you.
You might experience some wifi weirdness after you flash the kernel. You just need to open up /system/build.prop and change ro.securestorage.support from true to false and then reboot to resolve the issue.
If you have a different version of the device or want to compile it yourself for any reason I wrote an article describing how I compiled it here:
http://graemehill.ca/compiling-permissive-android-kernel/
I also did a few other things to fix the keyboard and get linux running properly, so if you're interested in that I described my setup in more detail here:
http://graemehill.ca/turning-a-galaxy-note-pro-into-a-linux-laptop/
Click to expand...
Click to collapse
I tried to install this using VBox Odin and I couldnt get it to work. Tried using BOOTLOADER and also PDA. Not sure the correct one but neither worked for me. Also, Moblie ODin hasnt yet worked but when it does, things will be much easier for me at least.
I have a newly rooted SM-900. I will have to find time someday to compile the kernel against what I have. Must be a slightly newer version than the one you posted. That is only thing I can think since I just got my 12.2. Thanks for the detailed info.

Camera?
Hey, thanks for the great kernel. It's working as expected to enable permissive mode, but I'm having one issue with it. When I use your kernel, the camera is disabled (says something like "Camera Failed"), and it won't work even when trying different software besides stock, like Google Camera. Anyway, clearing cache, etc. doesn't do anything, but the camera works again when I flash the stock kernel. Is this related to permissive mode or something else with the settings?

aarstar said:
Hey, thanks for the great kernel. It's working as expected to enable permissive mode, but I'm having one issue with it. When I use your kernel, the camera is disabled (says something like "Camera Failed"), and it won't work even when trying different software besides stock, like Google Camera. Anyway, clearing cache, etc. doesn't do anything, but the camera works again when I flash the stock kernel. Is this related to permissive mode or something else with the settings?
Click to expand...
Click to collapse
The camera fails for me too. I dumped a logcat and isolated the issue here:
W/ActivityManager( 2746): Permission Denial: get/set setting for user asks to run as user -2 but is calling from user 0; this requires android.permission.INTERACT_ACROSS_USERS_FULL
V/ApplicationPolicy( 2746): isApplicationStateBlocked userId 0 pkgname com.google.android.GoogleCamera
But... the camera is not a huge deal. It did, however, break wifi. I did not get a logcat of that yet, but I would assume it is also a permission issue.

Wifi works for me using the fix mentioned in the OP. Also, thanks for looking into the camera issue. I agree it's not a big deal, and it's easily fixed by flashing the stock kernel, until someone figures out a proper fix.

aarstar said:
Wifi works for me using the fix mentioned in the OP. Also, thanks for looking into the camera issue. I agree it's not a big deal, and it's easily fixed by flashing the stock kernel, until someone figures out a proper fix.
Click to expand...
Click to collapse
Wow, I totally missed that entire line in the OP... You literally just made my whole day. I fought this all day long, desperate to get ubuntu working. Thank you for pointing that out.

I get "xt_mark.h" is missing (no such file or directory) error. Any idea why that may be?
I'm using the source for p900 international hoping that I may sidestep the camera issue that way (by enabling permissive to the international kernel I mean), but as it stands it does not compile.
I've googled it but until now it was/is to no avail...

Graeme H said:
Hey everyone. I bought this device specifically because I do a lot of work on linux in command line world and I though it would be the perfect device when combined with the Logitech Pro keyboard and Complete Linux Installer (it's an app on Google Play).
Click to expand...
Click to collapse
Hey Graeme H,
we both have the same intention. I am downloading the international Kernel at the moment and will compile it again for you guys. The download takes a little longer as I am at vacations.
I am going this route: doviak.net/debian-kit/debian-kit_p00.html . In the future I would like to have arch linux running on this device but a customized debian would be okay for the beginning, too.
Eventually I will try to use framebuffer instead of vnc or something like that. I would love to use sublime-text and dwm on that device with that resolution
Good luck guys. I will try to update.
Edit: hehe I have dwm in front of me now and the resolution is so high that I am barely able to read
Compiled the kernel and flashed in on my device but my camera is still not working. Maybe we need to edit the config:
# Camera sensor devices
#
# CONFIG_VIDEO_OV7670 is not set
# CONFIG_VIDEO_VS6624 is not set
# CONFIG_VIDEO_MT9M032 is not set
# CONFIG_VIDEO_MT9P031 is not set
# CONFIG_VIDEO_MT9T001 is not set
# CONFIG_VIDEO_MT9V011 is not set
# CONFIG_VIDEO_MT9V032 is not set
# CONFIG_VIDEO_TCM825X is not set
# CONFIG_VIDEO_SR030PC30 is not set
# CONFIG_VIDEO_NOON010PC30 is not set
CONFIG_VIDEO_S5K6B2=y
# CONFIG_S5K6B2_CSI_C is not set
CONFIG_S5K6B2_CSI_D=y
CONFIG_S5K6B2_POSITION_FRONT=y
# CONFIG_S5K6B2_POSITION_REAR is not set
CONFIG_VISION_MODE=y
# CONFIG_VIDEO_M5MOLS is not set
# CONFIG_VIDEO_S5K6AA is not set
Click to expand...
Click to collapse

Rather than each people compiles its kernel, could someone put a link to download the international kernel compiled? I think this would allow more people to get this kernel. Thank

PHP:
smylion said:
Rather than each people compiles its kernel, could someone put a link to download the international kernel compiled? I think this would allow more people to get this kernel. Thank
Click to expand...
Click to collapse
Compiled from Kitkat source. [ur#l]erhan.es/upload/sm-p900-permissive-intl.tar[/url] (odin)

Thank you but the link does not work

smylion said:
Thank you but the link does not work
Click to expand...
Click to collapse
Sorry, it is erhan.es/upload/sm-p900-intl-permissive.tar

Kernel Patch Advice - LOS13

i was hoping i could implement this.
someone already made a patch for our device on the github link
it would be nice if someone compiled the kernel with the specific selinux changes so it doesn't have to be completely disabled
not sure what is done already in the available moto x pure patch
any input appreciated, i'm a noob when it comes to modifying kernels
just want to make sure its done right, and request compiling the latest LOS13 kernel with modifications.
https://github.com/pelya/android-keyboard-gadget
i'm still on the june 2, LOS13 rom
the kernel reports as:
3.10.102-CM-ga7d46cc8b84-dirty [email protected] #1
LOS13 thread:
https://forum.xda-developers.com/mo...m-unofficial-los13-moto-x-style-pure-t3554226
LOS13 downloads
https://www.androidfilehost.com/?w=files&flid=153188&sort_by=date&sort_dir=DESC

What's the purpose of this mod? Anything other than a fancy gadget?

QBANIN said:
What's the purpose of this mod? Anything other than a fancy gadget?
Click to expand...
Click to collapse
the main reason i want it is because it allows you to plug your cell phone into a pc with usb cable and your phone acts as a hardware keyboard without needing an app on the computer.
this is a feature i have wanted since windows mobile 6.5 went away...which worked elegantly for me back in the day.
i didn't have to lug around a keyboard and mouse for work, which i use daily, and have since i went android around 2007/08
i've been patient for years and here it is, and already pretty much ready for our current device.
just need someone to compile it, i dont currently have a linux box or use linux regularly.

Mhm... I'll take a look at this patch.

Ok, you can try it https://www.androidfilehost.com/?fid=745425885120759729 . This kernel includes android-keyboard-gadget.patch + modified selinux policy. I will release soon up-to-date LOS13 build with this patch included.

whoa, you da man

not working
installed boot.img from fastboot
rooted
installed app from market (usb-keyboard by pelya)
app freezes when plugged in to usb and then try and use the mouse pad in the app
unplug usb and mouse pad unfreezes
tried manually using terminal as su to disable selinux and chmod 666 /dev/hidg0 /dev/hidg1
app still didn't work
i am using the recommended hacker keyboard input panel
tried usb debugging on & off
let me know any ideas or if you need me to test something specifically if you are willing to have a look

got it working
had to choose 'midi input device' as selection for android usb notification dialog
'usb for charging' & 'usb file transfer' modes do not work

eigerzoom said:
(...)'usb for charging' (...) modes do not work
Click to expand...
Click to collapse
It works for me

QBANIN said:
It works for me
Click to expand...
Click to collapse
whatever works
this is really great
been waiting 10 years, i knew it was possible
have keyboard, will travel