[REQUEST] To any ROM & Kernel developers - Nexus 6 Q&A, Help & Troubleshooting

Hi,
I have a feature request for all ROM & kernel developers to add kernel level support into Android in order to successfully emulate a USB Keyboard & Mouse.
Once the kernel has the patches you can use this app to make your phone act as a USB keyboard and mouse:
https://play.google.com/store/apps/details?id=remote.hid.keyboard.client
In order to apply the patches this Github link explains everything you have to:
https://github.com/pelya/android-keyboard-gadget#compiling-kernel
Also, due to SELinux restrictions, the kernel has to be set to permissive however the guide also explains how to edit the kernel to get it working when the kernel is enforcing.
Please can any developers add this as it would be a nice addition to have in Android.
Thanks for reading

thenoobdev said:
I have a feature request for all ROM & kernel developers to add kernel level support into Android in order to successfully emulate a USB Keyboard & Mouse.
Click to expand...
Click to collapse
Android already supports keyboards and mice so how would adding kernel level support improve things?

Related

[KERNEL] Building additional modules for JB stock kernels

Some background info:
I'm the author of PPP Widget which is an app that enables mobile data connections on Android devices with USB host capabilities - even if they are WiFi-only.
It turned out that many Android devices have the drivers for 3G sticks already on board, included with the stock kernel. The one large exception are Samsung devices ...
I started to provide the missing drivers as modules (mostly "ppp_async" and "option" which depends on "usb_wwan"). That worked well for some Google devices and also for Samsung devices running ICS, using the source packages from
http://opensource.samsung.com/
In their JB kernels though, Samsung enabled the "MODVERSION" option. Furthermore, compiling the modules with the officially recommended toolchain resulted in a different "module_layout" checksum than in the modules provided in the firmware.
This prevents using any additonal modules on the devices. "insmod" refuses to load these modules.
The only explanation for this problem is that the custom device configuration provided in the source packages does not match the configuration of the device kernel.
This is the case for all GT-P31xx and GT-P51xx models as far as I can tell.
My take is that Samsung is required to provide the correct kernel configuration under the rules of the GPL. Maybe anyone else wants to contact Samsung on this behalf; I already did several times - still waiting for an answer ...
That's the reason why I build everyting from source including the GPU driver and lost exFAT support http://forum.xda-developers.com/showthread.php?t=1859227 and the boot image result http://forum.xda-developers.com/showthread.php?t=1855700 .
ketut.kumajaya said:
That's the reason why I build everyting from source including the GPU driver and lost exFAT support
Click to expand...
Click to collapse
Unfortunately, replacing the kernel is no option for end users. The modules I provide are going into a folder on the sdcard, and can be "insmod'ed" from there with no problem - once their magic string and the "modversions" are matching the kernel on the device. The latter is the wall I'm hitting ...
JFDee said:
Unfortunately, replacing the kernel is no option for end users. The modules I provide are going into a folder on the sdcard, and can be "insmod'ed" from there with no problem - once their magic string and the "modversions" are matching the kernel on the device. The latter is the wall I'm hitting ...
Click to expand...
Click to collapse
Thanx alot for such a great development. ...
Adi™
Creator Of Sungsonic™HD
I have received a reply from Samsung. They have updated the JB open source package for GT-P3110, GT-P5110 and GT-N7100 (which previously included a config file from 3.0.15 for a kernel version of 3.0.31 !!).
Unfortunately, the modversions of the compiled kernel are still different and incompatible. I have replied with these finding.
Waiting again ...
BTW, the only recent kernel config consistent with the actual device kernel that I have found is for the GT-N8000 (3.0.31). So it is possible to provide a matching configuration.
JFDee said:
I have received a reply from Samsung. They have updated the JB open source package for GT-P3110, GT-P5110 and GT-N7100 (which previously included a config file from 3.0.15 for a kernel version of 3.0.31 !!).
Unfortunately, the modversions of the compiled kernel are still different and incompatible. I have replied with these finding.
Waiting again ...
BTW, the only recent kernel config consistent with the actual device kernel that I have found is for the GT-N8000 (3.0.31). So it is possible to provide a matching configuration.
Click to expand...
Click to collapse
If You will start to work with kernel I'm willing to beta test with my P5110. Only issue for me is that I need to know what 3G dongle to buy (well need it anyway so would prefer an advice from someone who know something about it). I'm living in Poland and Ireland (once here once there) so I can even test LTE modems (well donations here, myself can spend up to ~50€ on 3G one) because in Wroclaw, Poland I heard it's quite good, also I got H+/H on SGSII here. While in Ireland signal is not THAT strong due to fact most of places are quite remote (except Dublin, Galway etc). Hope I can help in either way
This is what I wrote to Samsung concerning the botched configuration file provided with the latest GT-P3110 kernel source:
Thank you for the source code update.
However, I have asked for the kernel configuration that matches exactly the kernel on the GT-P3110.
I have compiled the kernel from the provided update, but the module layout checksum does *not* match the one from the kernel running on my device.
On the device: module_layout 0xb5a27644
From source: module_layout 0x143474f1
I have used the recommended toolchain "CodeSourcery 2010q1" and the unchanged config file provided with the source ("android_espresso_omap4430_r04_user_defconfig").
Please be aware that you are obliged by the GPL to provide the correct config file for the binary kernel that you are distributing.
As a side note: the configuration provided with the kernel source for the GT-N8000 *does* match the kernel on the device, so there is no doubt that it is possible to get the configuration right.
Other Android vendors are just enabling the "embedded" config file in the kernel, so that the correct configuration is simply available on the device as "/proc/config.gz". This is so much less trouble. I suggest that you enable this option for Samsung kernels too.
Regards,
...
Click to expand...
Click to collapse
The GT-N8010 is also in the same situation you describe - config for 3.0.15 and jb stock kernel at 3.0.31, can't build working modules for stock.
davp, there seems to have been some activity at the Samsung open source center after my messages.
I suggest you make yourself heard as well. Use the "Inquiry" button next to the package download link in the table for your device.
To be able to add working modules to the device, the kernel configuration for the source has to be 100% compatible. It does not matter if any closed drivers are missing as we don't want to replace the kernel - but all those general debugging config options should be correct.
BTW, there is a history of similar issues:
http://forum.xda-developers.com/showthread.php?t=1123643
The kernel source for the GT-P3110 has been updated once more, and this time they have fixed the configuration.
With the latest JB update we can actually build working modules for the current firmware.
I confirmed this to the Samsung people and reminded them of the other devices in need of this fix: GT-P3100, GT-P5100, GT-P5110, GT-N7100 and probably more (like the GT-N8010).
JFDee said:
The kernel source for the GT-P3110 has been updated once more, and this time they have fixed the configuration.
With the latest JB update we can actually build working modules for the current firmware.
I confirmed this to the Samsung people and reminded them of the other devices in need of this fix: GT-P3100, GT-P5100, GT-P5110, GT-N7100 and probably more (like the GT-N8010).
Click to expand...
Click to collapse
So for now we might get stock kernel which will support 3G modems via USB OTG? How about other kernels such as CM10.1?
I'm looking for good 3G dongle then Any advices?
Additional kernel modules for stock JB P31xx (tested) and P51xx (untested), contains:
- usb_wwan, ppp_async, and option module for PPP Widget
- dns_resolver, md4, and cifs module for cifs/samba filesystem support
- sunrpc, lockd, and nfs module for nfs filesystem support
Kernel config file attached.
FTDI Single Port Serial Driver added.
cifs.ko not working on P3100 JB 4.1.2 (stock rooted)
ketut.kumajaya said:
Additional kernel modules for stock JB P31xx (tested) and P51xx (untested), contains:
- usb_wwan, ppp_async, and option module for PPP Widget
- dns_resolver, md4, and cifs module for cifs/samba filesystem support
- sunrpc, lockd, and nfs module for nfs filesystem support
Kernel config file attached.
Click to expand...
Click to collapse
Hi ketut.kumajaya,
I'm trying to use cifs.ko but i get:
/system/lib/modules # insmod cifs.ko
insmod: can't insert 'cifs.ko': unknown symbol in module or invalid parameter
I have:
/system/lib/modules # uname -a
Linux localhost 3.0.31-1084989 #1 SMP PREEMPT Mon Mar 25 14:53:07 KST 2013 armv7l GNU/Linux
I tried other cirs.ko with same result.
Can you give me some clues of what can I do?
Thank you.
Try insmod in order:
insmod dns_resolver.ko
insmod md4.ko
insmod cifs.ko
If something goes wrong, see the kernel messages using dmesg.
ketut.kumajaya said:
Try insmod in order:
insmod dns_resolver.ko
insmod md4.ko
insmod cifs.ko
If something goes wrong, see the kernel messages using dmesg.
Click to expand...
Click to collapse
Great!!!
That's the solution.
In my Tab 10.1 4.0.4 I'm loading (different kernel and different modules, of course):
insmod cifs.ko
insmod md4.ko
insmod nls_utf8.ko
So I was not thinking I should use a different order.
Thank you.

