Related
Hello, I found a driver online that I want to add to my Android phone. It is a DisplayLink device driver.
magoroku15/DisplayLink-driver-for-android (from github)
The part I am confused about is how to go about adding the driver to my phone. Do I need to download the Android source code, add the driver to that, and then build the whole thing? Or is it possible to just load the driver as a module?
I've searched Google but haven't found anything definitive. I'm not even sure if I'm using the right terms here, as I haven't ever played around with adding drivers to anything before.
Any help would be greatly appreciated!
yes. i would also like to know how this is done.. please share. thanks
me 3! tell usssss
you would need a dev environment setup to cross compile for that device (your phone) then compile the source as a module and load it from a command line. (insmod <module>). if you get a new line in the terminal without error, its loaded.
thanks! ill try this later..
nenn said:
you would need a dev environment setup to cross compile for that device (your phone) then compile the source as a module and load it from a command line. (insmod <module>). if you get a new line in the terminal without error, its loaded.
Click to expand...
Click to collapse
What if you don't (or don't want to) have root access on the phone?
well this guy in his thread is loading a lot of drivers *.ko i thing?
helpful?
*edit* forgot the link
http://sven.killig.de/android/N1/2.2/usb_host/
Any answers?
I'm looking for the same thing: I want to install a new driver on Android devices, but I can't Root the devices - I need to add the driver(s) to stock Android installations.
Just curious.. why do so many ppl seem to add driver to their system? :/
My task is similar to noted earlier.
I want to make "virtual driver". In other words, the device doesn't have specific hardware and I need to emulate it programmately.
Any hints and links would be useful.
Thanks.
jkoshi said:
What if you don't (or don't want to) have root access on the phone?
Click to expand...
Click to collapse
I think you would need root access on your device in order to load your kernel module: 'insmod your_module.ko' or whatever.
- jc
Hey i was looking to do this exact thing so i could connect a mimo monitor to my phone any progress or step by step instructions
Subscribed
you need to have right kernel module compiled on the same kernel version that you android is running on.
it is a may be not only *.ko file, but it may need also another firmware files.
if it is only one file, you are lucky, you need just that ko file with right kernel version and put to vendor directory with modules.
and if not automaticaly loaded, you must call insmod command from rc file on device boot or manually from terminal.
better solution is to compile kernel yourself with driver inside it.
for details see 'linux kernel modules'.
Note: for sure you need root access to such as system modify operations...
And here : https://hex.ro/wp/blog/compile-an-android-kernel-module-outside-the-kernel-source-tree/
" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Great work! With this base, can yout get something like CW to run?
I'm so waiting for him to come back and say April fools.
I'm gonna screw him up if this was an april fool
First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?
vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.
)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.
Don't know alot about the bootloader, but what advantage does this have?
SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.
He said root with r/w access. Archangel won't do that, the file system is still protected.
pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.
Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.
Hello everyone,
This thread previously was a discussion area for the Ouya Boot Menu feature during its early development.
It's now being transitioned to a support area. The new project description/download page is at:
http://forum.xda-developers.com/showthread.php?t=2499673.
Thanks!
CWM Bootloop
Hal9k+1 said:
Hello everyone, attached is the ZIP of an updated CWM Recovery IMG file.
This image is based on the latest stock Ouya kernel in GitHub. The kernel contains some newer HDMI code, which will hopefully increase the chance of getting the CWM graphics showing up properly. I also turned off HDMI’s HDCP in the compile (not needed for a utility partition such as this), and grabbed a patch from Kulve’s Ouya kernel fork to really ensure HDCP bypass.
More importantly, the image contains Tasssadar’s excellent work involving KExec-HardBoot. This technology should allow for the implementation of a “fastboot boot”-related capability from a running ROM, enabling kernel chain loading. The recovery image in particular will be a place to practice with KExec-HardBoot, and come up with a booting method that could eventually be flashed to the boot/kernel partition.
It is fine (and recommended) to fastboot to this image as a quick verification of things. However, it will be necessary to flash to the Recovery (“SOS”) partition for proper testing of KExec-HardBoot, since there’s an embedded reboot (to Recovery in this case) in there. Do *NOT* flash this to the Boot.
A simple chain load test can be done by extracting “zImage” from this image, and “initramfs.cpio.gz” from your current ROM kernel. (Included is “unmkbootimg” that can help here - runs on Linux.) Push these to /tmp on the Ouya while it is running this image. Then enter the Ouya shell and do:
kexec --load-hardboot zImage --initrd initramfs.cpio.gz --mem-min=0xA0000000 --command-line=”$(cat /proc/cmdline)”
kexec -e
It should come up with this new kernel under your current ROM’s environment. As verification, you should see kexec files under /sys/kernel.
I’m looking to implement a basic chain loading application. It would come up before the Recovery and ADB services, and do the following:
% Pause for a bit, to allow any Alt-SysRq keyboard action (jump to Recovery or Bootloader) that may be needed.
% Check for any attached USB mass-storage devices (e.g., thumb drive), and look for the file “kernel.img”. Pull it in and boot it if present.
% If that failed, then look to “/system/kernel.img” on the Ouya itself, and boot it.
% And if that didn’t pan out, then exit and allow Recovery/ADB services to come up.
I hope all of this will be of help to others along the way!
Click to expand...
Click to collapse
Will this help with the problem I have?..
New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz
View2Askew said:
Will this help with the problem I have?..
New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz
Click to expand...
Click to collapse
Sorry, I'm not sure I understand. It sounds like the new stock firmware update is failing to go in, perhaps because of consistent download corruption. Whether you're actually being dropped in to the recovery partition is unclear. You might try the download again with the other networking type (Ethernet vs WiFi). You might also just disconnect from the network for the time being, and see if you remain in the firmware without interruption. From there you can consider setting up ADB to see if you can administer the Ouya from a PC.
My post is more for the developers at heart, just in case my investigation piqued anyone's interest. Ideally the post would go in the Development section, but I evidently need a few more posts here to unlock that area.
Best of luck!
Dual booting
Yes, please do enable dual/multi booting
Is there something I can do to help in that regard?
kulve said:
Yes, please do enable dual/multi booting
Is there something I can do to help in that regard?
Click to expand...
Click to collapse
Thanks kulve, and thank you for the kernel patch set. I need to get familiar with the offerings there.
I don't see any blockages in my plan so far; I just need to start in and see what comes up. At least it's a better feeling than the dead-ends encountered with the U-Boot and regular KExec investigations.
Someone more enterprising could possibly port in the MultiROM project, but I'll stick with this. Will let you know if I get stuck.
My findings so far...
- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)
- I see how to pull the kernel and ramdisk out of an Android image (on the Ouya itself), so that they could be passed to KExec-HardBoot. I've done it with a script as a test but it may end up in an executable.
- I tried out a USB thumb drive. It's detected but no block device is made available under /dev -- I've finally decided that support is likely in a kernel module, which does not exist on the Recovery image. I'm probably not going to sweat this due to the next item.
- I notice that the CWM application can read the Ouya power button as something comparable to a keyboard key press. Borrowing this capability may allow us to count the button presses in a limited time range, and thus boot an appropriate image. (Would be easier than dealing with the pairing of the controller, but at least still wouldn't require a keyboard.) With this line of thought, I'm thinking the main image could sit in /system while any alternates could be in /sdcard or /data.
So in general, studying the code of the CWM application appears to be the next direction. Thanks - feel free to send any ideas.
Hal9k+1 said:
- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)
Click to expand...
Click to collapse
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).
kulve said:
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).
Click to expand...
Click to collapse
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!
Hal9k+1 said:
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!
Click to expand...
Click to collapse
I noticed your comments related to this on the "Ouya CWM Recovery" thread but I'm not allowed to post there, so I'll post here.
Or actually repost as I'm mostly repeating myself. I had all kinds of issues in getting output using /dev/graphics/fb0 in Linux with the stock Ouya kernel but after some fixes the fb1 seems to work quite reliable. I get the output even if I don't have HDMI plugged in during the boot and it chooses the right resolution both for my TV (1080p) and for my monitor (1680x1050).
To all: I have updated the attachment that's present on the first post. I've synced to the latest Ouya kernel and pulled in the next HDMI patch set from Kulve. My HDMI issue now appears to be fully resolved.
Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.
With this handled and due to my thinking in general, I'm going to back away from trying to compile CWM itself -- I don't want to invest in CM10.1's environment at this time. Instead I will borrow CWM's UI and input technology to build an independent front-end with this Ubuntu/glibc environment I have working. My idea is to release another Recovery image when that's ready so we'll have a chance to practice/debug before moving to the Boot image.
Hal9k+1 said:
Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.
Click to expand...
Click to collapse
Hit the Thanks button
Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.
ooo nice, ill try it out and see what happens
kulve said:
Hit the Thanks button
Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.
Click to expand...
Click to collapse
Done! :laugh:
My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.
Hal9k+1 said:
Done! :laugh:
My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.
Click to expand...
Click to collapse
Any chance of getting some concise installation instructions?
zondajag said:
Any chance of getting some concise installation instructions?
Click to expand...
Click to collapse
Here's a quick executive summary until I can update the 1st post.
I'm reminded there's another XDA project (Ouya Safe Recovery) with a very similar goal as this, and works by reversing the Boot and Recovery concepts. However it's completely incompatible with us, and those users should not be doing any flashing -- at least not until we have a Boot image ready.
First step is to get rcvy092613.img to the Ouya in its /tmp directory. This may be done with an "adb push rcvy092613.img /tmp" command, or can by done through Secure Copy if an appropriate SSH server is set up.
Next step is to access the Ouya shell, either running from the main ROM or from a Recovery ROM. Be sure to become root (ensure "#" in the prompt) as needed.
Run the following to back up the old image:
cd /dev/block/platform/sdhci-tegra.3/by-name/
dd if=SOS of=/sdcard/old_rcvy.img
Make sure the new image is correct - should see "2a882d1ba8c2d543503cacb49ab0d397":
md5sum /tmp/rcvy092613.img
On to flashing Recovery:
dd if=/tmp/rcvy092613.img of=SOS
Now wait at least a full minute in case there is any internal flushing still taking place. And to finish up:
sync
reboot recovery
Aye....never enough time to tinker it seems, especially with getting over this flu.
At this point I have my own compiled code splitting the boot image file, as well as counting the power button clicks.
I want to see if I can make a welcome/instruction screen, probably by getting CWM's minui down to its core essence. From there it will hopefully just be normal integration work to achieve a new Recovery for testing.
Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.
Hal9k+1 said:
Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.
Click to expand...
Click to collapse
Did I read correctly that the image support multibooting?
kulve said:
Did I read correctly that the image support multibooting?
Click to expand...
Click to collapse
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.
So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.
Hal9k+1 said:
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.
So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.
Click to expand...
Click to collapse
My kernel is hard coded to mount the Debian (or whatever) rootfs from /dev/sdaX so Ouya's internal partitioning doesn't matter. It would be really cool to be able to put kernelA1.im to /sdcard, an USB flash drive to the USB port and boot to Debian without tinkering with adb/fastboot/etc. on a PC.
I'm not currently using any initrd-images but adding something simple should be straightforward.
I'm not sure if anyone will find this of use, but I did so I figured I'd post it for everyone to use:
I recently ran into issues running a few binaries on my V10. After doing a bit of research I found that non-PIE (position independent executables) will not run on newer devices (5.0+). Given I needed to run non-PIE binary, I looked further into a fix. This lead me to a thread posted here on XDA about bypassing the PIE check on Android L for the Nexus 5. Unfortunately the linker included in this fix is not usable by our device. Thankfully the linked thread goes into some detail about how to patch /system/bin/linker to allow non-PIE binaries. After reading into the provided information, I was able to patch our own linker and get my non-PIE binary to run just fine.
I've thrown together a flashable ZIP that simply replaces /system/bin/linker with a patched version that will allow non-PIE binaries. :good:
As a note:
Code:
[I]
[B][COLOR="Red"]
I HAVE ONLY TESTED THIS ON MY OWN LG V10 H901 ON MARSHMALLOW (6.0).
I CANNOT VOUCH FOR ANY OTHER MODEL, VERISION, OR DEVICE. AS ALWAYS
BE SURE TO PERFORM A BACKUP BEFORE FLASHING![/COLOR][/B]
I am, by no means, a developer. I simply dabble in Android for fun. I am not
responsible for any issue(s) caused by using this patch and you are doing
so at your own risk.
[/I]
So what this does is allow older non 6.0+ compatible apps to work?
Swizzle82 said:
So what this does is allow older non 6.0+ compatible apps to work?
Click to expand...
Click to collapse
It's helpful for any app with binaries that don't support position independent execution. In my case it allowed me to use my debugging server (which wouldn't run otherwise).
this works on the latest cm build for the htc one m8
but im a little confused as to which byte was modified can you please explain how you found which byte to replace i am using hex editor on my phone and cannot find the hex allocation mentioned in the forum
well i thought it worked until i went to restart my phone and it woudnt boot... thankfully tho i didnt delete the old linker file i just renamed it to linker.old so i was able to boot into my recovery and use its file manager to fix the issue
for now i guess i will create a script to automatically switch the file when i shutdown my phone and switch it back when it starts
Hi Guys!
I would be happy if someone could post a tutorial on how to Bypass PIE on Android 6.0.1
I have some experience in disassembling ELF files, but do not know where to look for disabling PIE in linker file. I would like to learn how to do it on my own, so i am not asking someone to patch my linker file.
Using G928F with Android 6.0.1
Thank you in advance!
Please help me to patch my linker
Works on Samsung J710MM (Marshmallow 6.0.1) perfectly. Thanx a lot!!!
Could anyone help me bypass PIE On marshmallow Touchwiz 6.0.1 would greatly appreciate your help?
Deleted
Hello, I have an m050 head unit and a USB flash stick as well as sdcard for music storage. The problem is that when the unit starts from a cold boot it starts up the built in music app and attempts to play where it left off but it starts quicker than the storage mounts so it doesn't initially find anything and defaults into shuffle mode. Then a few seconds later the storage auto mounts and starts playing random playlists. Is there a way to make the storage mount prior to the interface launcher running? The head unit is rooted.
^^ Bump. Nobody else has this issue where media mounts too late for apps that restore themselves on cold boots? I've tried searching quite a bit but have gotten nowhere useful.
Still nobody on this? Or anybody have a hint on what I should be searching for? Or maybe I should be posting in a different forum? I'm having no luck. Basically I'm looking for a way to cause the USB and sdcard's media to mount as early as possible even if that means it's recognized as permanent media instead of auto mounting as removable just so it mounts and is available before the launcher starts when all the other apps that want to access it and the media scanner want to scan it so they don't error for not having the media available.
onedumslack said:
Still nobody on this? Or anybody have a hint on what I should be searching for? Or maybe I should be posting in a different forum? I'm having no luck. Basically I'm looking for a way to cause the USB and sdcard's media to mount as early as possible even if that means it's recognized as permanent media instead of auto mounting as removable just so it mounts and is available before the launcher starts when all the other apps that want to access it and the media scanner want to scan it so they don't error for not having the media available.
Click to expand...
Click to collapse
This is very hard to do. It is in the init.rc file in your ramdisk image in your boot image. If you create a new boot.img with inside the modified ramdisk.img image you can tweak this. However, on every new ROM you need to rework that image again. And you need to be able read/write in the android init language, which is used in this init.rc file.
And by the way: there are more of these init.*.rc files in the ramdisk giving you the ability to tweak your system (or brick it).
Edit: If you find entries to Cyanogenmod giving you other options: That is correct as Cyanogenmod uses a more Linux-like approach giving you way more options to tweak your system. This doesn't work on non-Cyanogenmod ROMs.
surfer63 said:
This is very hard to do. It is in the init.rc file in your ramdisk image in your boot image. If you create a new boot.img with inside the modified ramdisk.img image you can tweak this. However, on every new ROM you need to rework that image again. And you need to be able read/write in the android init language, which is used in this init.rc file.
And by the way: there are more of these init.*.rc files in the ramdisk giving you the ability to tweak your system (or brick it).
Edit: If you find entries to Cyanogenmod giving you other options: That is correct as Cyanogenmod uses a more Linux-like approach giving you way more options to tweak your system. This doesn't work on non-Cyanogenmod ROMs.
Click to expand...
Click to collapse
Thank you, I think I'm getting headed in the right direction. I started reading "Android Internals A Confectioner's Cookbook" and I'll be working with an already prerooted ROM. However, it is not a cyanogenmod ROM. Are you saying getting the sdcard and/or USB drive to mount from the ramdisk via the init.rc file is only possible on a cyanogenmod ROM? Or did you mean something else? For this use case I don't think I'll mind the work to rebuild the ramdisk and boot image if it's possible since I won't be getting updates often since it's on a head unit and if I can get the media player to stop going into random shuffle every time it boots up I will be so happy cause it's driving me crazy that it can't resume.
onedumslack said:
Thank you, I think I'm getting headed in the right direction. I started reading "Android Internals A Confectioner's Cookbook" and I'll be working with an already prerooted ROM. However, it is not a cyanogenmod ROM. Are you saying getting the sdcard and/or USB drive to mount from the ramdisk via the init.rc file is only possible on a cyanogenmod ROM? Or did you mean something else? For this use case I don't think I'll mind the work to rebuild the ramdisk and boot image if it's possible since I won't be getting updates often since it's on a head unit and if I can get the media player to stop going into random shuffle every time it boots up I will be so happy cause it's driving me crazy that it can't resume.
Click to expand...
Click to collapse
No that is not what I meant. I meant to say that you might have found easy solutions, but those were most possibly for Cyanogenmod. Within Cyanogenmod you have more easy options.
It is relatively easy to modify the ramdisk.img and boot.img (I did it many times when I still built ROMs for other tablets). However, there is always the chance to (soft-)brick your device. Fortunately these intel devices can only be soft-bricked and it is only necessary to flash your device again with a "standard" rom.
Note that all tools are Linux tools. Maybe some are available for Windows as well.
If you want to continue with this you should download the pack/unpack tools for boot images (but you can find these on many places).
And something I did not yet do on these Joying devices, so search for yourself:
- Replace the original boot.img with your modified boot.img in your unzipped Joying ROM and flash your unit (I think this is the simplest one).
(- Or write the boot.img directly to your unit using rkflashtools (and this requires knowledge of the partitions on your system, but I do not even know whether these Rockchip flashtools als work on the Inte/Rockchip sofia units))
surfer63 said:
No that is not what I meant. I meant to say that you might have found easy solutions, but those were most possibly for Cyanogenmod. Within Cyanogenmod you have more easy options.
It is relatively easy to modify the ramdisk.img and boot.img (I did it many times when I still built ROMs for other tablets). However, there is always the chance to (soft-)brick your device. Fortunately these intel devices can only be soft-bricked and it is only necessary to flash your device again with a "standard" rom.
Note that all tools are Linux tools. Maybe some are available for Windows as well.
If you want to continue with this you should download the pack/unpack tools for boot images (but you can find these on many places).
And something I did not yet do on these Joying devices, so search for yourself:
- Replace the original boot.img with your modified boot.img in your unzipped Joying ROM and flash your unit (I think this is the simplest one).
(- Or write the boot.img directly to your unit using rkflashtools (and this requires knowledge of the partitions on your system, but I do not even know whether these Rockchip flashtools als work on the Inte/Rockchip sofia units))
Click to expand...
Click to collapse
Thanks a bunch, I appreciate that. I'm gonna see if I can get traction today on replacing the boot.img route. I should be fine with the utilities, I'm on osx and can create a Linux VM as well as having a Windows too. Any recommendations on mount point paths for the the sdcard and USB stick? Currently the auto mounter puts them in /mnt/external_sd1 and /mnt/external_usb1. So I was wondering if I should put them in the same location or put them in /system or my guess is I should put them on new paths in /mnt as I believe I saw the init.rc creates /mnt on the root filesystem on every boot.
Post deleted. My answer was for a joying intel head unit. The head unit in this topic is not an joying intel head unit.
surfer63 said:
One thing I forgot which makes your task almost impossible if you want a "straight" ROM update.
the boot.img is inside the 5009_20.zip. As such you can easily replace that boot.img but the 5009_20.zip is a signed zip. You never get the original signing back which means that you won't be able to create your own "custom" rom as the ROM upgrade/update process will not accept it.
In other words: you need to do some direct replacing of the boot.img.
something like
Code:
adb connect <unit ap-address>
adb root
adb shell cp boot.img /sdcard/
adb shell dd if=/sdcard/boot.img of=/dev/block/mmcblk0p9
adb shell reboot
Note: I did NOT test this this!! Always check beforehand which block device you need to replace!
Click to expand...
Click to collapse
I'm not sure this applies to mine? I've since found that I need to use the imgrepackerrk tool for unpacking and repacking for my specific ROM for RK chips. So far I've successfully unpacked everything so I can test out editing but I have not been successful yet due to the utility having a bug that affects just my ROM on repacking. The bug has been fixed in his windows version of the utility but not on the Linux so I need to set up my windows VM to repack in windows which I haven't done yet. I'll be trying it out this weekend.
onedumslack said:
I'm not sure this applies to mine? I've since found that I need to use the imgrepackerrk tool for unpacking and repacking for my specific ROM for RK chips. So far I've successfully unpacked everything so I can test out editing but I have not been successful yet due to the utility having a bug that affects just my ROM on repacking. The bug has been fixed in his windows version of the utility but not on the Linux so I need to set up my windows VM to repack in windows which I haven't done yet. I'll be trying it out this weekend.
Click to expand...
Click to collapse
Sorry. my mistake. I have an intel joying and I'm constantly in intel joying threads. Above does indeed not apply to you. I will remove it.
Hello team,
I have the same problem with my Joying unit, and I don't find solution. I have a lot of MP3 in a usb key, but always the same issue when I start my car : music player starts but playlist is lost, mp3 not available. I need to wait a lot of seconds/minutes to load all MP3.
For info, I used original media player, but also Pi & Pulsar ... same issue
I tested with usb key, smal, medium, large, hard drive SSD ... but nothing
Did you find a solution to start music correctly when unit starts ?
Thanks.