Related
I realize people gave up slightly on the whole kexec thing over radio worries, but I now have the module compiling and inserting without error into the Droid2/DroidX gingerbread kernel. Next comes cross compiling the kexec-tools for userspace, to allow us to attempt inserting a different kernel.
To build, you'll need a compiled DroidX kernel from source, as well as the android NDK.
To build, make sure you have downloaded the DroidX GB kernel source and compiled it. There are guides everywhere on how to build Android kernels. Just make sure you use the proper cross compiler.
http://sourceforge.n....l.tgz/download
When you build, make sure to use
Code:
make mapphone_defconfig
Once the kernel is built, clone my repo and edit envsetup.sh to reflect the correct paths to your kernel source directory and the android NDK.
https://github.com/i...kexec-mod-d2-dx
Then, source it:
Code:
source envsetup.sh
Then, just run
Code:
make
and cross your fingers. You should then have a fresh kexec_load.ko file!
To see if it loads, you'll need to copy it to your sdcard, and then on the phone, using a console, do the following:
Code:
su (click allow)
insmod /sdcard/path/to/kexec_load.ko
If you don't get any errors, it inserted! Now, of course, to actually use it, we'd need the kexec-tools built, which I haven't gotten ready yet...but they're coming! To remove the module (no reason to leave it in memory for now):
Code:
rmmod kexec_load
Happy hacking, and help is always appreciated!
This looks great! If you need any help just ask
Thanks! I probably could actually use some. I'm looking at eternity project's git repos now, and am trying to figure out how they managed to get atags working, with the whole procfs thing...still scratching my head there.
I'm looking at eternity project's git repos now, and am trying to figure out how they managed to get atags working, with the whole procfs thing...still scratching my head there, though I do have an atags module working, except it doesn't do anything without atags in the procfs (http://lists.infradead.org/pipermail/kexec/2011-January/004795.html).
kexec-tools:
https://github.com/i...xec-tools-dx-d2
To build, see the README.
Then, copy the binaries from /build/sbin/* to your device, and the move them to the /system/bin directory, and chmod them 770 to make them executable.
mod-atags:
https://github.com/i...mod-atags-d2-dx
Now, if I/we can just get atags and procfs stuff taken care of, we'll be able to go to the next step. I already have atags compiling as a module, but it won't stay inserted because we have no atags in the procfs. Note I can't just trace through code like this and know what everything is doing, but I know enough to hack at it and be dangerous
I know this is kind of off topic, but would this help us people with Motorola Atrix 2? Does it use the same radio?
calebcoverdale said:
I know this is kind of off topic, but would this help us people with Motorola Atrix 2? Does it use the same radio?
Click to expand...
Click to collapse
No idea. I haven't even gotten the kernel to change yet, so I haven't gotten to mess with radio yet. The method itself should/would work though, but radio will require reverse engineering...perhaps find a similar phone with an open bootloader and disassemble and attempt to clone it's modules.
The latest change I made may or may not work, it was an attempt to remove atags from the kexec module based on an old patch I found, which added the functionality. This at leaset made kexec -l zImage work, but when I run kexec -e, the kexec binary complains about atags not being there...hrmmmph.
I may have to revert it (and will if we can get atags somehow) ...but if we can get the kexec bin to ignore /proc/atags or just find a way to rip them out of the running kernel, we'll be in business.
The commit: https://github.com/ilikenwf/kexec-mod-d2-dx/commit/12dffe0ea286be0fe9ab0303a5a35ed92be4ee2c
I'm also looking into 2ndboot.
I like where this is going! Keep working!
Sent from my DROID2 using xda premium
Okies, so, I emailed aliasxerog (original kexec-mod writer), and I hope he'll get back to me. Even though his twitter says he's a "former android developer," maybe he'll be willing to give me some hints so I can pick up where he left off.
I also got the froyo version of the module building properly based on his module, yet again, (all after SBF'ing my phone back down to motoblur froyo - yech!) but neither currently work... (note there's a gingerbread and a froyo branch on my repo): https://github.com/i...kexec-mod-d2-dx
The froyo one throws the following error, which stops me dead in the water:
Code:
Could not find a free area of memory of 3007dc bytes...
The gingerbread one loads the kernel into memory but won't execute it due to our not having atags.
We've moved our git repos to an organization for easier collaboration:
https://github.com/organizations/D2-DX-Customboot
links are imcomplete.
use URL lable pls.
Cross compiler version ?
hello,
Sorry but I am not able to use the sourceforge link that you provided to download kernel source .. Also please share what cross compiler version is to be used....
Thanks in advance.
Ok, I'm trying to do something fun with my phone... (Hisense EG909 MSM8625)
Since hisense is keeping the source code, so I'm trying to build the source from codeaurora.org ics branch M8625SSNSKMLYA1015 (to keep the same version with my current stock ROM)
I've successfully compiled the kernel with the ndk but I'm stuck on getting it to boot.
It just show the carrier logo (bootloader). I can't get the bootanimation to load.
I'm not expecting things like wifi / bluetooth or even the radio works... but I'm just trying to at least get it to boot the launcher
I have experience in c/c++ but I know nothing about android and just started to learn it...
Can anyone point me on how to debug or see what's wrong with the kernel?
Is there any way to show something on the screen? I mean turning on the frame buffer
I've search and tried many method like altering the command line "console=tty0", adding "CONFIG_MSM_FRAMEBUFFER", etc..
but seems like nothing works, it just stuck there...
the way I build is:
1. downloading code from caf
2. pulled config.gz from my working phone... but it require some hisense stuff. so I'm using the configs that come with the code
3. tried both msm7627a_defconfig and msm7627a-perf_defconfig,
4. extract current working boot.img
5. substitute the kernel with my compiled zImage, and repack the boot.img
Am I missing something here?
million thanks for your help...
Looks like you are missing some hardware drivers. Why not find the lines in defconfig mentioning "hisense stuff" and search at Google or "searchcode.org" to see if drivers are available. And then patch your source as necessary.
sharonsym said:
Ok, I'm trying to do something fun with my phone... (Hisense EG909 MSM8625)
Since hisense is keeping the source code, so I'm trying to build the source from codeaurora.org ics branch M8625SSNSKMLYA1015 (to keep the same version with my current stock ROM)
I've successfully compiled the kernel with the ndk but I'm stuck on getting it to boot.
It just show the carrier logo (bootloader). I can't get the bootanimation to load.
I'm not expecting things like wifi / bluetooth or even the radio works... but I'm just trying to at least get it to boot the launcher
I have experience in c/c++ but I know nothing about android and just started to learn it...
Can anyone point me on how to debug or see what's wrong with the kernel?
Is there any way to show something on the screen? I mean turning on the frame buffer
I've search and tried many method like altering the command line "console=tty0", adding "CONFIG_MSM_FRAMEBUFFER", etc..
but seems like nothing works, it just stuck there...
the way I build is:
1. downloading code from caf
2. pulled config.gz from my working phone... but it require some hisense stuff. so I'm using the configs that come with the code
3. tried both msm7627a_defconfig and msm7627a-perf_defconfig,
4. extract current working boot.img
5. substitute the kernel with my compiled zImage, and repack the boot.img
Am I missing something here?
million thanks for your help...
Click to expand...
Click to collapse
if you can't extract original defconfig (config.gz) from device, it would be hard to have bootable kernel.
Sent from my Oppo N1 using Tapatalk
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Steel01 said:
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Click to expand...
Click to collapse
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Unjustified Dev said:
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Click to expand...
Click to collapse
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Steel01 said:
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Click to expand...
Click to collapse
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at (removed) as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Unjustified Dev said:
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at https://github.com/CM-Shield as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Click to expand...
Click to collapse
Thanks, pm sent. Guess I'll fire off a full aosp build so we'll have the same trees available at that time.
Steel01
Edit: Today's just not my day. None of my builds from nvidia's aosp 4.3 r3 tree boot. A normal boot hangs at the shield logo. The recovery gives me the red triangle (not terribly surprised since nvidia's official gives me that too, only agrabren's cwm recovery works for me). I didn't think too much of it when I built off of openjdk 1.6, but now that I pulled sun's 1.6-41 and it still doesn't boot, I'm a bit miffed. Shouldn't be a reason why I can't build off CentOS. Maybe I'll load up a Debian or Mint VM and try building off that. I really don't want to touch Ubuntu which all the android docs are written for...
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Steel01 said:
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Click to expand...
Click to collapse
Did you get the closed source binaries extracted?
Unjustified Dev said:
Did you get the closed source binaries extracted?
Click to expand...
Click to collapse
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Steel01 said:
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Click to expand...
Click to collapse
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Unjustified Dev said:
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Click to expand...
Click to collapse
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Steel01 said:
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Click to expand...
Click to collapse
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Unjustified Dev said:
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Click to expand...
Click to collapse
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Steel01 said:
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Click to expand...
Click to collapse
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Unjustified Dev said:
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Click to expand...
Click to collapse
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Steel01 said:
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Click to expand...
Click to collapse
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Unjustified Dev said:
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Click to expand...
Click to collapse
Alright. If you haven't got the dtb stuff straightened out by the time I get back to my dev machine tomorrow night, I'll tackle that. I've had some hobbyist experience with that on some embedded dev boards. In general, I wouldn't think the dtb would ever change. Definitely not within a kernel version. Definitely needed, though. But in the spirit of open source and building as much as possible from source, it will be good to make that build. Shouldn't be too difficult. And yes, 1:30 AM does bad things to cognizance. *passes out*
Steel01
Edit: I took a look at the tf701t kernel tree this morning. The dtb part may already be done if we base from there. A dts file already exists for roth (arch/arm/boot/dts) and the make file a dir up appears to glob the dts directory and build dtb's for each. I don't have access to a build tree to verify that atm, though. Bit if that's true, the kernel should be as simple as cloning tf701t, renaming its defconfig and modifying what little differences there are if any, then copying the dtb to the out directory.
Edit 2: A bit of googling turned up http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree which says a config flag handles building dtb's. The tf701t config already sets CONFIG_MACH_ROTH=y, so I'm wondering if that kernel won't boot on the shield out of the box. Something I'll try once I get back to my dev machine tonight.
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Steel01 said:
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Click to expand...
Click to collapse
So far going to push unmodified kernel now https://github.com/CM-Shield/android_device_nvidia_roth
Progress finally. Got a cwm recovery that boots and looks like it works plus fits in the partition. Most of the buttons aren't mapped yet and the screen is rotated, but that should be the east part to fix.
Steel01
Getting closer. But still no dice. Logcat of current iteration.
Steel01
Since development for the Sidekick 4G has stopped I decided to try and port the CM11 M10 snapshot from the Galaxy S 4G using this guide. I used the Galaxy S 4G as port ROM since most of the specs are the same as the SK4G. The base ROM I used is ayoteddy"s KJ2 Deodexed & rooted ROM. I followed the guide and flashed the ROM I made but the phone didn't boot. It stays stuck at the tmobile startup screen and then bootloops. I took a logcat and see a lot of errors but idk how to correct them. I tried uploading the ROMs I used and the one I created but it only let me upload the logcat.
Hey,
Its awesome to see some more effort in this phone but when porting a ROM one of the main prerequisites is the base being the same android version.
So to port cm11 over you would need a kitkat kernel and ROM for the sk4g already.
What would be real helpful is to get the gingerbread kernel fully functional then any GB ROM could be ported fairly easily.
Or start with a kitkat kernel but both require a bit of work. If you want to take it on a can link a bunch of guides that may help
Thanks for that info. I don't have experience coding but I would like to be able to learn how to cook and port roms so I would really appreciate some guides. As I understand it, since there is no KitKat ROM available for the sk4g I would first need to make my own KitKat kernel and ROM before I would be able to port cm11? And how long do you think it would take to learn everything needed to be able to port and cook roms?
Hey,
On mobile right now so can't post a bunch of links but xda is filled with them
The best place to start would be http://www.xda-university.com
And be sure to check out the forum links as well!
For a quick set of links see the seventh post in this thread
http://forum.xda-developers.com/showthread.php?t=2348266
For a different device but those are all great places to start learning to develop for android
Keep me posted on your progress!
Took me a while to find some useful guides since I was searching with the term "port" and not "build/compile from source" since that is essentially what I'm doing. I used wiki.cyanogenmod.org/w/Doc:_porting_intro and wiki.cyanogenmod.org/w/Build_for_galaxysmtd (can't post links yet). I forked the galaxys4g repo and modified the files to be suited for the sidekick4g. Now I'm onto the building step, a couple of things already broke and I managed to fix them, but I ran into this error and haven't been able to fix it.
brunch sidekick4"ebtables is disabled on this build"
find: `src': No such file or directory
build/core/base_rules.mk:134: *** system/extras/ext4_utils: MODULE.TARGET.EXECUTABLES.setup_fs already defined by device/samsung/sidekick4g. Stop.
I researched the MODULE.TARGET.EXECUTABLES.setup_fs already defined by device/samsung/sidekick4g issue and suggestions were to delete the setup_fs file within device/samsung/sidekick4g folder. However the setup_fs file wasn't in there, I did find a setup_fs.c file and deleted that one. Then I proceeded to try the build again and ran into the same error. Another suggestion was to use grep -R setup_fs *. This command pointed to these files,
Android.mk:LOCAL_SRC_FILES := setup_fs.c
Android.mk:LOCAL_MODULE := setup_fs
Android.mk~:LOCAL_SRC_FILES := setup_fs.c
Android.mk~:LOCAL_MODULE := setup_fs
initramfs/init.herring.rc:service setup_fs /system/bin/setup_fs /dev/block/platform/s3c-sdhci.0/by-name/userdata
sidekick4g.mk: setup_fs
But I don't know what exactly I'm supposed to delete. The device repo is located at github.com/SK4G/android_device_samsung_sidekick4g.git It is a pre-build attempt version before I made suggested changes to the local repo. I tried "git push origin master", the command went through and said everything is up to date but the remote repo still wasn't changed so I haven't been able to update it.
What are you using for the device tree? The relay is a completely different device and none of the drivers would work, did you at least pull blobs and proprietary files from a sk4g?
There is a ton of setup to be done in order to build from source, you can use the cm11 source but need to make a specific device tree for the sidekick to get a working build, not to mention a ton of kernel work will be needed
For the device tree I forked the galaxys4g repo (not the galaxy s relay 4g) and then modified the files to build the sidekick4g specific device tree. When pulling the blobs and proprietary files the guide said " Your device should already be running a build of CyanogenMod for the branch you wish to build for the extract-files.sh script to function properly". Not sure if that's relevant to the errors but I was still able to pull the blobs towards the correct ~/android/system/vendor/samsung directory. As far as the kernel I downloaded the stock kernel from the samsung source website and then put it in the kernel/samsung/sidekick4g directory. The guide said that the kernel and kernel modules would be built automatically as long as I made appropritate changes to the BoardConfig.mk and I did so. I have done every step in the guide and now I'm into building but I can't get past the previously mentioned error. Should I delete the whole part of the files mentioned by the grep -R setup_fs * command or just the red part or is there another solution?
Well the blobs that were pulled and the kernel that was used was for froyo, that won't work for kitkat without a weeks worth of modification
Also the s4 is even more different than the relay and would be much harder to use anything from there
What you need at this point is to create your own device tree on github and add this to your local manifest, then the hard part is to adapt the sk4g kernel into something that will work with kitkat, once this steps are complete you can build and then fix the errors that come up, fixing any errors at this point won't help much as the files used are incompatible from the start
I should have been more specific, I used the T-Mobile Galaxy S 4G which is one the first galaxy phones. It has the same hummingbird chipset, architecture, ram/rom size, resolution, and both originally ran froyo. The guide states that the cm buildbots build a compatible kernel for me. I didn't just fork the galaxys4g repo and leave it as is. I went through the files and substituted anything that was galaxys4g device specific to fit the sidekick4g.
No problem, should have read more clearly, yes the galaxy s is very similar minus the keyboard but you can look at the work that was done to get a GB ROM booting here
http://forum.xda-developers.com/showthread.php?t=2323617
This was done on the exhibit, another very similar phone,
Even after the kernel was adapted the keyboard never worked, you check the link to his github to see what was put into it to work
The kernel built by the bot won't adapt it to work between different versions of android so you need to build this manually first then you can use it, but even then there will be a lot to do in order to get the keyboard working
Now I'm beginning to understand what you have been trying to tell me. It was hard to grasp at fist because I never really looked into building a kernel since I usually just use the stock kernel or the cm built in kernel on my devices. Now I shall redirect my efforts into building a kernel
Hi I just wanted to know if you're still building port for the sidekick 4G I still have mine and I would like to use if you have kitkat to work. I miss my sidekick 4G
Sent from my Nexus 6 using XDA Free mobile app
Hey folks,
i'm trying to get a "vanilla" aka unmodified device tree for the Shield Tablet K1. I know that you can sync over from nvidia's gitweb, tough the device tree is looking weird.
When i look at let's say cm's android_device_nvidia_shieldtablet it looks different. So i wonder how i would go from nvidias mutated tree to cm's layout without actually just forking it from cm.
Reason is, i want to port another custom rom over to the shield tablet, but i can't neither figure out how i'd do that with nvidias sources, nor how i would create a device tree similar to cm's, without any modifications.
I googled around for about 2-3 months now and still have no clue, so if anyone could give me a hint, i'd be very grateful!
What's wrong with the cm tree?
Unjustified Dev did the initial port of everything by hand. I've done maintainance manually since then. And to my knowledge, there's only been one other person to do a manual conversion (vartom). All custom ROMs derive from my tree. Should work in aosp as well. If there's something you need different from the cm tree, you can just add it on top. Or if something is broke in general, I need to know and fix it.
There's nothing "wrong", just not " clean", if you catch my drift. It's just a matter of reverting inwanted things, but yeah.. feels dirty.
Anyways, thanks for the info, man.
*shrugs* Okay, if you want to set up a new tree, nothing's stopping you. I wouldn't mind someone else knowing how to do it (pretty sure I'm the only active dev that has experience there), but it's a lot of parsing and research. I'll say that CMs trees are 95% unmodified from Nvidia's upstream, though. It's just rearranged into an aosp style tree. The kernel is a merge of the console and tablet since they were 98% identical anyways. I do my best to keep everything as clean as possible since I don't want to do through the work of making a lot of modifications every time a new release comes out... Engineers are lazy like that. I think the only things that aren't pure identical copies are the LTE init files and the unified device stuff (making the wifi only and lte models work in one ROM).
Nah, don't get me wrong there, i don't want to discredit you there.
I'm more talking about cm specific things like gello browser and stuff. Like i said, just a matter of a few changes to not include these. I'm just a beginner in any way, i can just follow instructions at best, i don't know c, and almost no java at all. So what you do is an astounishing task - it's just a personal preference coming and starting with nexus devices to tinker around, i have had the luxury of an AOSP tree, that's pretty much "my dilemma". I'm unexperienced and thus this might take a while for me. I've started to modify your device tree the day before yesterday, but i have something done wrong, as when i start compiling it'll ask if it should use " full_eng" config. (6.0.1 is used)
Again, thanks for putting me in the right direction, also for your efforts in maintaining our device.
What ROM are you trying to build? You could look at Carbonrom or Blissrom to see the rename changes needed to use the tree in a different ROM. Those should be similar across the board. I think the only CM specific package references would be gello and snap. Those commits could be reverted easily enough. Or if the ROM doesn't have them, I think they'd be ignored even if left as is.
Hi,
you can take a look at here
the base was the official cm tree, this is not vanilla but it s a K1 only tree.
Steel01 said:
What ROM are you trying to build? You could look at Carbonrom or Blissrom to see the rename changes needed to use the tree in a different ROM. Those should be similar across the board. I think the only CM specific package references would be gello and snap. Those commits could be reverted easily enough. Or if the ROM doesn't have them, I think they'd be ignored even if left as is.
Click to expand...
Click to collapse
I'm trying to port OmniROM https://docs.omnirom.org/Porting_Omni_To_Your_Device
Shouldn't be that difficult, i'm just doing something wrong.
kylon said:
Hi,
you can take a look at here
the base was the official cm tree, this is not vanilla but it s a K1 only tree.
Click to expand...
Click to collapse
Thank you, man.
I've forked it and will use it as a base.
Oh, omni. I build TWRP from omni. Take a look at the following two commits.
https://github.com/TeamWin/android_...mmit/c8e564a5ea44d963ab8d0e7829d9becd2ad5b0c0
https://github.com/TeamWin/android_...mmit/9b8772627795492f3380d2bf86680c09aada92c9
I haven't built the full ROM, but that should work. If you're using a K1 specific tree, the only difference should be in omni_shieldtablet.mk, instead of gsm.mk, use whatever omni has for tablet wifi only.
Steel01 said:
Oh, omni. I build TWRP from omni. Take a look at the following two commits.
https://github.com/TeamWin/android_...mmit/c8e564a5ea44d963ab8d0e7829d9becd2ad5b0c0
https://github.com/TeamWin/android_...mmit/9b8772627795492f3380d2bf86680c09aada92c9
I haven't built the full ROM, but that should work. If you're using a K1 specific tree, the only difference should be in omni_shieldtablet.mk, instead of gsm.mk, use whatever omni has for tablet wifi only.
Click to expand...
Click to collapse
Thank you, man. In fact i heavily orientaded on TWRP sources in this case. Also took a look at zombipop's repo.
Still whatever i do all i get is
[[email protected] omni]$ brunch shieldtablet
build/core/product_config.mk:241: *** No matches for product "omni_shieldtablet". Stop.
WARNING: Trying to fetch a device that's already there
Traceback (most recent call last):
File "build/tools/roomservice.py", line 352, in <module>
fetch_device(device)
File "build/tools/roomservice.py", line 320, in fetch_device
git_data = search_gerrit_for_device(device)
File "build/tools/roomservice.py", line 81, in search_gerrit_for_device
device_data = check_repo_exists(git_data, device)
File "build/tools/roomservice.py", line 58, in check_repo_exists
"exiting roomservice".format(device=device))
Exception: shieldtablet not found,exiting roomservice
build/core/product_config.mk:241: *** No matches for product "omni_shieldtablet". Stop.
** Don't have a product spec for: 'omni_shieldtablet'
** Do you have the right repo manifest?
No such item in brunch menu. Try 'breakfast'
Click to expand...
Click to collapse
Oh, brunch won't work because it wants to sync from the upstream server. Use lunch instead. Then run make to build.
Steel01 said:
Oh, brunch won't work because it wants to sync from the upstream server. Use lunch instead. Then run make to build.
Click to expand...
Click to collapse
Looks like a derp moment, i just had to modify the devicetree in another directory which is the actual working dir, instead on androidsrc/device/nvidia/shieldtablet directly. Like i said i just did something wrong.
It' compiling now, thank you for all the support!