cifs.ko for Abominable Snowman

Desperate for proper cifs support, I tried out the STOCK PLUS rom from the forum but unfortunately it doesn't seem to support unicode characters (I assume the dev hasn't included nls_utf8.ko).
So what I'll do is to compile cifs.ko, nls_utf8.ko, md4.ko myself for the newest build of Ouya firmware that I can obtain, and share them here with people.
However since I'm a noob on this I need somebody to first give me a direction on how to compile the kernel modules. I've searched online but there doesn't seem to be a good tutorial anywhere. Apparently for many people it should be a piece-of-cake task though. If someone does respond and teache me the instructions then I'll do all the manual work and compile these things.
Hopefully eventually this post would be helpful for other people as well - I might compile other modules on demand and share here if I learn how in the end.
EDIT:
OK, apparently you'd need to configure the kernel and compile it with utf8 support.
1. clone this repo: https://github.com/ouya/ouya_1_1-kernel
2. follow the step-by-step kernel configuration tutorial at http://forum.xda-developers.com/showthread.php?t=2110842
3. note when you run 'make menuconfig'; remember to tick the utf8 option in the native language support section
I haven't had time to do this but theoretically it should give you the correct result.
Additional note:
Although STOCK PLUS does not support utf8 charset for smb (confirmed); it does support utf8 for nfs so you can instead do a nfs setup.

[KERNEL] [KEXEC] Kernel EXECution for locked devices [N900V] [WIP]

THIS THREAD IS WIP & FOR DEVELOPERS ONLY !
Technical information with sources & binaries is in post #2. It includes kernel building, kexec-module, kexec-tools, hijack script, required patches & current problems with logs.
Click to expand...
Click to collapse
What is kexec?​--------------------------------------------------------------------------------------------------------​
kexec or kernel execution is a module/mechanism of the kernel that allows live/hot booting of a new/custom kernel "over" the currently running kernel. For more info, read the useful threads/links bellow.
kexec could be used to load a custom kernel into memory & yes, we'll then be able to install AOSP ROMs or in general run a custom kernel compatible with our device.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Updates:​--------------------------------------------------------------------------------------------------------​
[09/01/2014]:​
kexec module has been successfully patched & loaded/inserted into both NC2 & NC4 stock kernels. Now, I'm working on compiling/loading a guest kernel & fixing possible problems/bugs.
Click to expand...
Click to collapse
[08/31/2014]:​
Two versions of HLTEVZW KK kernel have been compiled from source: one uses the default configurations & the 2nd adds custom capabilities & kexec boot options. Moreover, kexec-tools & module have been cross-compiled. Now, I'm working on patches for kexec module & guest kernel (the hardest part).
Click to expand...
Click to collapse
[08/01/2014]:​
I've successfully flashed a custom kernel on my device. This trips knox flag & isn't 100% related to kexec, but it has the same objective (loading custom kernel on the locked-bootloader devices). However, the bootloader makes security check & blocks the installed kernel with the "unauthorized software by VZW" warning. Then, I tried to patch the bootloader to remove this security check, but my device was HARD BRICKED. Now, I've created a General thread for how to recover from a HARD BRICK. This is promising info for testing bootloader exploits.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
​​
Status
--------------------------------------------------------------------------------------------------------​
Supported NC2 & NC4 kernels
Working kexec-tools
Loaded kexec module
WIP kexec/guest kernel​
Click to expand...
Click to collapse
Thanks to / Credits:
--------------------------------------------------------------------------------------------------------​
@sextape - for the leaked NC2 firmware
@Hashcode - for his great work on kernel/recovery
...
Please PM me if I forgot to add proper credits for your work!​
Click to expand...
Click to collapse
​
XDA:DevDB Information
KEXEC, Kernel for the Verizon Samsung Galaxy Note 3
Contributors
hsbadr, CalcProgrammer1, ryanbg
Kernel Special Features:
Version Information
Status: Testing
Created 2014-07-11
Last Updated 2015-02-15
Technical Information
This post is reserved for technical information with sources & binaries. This includes kernel building, kexec-module, kexec-tools, hijack script, required patches & current problems.
Kernel Building:
--------------------------------------------------------------------------------------------------------​
The first step for building working kexec-module & tools is to cross-compile the kernel from source with the correct configurations. I won't describe how to build a kernel from source, but you may find this thread very useful.
I've used two different sources for the NC4/NC2 HLTE_VZW KK kernels. The 1st one is a part of SM-N900V_NA_KK_Opensource.zip released by Samsung for N900V NC4 kernel while the 2nd is available on @Hashcode's Github profile with 3 branches: hltevzw-kk-nc2 branch is modified for N900V NC2 kernel + 15 commits for compiling kexec as a module & other kexec patches.
The instructions provided by Samsung to build the NC4 kernel are to update CROSS_COMPILE toolchain environment variable in the Makefile & build with the default configurations as follows:
Code:
export ARCH=arm
make VARIANT_DEFCONFIG=msm8974_sec_hlte_vzw_defconfig msm8974_sec_defconfig SELINUX_DEFCONFIG=selinux_defconfig
make
However, I've patched the sources & used menuconfig interface to customize kernel configurations as follows:
Code:
export ARCH=arm
make VARIANT_DEFCONFIG=msm8974_sec_hlte_vzw_defconfig msm8974_sec_defconfig SELINUX_DEFCONFIG=selinux_defconfig menuconfig
make
(menuconfig is added in the second line)
The default output is the kernel image (arch/arm/boot/zImage) & modules (drivers/*/*.ko). The kexec-module(s) will be built if you patched the sources & configured it as a module.
You may then use dtbTool to generate device tree dt.img & mkbootimg to pack the kernel in boot.img.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Kexec Module:
--------------------------------------------------------------------------------------------------------​
There're many different flavors of kexec-mod sources. @delewer in this thread uses a standalone kexec-mod source MOD'd for Sony Xperia Z1 to be cross-compiled against the precompiled kernel source while @Hashcode in his sources on Github patches the kernel source to cross-compile kexec-mod with the kernel. Some modules may or may not use/port the hardboot patches. The output for kexec module/drivers have different names (the standalone kexec-mod source generates kexec_load.ko & procfs_rw.ko while the kernel source patched by @Hashcode generates 3 modules: arm_kexec.ko, msm_kexec.ko & kexec.ko).
To test if the cross-compiled modules are loadable & have the correct kernel headers, use insmod in terminal emulator (or a safe point with terminal like Safestrap) to insert the module into the kernel (assuming you've kexec.ko in /system/lib/modules/):
Code:
insmod /system/lib/modules/kexec.ko
Then, use lsmod to list & show the status of loaded modules:
Code:
lsmod
Alternatively, you may check if system call of the kernel includes kexec functions using:
Code:
cat /proc/kallsyms | grep kexec
The kexec-modules I've compiled are loadable & have been successfully inserted into both NC4 & NC2 kernels.
I'm using my own sources for kexec-module based on others & I'll share the sources with binaries & modules after making some required tests.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Kexec Tools:
--------------------------------------------------------------------------------------------------------​
I'm using the latest version of kexec-tools from here (currently, kexec-tools-2.0.8.tar.gz) cross-compiled for arm with custom configurations. Three binaries are generated including kexec (directly boot into a new kernel) & kdump (display kernel trace data). For more info, check the manpage of each binary & kexec/kexec-tools manuals/guides.
To test your kexec-tools cross-compiled binaries for arm,
Code:
kexec --help
assuming that they're in your PATH (e.g., /system/xbin) with executable permissions (e.g., 755).
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Hijack Script:
--------------------------------------------------------------------------------------------------------
will be updated soon...​
Click to expand...
Click to collapse
Required Patches:
--------------------------------------------------------------------------------------------------------
will be updated soon...​
Click to expand...
Click to collapse
Current Problems/Logs:
--------------------------------------------------------------------------------------------------------
will be updated soon...​
Click to expand...
Click to collapse
Sent from my SM-G900V using Tapatalk
jr_718 said:
Sent from my SM-G900V using Tapatalk
Click to expand...
Click to collapse
My eyes about popped out the side of my head when I saw this! It says your in testing have you had any luck at all? Thank you thank you thank you BTW!
amebiasis said:
My eyes about popped out the side of my head when I saw this! It says your in testing have you had any luck at all? Thank you thank you thank you BTW!
Click to expand...
Click to collapse
I've tested several binaries for the same kernel version, but none works for now. I'll compile from source & see. However, please keep this this thread for devs discussions only until we release working kexec & guest kernel.
Trying to keep the n3 alive before the n4 arrives? Lol seriously though congrats and thank you. Hope you and the devs here the best of luck. We, the re owners, appreciate all you have done already for us.
bmwh0r3 said:
Trying to keep the n3 alive before the n4 arrives? Lol seriously though congrats and thank you. Hope you and the devs here the best of luck. We, the re owners, appreciate all you have done already for us.
Click to expand...
Click to collapse
Note 4 is useless until it gets root & custom ROMs. For me, it'll be better ONLY IF we can break its security & unlock bootloader!
What about surge & ryanbg and e.v.a. I been following them and they both have a good idea on how things work well I think they are good for the job
Just a thought I had when unlocking my spare RAZR hd, but the kernels on the Razr and my note 3 are 3.4.97 and 3.4.0. Is the exploit part of the kernel or is there a reason I'm a user and not a Dev? If it is, motopacalypse.apk is what unlocked my RAZR. I'm just trying to learn so please don't think I'm a moron. I just don't know the coding aspect of android at all.
Have you got an irc or hangout open for discussion?
Thanks for your efforts! !
tpike said:
Have you got an irc or hangout open for discussion?
Thanks for your efforts! !
Click to expand...
Click to collapse
There is #Galaxy-Note-3 on Freenode but it's really quiet in there most of the time.
Many forum lurkers like me have been anxiously waiting for this breakthrough! Don't give up! I also believe in donating to hardworking devs like you guys! Good luck...
I was an owner of a Motorola Defy and the day that it got KEXEC I was so exited.. so good luck for you guys! Nothing is impossible. :victory:
Feche said:
I was an owner of a Motorola Defy and the day that it got KEXEC I was so exited.. so good luck for you guys! Nothing is impossible. :victory:
Click to expand...
Click to collapse
Who was devs on kexec on defy?
ironfisted said:
Who was devs on kexec on defy?
Click to expand...
Click to collapse
Not sure
I've been working on kexec for a little while now with limited success. My biggest problem is the getting the 4 byte CRCs for the kernel symbols used by the kexec module. Same with a few other projects I'm working on. They compiled the NC2 kernel with MOD VERSION and CRC. I've compiled it from source, but there's so much work to be done my head is spinning.
ryanbg said:
I've been working on kexec for a little while now with limited success. My biggest problem is the getting the 4 byte CRCs for the kernel symbols used by the kexec module. Same with a few other projects I'm working on. They compiled the NC2 kernel with MOD VERSION and CRC. I've compiled it from source, but there's so much work to be done my head is spinning.
Click to expand...
Click to collapse
Good luck! Lots of us are waiting for this!
ryanbg said:
I've been working on kexec for a little while now with limited success. My biggest problem is the getting the 4 byte CRCs for the kernel symbols used by the kexec module. Same with a few other projects I'm working on. They compiled the NC2 kernel with MOD VERSION and CRC. I've compiled it from source, but there's so much work to be done my head is spinning.
Click to expand...
Click to collapse
Keep it up man, I understand the hard work involved in doing something like this, but it will definitely pay of in the end!!! Thank you for your hard work and dedication, you got a lot of people counting on you
Sent from my BajaRom "L" Themed Note 3
ryanbg said:
I've been working on kexec for a little while now with limited success. My biggest problem is the getting the 4 byte CRCs for the kernel symbols used by the kexec module. Same with a few other projects I'm working on. They compiled the NC2 kernel with MOD VERSION and CRC. I've compiled it from source, but there's so much work to be done my head is spinning.
Click to expand...
Click to collapse
I see. Let me know if you'd like to contribute to this thread. I'll update it soon with more details about the required patches & the preliminary results of my tests ––after releasing a new version of JasmineROM.
ryanbg said:
I've been working on kexec for a little while now with limited success. My biggest problem is the getting the 4 byte CRCs for the kernel symbols used by the kexec module. Same with a few other projects I'm working on. They compiled the NC2 kernel with MOD VERSION and CRC. I've compiled it from source, but there's so much work to be done my head is spinning.
Click to expand...
Click to collapse
I was told by a defy dev that we would have better luck contacting hp touch pad kernel devs. I guess their kernel is more like ours I guess. Idk. I never tried contacting dev from their yet

[PATCH] Kexec-hardboot patch

In this post, I would like to explain what kexec-hardboot patch is.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Unlike grouper's kexec-hardboot patch, this one only requires the host kernel to be patched. This is one of the improvements Tasssadar made, and I think it is pretty significant.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Kernel patch: https://gist.github.com/PatrikKT/50faf32e8931d51c0c9a,
This is the kernel patch. Only the host kernel needs to be patched.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_PROC_DEVICETREE=y
CONFIG_ATAGS_PROC=n # This one is turned on automatically, but it is not needed, so you can disable it.
All these options must be enabled.​
Userspace kexec binary: https://github.com/Tasssadar/kexec-tools
I had to change some things in kexec userspace binary because of some kernel bugs, complete description is in that repository. You can get statically built binary at https://github.com/Tasssadar/multirom/blob/master/install_zip/prebuilt-installer/multirom/kexec​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --dtb
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - he used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped him out with that, thanks.
For hammerhead, he has improved the patch a bit - only the host needs to be patched now and he has added support for DTB.
This thread was used as a template Credits to @Tasssadar for his Nexus 5 patch
Awesome people helping with our G2's development. Thank YOU!
patrik.KT said:
I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows to boot any kernel without changing the boot partition.
Click to expand...
Click to collapse
What benefit would there be to non-MultiROM users? (Just curious.)
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Any. Just any.
Actually I can't think of anything. It's only to bring the device to a full reboot to load a new kernel.
Odoslané z môjho HTC Desire 601
blastagator said:
What benefit would there be to non-MultiROM users? (Just curious.)
Click to expand...
Click to collapse
Not for common user, in epic4g kexec used by kernel devs to test a new kernel build without replace the existing kernel.
They just load a temporary kernel to test. Then that kernel will gone after a reboot.
Hope to see new kernels that support MultiRom! Great work man!
Would this allow a multiboot with AOSP and Stock roms?
AbdulrahmanAmir said:
it doesnt work while i have stock and the secondary is aosp (dU-dirty.unicorn) when i boot the secondary it works sound only but no display just black screen plzz help
Click to expand...
Click to collapse
The patch is not necessary at the moment, because of the locked bootloader. It's just for devs to be prepared with their kernel when we can unlock the bootloader, so that multirom will work as it should.
Odoslané z môjho HTC Desire 601
Thanks for your great thread. But there is no instruction about how we can add that patch to kernel source. Could you write more details about implanting this patch?
No response??
mohamaadhosein said:
No response??
Click to expand...
Click to collapse
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Hey, some changes need to be made to the patch.
On line 353, change the number from 22 to 21. Also, it has some errors when modifying head.S, which I had to fix manually..
But guys, my kernel is building with the latest multirom. This **** is going to maybe work soon!
I'll keep you all posted.
Thank you man
Guys, I think I've done it. Kexec hardboot patched kernel for 5.1.1 and thus multirom compliant, which I am preparing to build with twrp. this is very exciting.
When will it be ready?
Are you kidding me? No ETAs. I literally haven't even announce it yet and somebody asks for an ETA.... It will be ready once I test everything to boot well on my device.
patrik.KT said:
Download the patch file from first post and place it in the kernel root directory. Then you should use this command to check if there are any conflicts: git apply --check <path_to>.patch
If there are no errors, use this to apply: git apply <path_to>.patch
Sorry for the late response but I checked xda when I wasn't home and I forgot to reply when I got home
Odoslané z môjho HTC Desire 601
Click to expand...
Click to collapse
It says the patch is corrupted on the line 375

[WIP] PostmarketOS for motorola moto g5s

/wiki/Motorola_Moto_G5s(motorola-montana)
The kernel used is from motorola's repository, since working usb networking is a must have, I'm not so sure if I can rely on lineageos kernel(I'm not sure if it is a matter of a kernel or of the vendor/device tree I decided to play it safe) , so I decided to start from scratch.
Right now on the roadmap:
1. Clean up the messy commits and start from a new branch.
2. Get merged into postmarketos official repository. (I can do so right now, but I rather go back and re-do the commits, remove the unnecessary changes).
3. Fix DPI settings, default ones are optimized for Desktop.
4. Find out the right pixelformat to use with osk-sdl those will translate into charging/battery-sdl and Filesystem Encryption.
5. Get wifi, gps ,accelerometer, bluetooth audio working. (Wifi and accelerometer doesn't work for 100%, )
test gps/get it working, get accelerometer working ,fix DPI.
6. Lastly mainlining kernel, which is required to get the WIP postmarketos modem driver and 3D Acceleration working.
Optional:
1. Porting MultiROM and patching a kernel to support kexec-hardboot patch on our device.
Once I will get my internet back I will work on @up things and provide:
1. Instructions on getting this linux distribution compiled.
2. Fastboot bootable kernel and sdcard image. I would prefer for you to boot a kernel and using sdcard over a flashable zip image for now, disappointment guaranteed.
WIFI networking most likely doesn't work since I haven't created device/firmware-montorola-montana package with wifi firmware.
If you want to contribute hit me up, I have a very slow connection and possibly have it for couple of days, so I might not be able to do any work for some time.
I don't have enough posts to make a DEVDB nor a development thread, so take it as [Q&A] thread that will hopefully get me to the minimal number of posts I require.
I also can't post outside links apparently the repositories I here present are relative to postmarketos wiki, github, gitlab or codeaurora git.
Repositories:
Kernel:
/kubast2/kernel-msm
Wlan kernel module and firmware:
/MotorolaMobilityLLC/vendor-qcom-opensource-wlan-prima
/quic/la/platform/vendor/qcom-opensource/wlan/prima/tree/
For configs I use a twrp image of stock oreo, I will need to use some config files from that backup image in place of the wlan driver provided configs.
Device and proprietary repositories by the montana development team will be useful for reference of existing blobs and configuration files, while other device ports from postmarketos repository will be useful for reference on when they need to be placed within the rootfs of postmarketos:
/montanadevelopment
/postmarketOS/pmaports
Stock kernel is 32-bit, which is why USB tethering works on LOS14.1, which is 32-bit. Take a look at their trees:
github.com/kayesk
USB tethering fixed in ARM64.
JarlPenguin said:
USB tethering fixed in ARM64.
Click to expand...
Click to collapse
Alright thanks, I don't have notifications for xda-developers, I will build on the basis of your kernel and push the change.
I see your kernel is already on a mainlining effort front.
kubast2-farelka said:
Alright thanks, I don't have notifications for xda-developers, I will build on the basis of your kernel and push the change.
I see your kernel is already on a mainlining effort front.
Click to expand...
Click to collapse
Actually it was fixed in init scripts. Are you still working on this project?

Categories

Resources