Open cmd
go to adb folder
type adb shell
cd /system/bin/
kexec-tool
you willl see commands for loading Zimage to kernel or loading new kernel
Yes but it has been already told that we have to find root partition... without it we can't do anything... Bin4ry has already posted modded kexec tool too..
blagus said:
Yes but it has been already told that we have to find root partition... without it we can't do anything... Bin4ry has already posted modded kexec tool too..
Click to expand...
Click to collapse
Im looking for it
in init.delta.rc I found the text
sevice kexec-tool /system/bin/kexec-tool -p /system/xbin/capk --initrd=/system/xbin/capk_root
and the source code is config file
in /kernel/arch/arm/configs/semc_shakira_capk_defconfig
I did not compile it
there are errors during compilation
If, after compilation will file capk_root. can try to run it on the phone !?
sorry for my english
That kexec command is made to load new kernel in case of kernel panic. So maybe we can load new kernel with that -p option and produce kernel panic so new kernel would be loaded... Would that work?
blagus said:
That kexec command is made to load new kernel in case of kernel panic. So maybe we can load new kernel with that -p option and produce kernel panic so new kernel would be loaded... Would that work?
Click to expand...
Click to collapse
Dontpanic folder is located in data folder.
Maybe will work try some panic kernel andvif mobile will not turn on that mean you did it.
Sent from my E15i using XDA App
blagus said:
That kexec command is made to load new kernel in case of kernel panic. So maybe we can load new kernel with that -p option and produce kernel panic so new kernel would be loaded... Would that work?
Click to expand...
Click to collapse
try flashing x10s kernel.sin that will probably produce kernel panic
That wouldn't work because phone would be off - we need working turned on system, where we load new kernel and then produce kernel panic... unfortunately, when I have to, I don't know how, but when I "had" to crash Ubuntu installation, it was very easy
blagus said:
That wouldn't work because phone would be off - we need working turned on system, where we load new kernel and then produce kernel panic... unfortunately, when I have to, I don't know how, but when I "had" to crash Ubuntu installation, it was very easy
Click to expand...
Click to collapse
Change modules.
Sent from my E15i using XDA App
Tried this. Used capk_root and capk with kexec, triggered kernel panic.
Nothing special happens. Devices just hangs.
here what happen while trying kexec-tool -p
# kexec-tool -p /data/dontpanic/zImage
kexec-tool -p /data/dontpanic/zImage
200000- d8fffff : System RAM
22b000- 6e3fff : Kernel text
6e4000- 813733 : Kernel data
2900000- 2afffff : kgsl_phys_memory
d200000- d8fffff : Crash kernel
d9e0000- d9fffff : ram_console
a0000000-a001ffff : kgsl_reg_memory
a0000000-a001ffff : kgsl
a0200000-a0200fff : msm_serial_hs.0
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : TIWLAN_SDIO.2
a0800000-a08003ff : msm_hsusb
a0800000-a08003ff : msm_hsusb_periphera
a0800000-a08003ff : msm_hsusb_host.0
a0800000-a08003ff : msm_hsusb_otg
a0800000-a08003ff : msm_otg
a0a00000-a0a007ff : msm_nand_phys
a9900000-a9900fff : msm_i2c.0
a9900000-a9900fff : msm_i2c
a9c00000-a9c00fff : msm_serial.2
a9c00000-a9c00fff : msm_serial
aa200000-aa2effff : mdp
aa300000-aa300fff : tssc
aa600000-aa600fff : pmdh
CRASH MEMORY RANGES
200000- d1fffff
Created elf header segment at 0xd8fc000
Command line after adding elfcorehdr
elfcorehdr=222192K
---UP------
Hi Team,
Was trying to port CyanogenMod 11 || CAF 8610 KK on MSM8610 handset.
I have a partial kernel source for the device, but am unable to compile the dt.img from it.
Using the dt.img from the Stock Boot.img gives me display, but using my created dt.img gives me no display.
When i try to create a DT.IMG using the mkbootimg_tools i get :-
DTB combiner:
Input directory: './arch/arm/boot/'
Output file: 'dt.img'
=> Found 0 unique DTB(s)
I want to know how to create the dt.img from the kernel. Tried various dtbTools with the same result. Am wondering if there is something else wrong.
Any help would be greatly appreciated.
adityaxavier said:
Hi Team,
Was trying to port CyanogenMod 11 || CAF 8610 KK on MSM8610 handset.
I have a partial kernel source for the device, but am unable to compile the dt.img from it.
Using the dt.img from the Stock Boot.img gives me display, but using my created dt.img gives me no display.
When i try to create a DT.IMG using the mkbootimg_tools i get :-
DTB combiner:
Input directory: './arch/arm/boot/'
Output file: 'dt.img'
=> Found 0 unique DTB(s)
I want to know how to create the dt.img from the kernel. Tried various dtbTools with the same result. Am wondering if there is something else wrong.
Any help would be greatly appreciated.
Click to expand...
Click to collapse
Guys !?
like this
if u see a bunch of .dtb files in arch/arm/boot
then
./dtbToolCM -s 2048 -o arch/arm/boot/dt.img -p scripts/dtc/ arch/arm/boot/
Yeah, I made the mistake of doing it before compiling the zimage.
Got the DT.IMG. but there is a problem.
Compiled zimage + compile DT.IMG = no display, no adb.
Compiled zimage + stock DT.IMG = display and adb
As far as I understand the problem might be because the compiled DT.IMG is not having the right dtb.
My device has otm9608c qhd display.
adityaxavier said:
Yeah, I made the mistake of doing it before compiling the zimage.
Got the DT.IMG. but there is a problem.
Compiled zimage + compile DT.IMG = no display, no adb.
Compiled zimage + stock DT.IMG = display and adb
As far as I understand the problem might be because the compiled DT.IMG is not having the right dtb.
My device has otm9608c qhd display.
Click to expand...
Click to collapse
maybe , try make clean , and again build , actually dtbToolCM finds the right dtb files from scripts/dtc , it shouldnt go wrong unless u did it wrong or if ur source has problems
I have been trying unsuccessfully to build the GoogyMax3 and Alucard kernels for my CM11 Samsung Galaxy S4 (I9505). I've tried many different toolchains and followed all the tutorials and threads I can find. I also tried two separate Linux boxes as my compilation machine in case the first had an issue.
The kernel will compile and the .zip is created, but they never work when I flash them with TWRP. So I suspect I'm doing something fundamentally wrong or missing an important step. Is there any way to identify what architecture a kernel has been compiled for? Do toolchains (such as the Christopher83 Linaro ones) require any configuration after git cloning? I think my environment is not correct.
Ultimately I'd just like to compile some additional modules and this is taking me far too much effort without any progress.
I'm having EXACTLY the same problem.
I have tried EVERY tute and guide I can find.
Iv tried different toolchains on different source code, most building fine, but flashing in fastboot or installing a .zip in TWRP results in bootloop, never getting past the splash screen.
I thought it was my install method, I tried varying methods of any kernel, compiling my on boot.img, different zip signing tools, Nothing gets me past the bootloop.
NOTE: Attempting to build Kangaroo Kernel for htc-m7. The best guide for me so far has been http://pete.akeo.ie/2013/10/compiling-and-running-your-own-android.html?m=1 especially after the heading "Crafting an Android Boot.img" where the author supplies a new unmkboot tool that gives you the full set of parameters for compiling your custom boot. img.
Good luck man, if you figure it out let me know, I'll do likewise for you.
I've worked out what I was doing wrong. My ramdisk was invalid. I cloned https://github.com/Alucard24/Ramdisk into the folder the build script for the Alucard kernel was expecting to use and rebuilt the kernel with the 2015.02 Cortex A7-optimised toolchain. This time it worked. So you should be investigating that your ramdisk is correct.
Hmm. Got my ramdisk from (1st time) extracting the boot.img from the .zip file of my rom and (2nd time) a backup of boot. img from my phone using TWRP. I know the parameters I set when re joining ramdisk to my zImage are correct, but it never gets past the splash screen i.e the kernel isn't loading, which suggests to me it is as you say the ramdisk.
I'm wondering if I need to alter the Makefile of my kernel for Christopher's tool chain in any way.??
Thanks for letting me know.
Joeisgood99 said:
Hmm. Got my ramdisk from (1st time) extracting the boot.img from the .zip file of my rom and (2nd time) a backup of boot. img from my phone using TWRP. I know the parameters I set when re joining ramdisk to my zImage are correct, but it never gets past the splash screen i.e the kernel isn't loading, which suggests to me it is as you say the ramdisk.
I'm wondering if I need to alter the Makefile of my kernel for Christopher's tool chain in any way.??
Thanks for letting me know.
Click to expand...
Click to collapse
I didn't have to modify anything for the toolchain. I download and extracted it and then updated the build script. The Alucard script creates the image with this:
./mkbootimg --cmdline 'console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3' --kernel $PACKAGEDIR/zImage --ramdisk $PACKAGEDIR/ramdisk.gz --base 0x80200000 --pagesize 2048 --ramdisk_offset 0x02000000 --output $PACKAGEDIR/boot.img
I have the same problem,
Im learning for making custom kernels and I use for a try working kernel without anychange - only compiling from working source - and... after compiling flash and bootloop - always , flash ziped by another person - works .....
I'm not an active developer but I'm also not a *total* noob -- I've successfully compiled usable kernels for Nexus 4, Moto G, HP TouchPad -- but I'm not making much headway on my Z5C kernel.
I want to run an otherwise stock Sony ROM on my phone, but make a couple of minor tweaks to the kernel. With that in view, I downloaded the source tree from Sony's dev site for the kernel that matches the one that shipped with the ROM I am currently running (at the moment, for Reasons, it's a Lollipop one, and I'm not really interested in debating that point anyway), and then I started by building a kernel with ZERO changes applied first. But it will not boot. Instead, with my first attempt at a kernel compiled from scratch, after the Sony Xperia boot logo and before the boot animation would normally kick in, the screen goes black and the notification LED blinks red 4 times, and then it reboots and starts over (bootloop).
I'm not sure what I am supposed to do to diagnose the problem since the screen doesn't display anything and it never gets far along enough in the boot process to where the USB port is initialized. And, yes, the bootloader is unlocked (I can flash a stock kernel to the phone with the DRM fix applied, and that boots and works just fine).
Here is what I have done so far:
Downloaded the kernel sources that match my ROM's kernel at https://developer.sonymobile.com/do...rchives/open-source-archive-for-32-0-a-6-200/
Downloaded the GCC 4.9 for ARM64 cross-compiler / toolchain from https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
Applied kitakami_defconfig and suzuran_diffconfig, and built the kernel. It compiled cleanly without any errors.
Extracted kernel.elf from my ROM's kernel.sin, and then unpacked the binary image, initramfs, and device tree blob from that.
Re-packaged a new kernel into .img format for Fastboot flash by substituting in my kernel image binary for the official Sony one, but keeping the original ramdisk and DTB.
Flashed image to boot partition with Fastboot == bootloop
Flashed original kernel back == works fine
Decided to try creating a new DTB instead of reusing the one from the original kernel...but dtbTool spits out this:
Code:
Found file: msm8994-v2.0-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Found file: msm8994-v2.1-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Grabbed dtbToolCM from https://github.com/xiaolu/mkbootimg_tools instead, which seems to work.
Substituted in the new DTB image for the original Sony one, repackaged up a new boot.img, flashed that == bootloop
Tested my mkbootimg and the parameters I was using by extracting kernel, ramdisk, and DTB from original kernel.elf, then repackaging them all together into a boot.img and flashing that to the phone with Fastboot == works just fine
Hypothesized that perhaps my kernel didn't like the Sony kernel modules on the system partition because of version magic mismatch, so I changed CONFIG_LOCALVERSION from "-perf" to "-perf-g75e6207" in .config and rebuilt kernel, repackaged, reflashed with Fastboot == bootloop ... ARGH
So at this point, I'm at a loss. I've proven that it's not the way I am packaging up the boot image because if I repack the original Sony kernel binary up with the original ramdisk and DTB and then flash that file to the boot partition, that has no problem booting the phone. Is there some modification that I need to make to the contents of the ramdisk? I'd think I should just be able to use the stock Sony ramdisk unmodified, especially if the kernel itself doesn't differ at all (same sources, same .config) from the one Sony compiled, but...?
Any leads that any experienced Xperia Z-series kernel hackers out there can supply before I end up tearing my hair out would be greatly appreciated.
Thanks so so so much,
-- Nathan
[UPDATE]: Just tried assembling with mkqcdtbootimg instead. No go. Also unpacked the image made by that utility and verified that everything (e.g. offsets, etc.) looked sane. GARGH.
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
nlra said:
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
Click to expand...
Click to collapse
I think that cannot be possible. There are lots of kernels out there compiled with toolchains different than the stock one (e.g. Androplus kernel is compiled with UBERTC 4.9)
I am in the same situation as you, but with the Xperia X Compact:
-Untouched copyleft source code
-Untouched ramdisk
-Using AOSP mkbootimg (the new one written in Python: https://android.googlesource.com/platform/system/core/+/nougat-release/mkbootimg/mkbootimg) with arguments specified in README_Xperia (https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/README_Xperia)
And still no boot... I am about to give up on this as I cannot find any other solution...
You can see my build script here for reference: https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/utils/build.sh
bamsbamx said:
I think that cannot be possible.
Click to expand...
Click to collapse
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
nlra said:
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
Click to expand...
Click to collapse
Yeah, sorry about that, I didnt push the new commits to Github yet because of the kernel not booting, the current script I am using is this one:
Code:
#!/bin/bash
RED=1
GREEN=2
BLUE=4
colorPrint() {
tput setaf $2
echo $1
tput sgr0
}
colorPrint "Initializing workspace..." $BLUE
#Device config
device=kugo
#Workspace directories
workdir="$(pwd)"
outputfolder=${workdir}/OUTPUT
outputdir=${outputfolder}/${device}
toolchains=${workdir}/toolchains
ramdisk=${workdir}/ramdisks/${device}/ramdisk
export ARCH=arm64
export CROSS_COMPILE=${toolchains}/aarch64-linux-android-4.9-kernel/bin/aarch64-linux-android-
export KBUILD_DIFFCONFIG=kugo_diffconfig
colorPrint "Cleaning previous builds..." $BLUE
rm -rf $outputdir
mkdir -p $outputdir
colorPrint "Configuring kernel..." $BLUE
make msm-perf_defconfig O=$outputdir
colorPrint "Building kernel..." $BLUE
time make -j8 O=$outputdir 2>&1
if [ ! -f $outputdir/arch/arm64/boot/Image.gz-dtb ]; then
colorPrint "ERROR: kernel image not found. Kernel build failed" $RED
exit 1
fi
if [ ! -e $outputdir/ramdisk.cpio.gz ]; then
colorPrint "ERROR: ramdisk image file not found. Compression failed" $RED
exit 1
fi
colorPrint "Packaging boot image file" $BLUE
${workdir}/utils/mkbootimg \
--kernel $outputdir/arch/arm64/boot/Image.gz-dtb \
--ramdisk $outputdir/ramdisk.cpio.gz \
--base 0x20000000 \
--ramdisk_offset 0x02000000 \
--pagesize 2048 \
--tags_offset 0x01E00000 \
--cmdline "androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 zram.backend=z3fold earlyprintk" \
--output $outputdir/boot.img
if [ ! -f $outputdir/boot.img ]; then
colorPrint "ERROR: boot image file not found. boot packaging failed" $RED
exit 1
fi
colorPrint "DONE" $GREEN
colorPrint "boot image file can be found at ${outputdir}/boot.img" $GREEN
This one is for the build 34.3.A.0.217... However, I already had managed to boot copyleft kernel builds in other versions (such as 34.2.A.0.XXX) using the Github script, the UBERTC 4.9 Toolchain and not changing the GCC version, although I had to set # CONFIG_MODULE_SIG_FORCE is not set There must be something strange here
I think there must be something with kernel files permissions, or... maybe this? https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
zacharias.maladroit said:
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
Click to expand...
Click to collapse
Hi,
Nope, I didnt disable RIC neither dm-verity, the only thing I changed was CONFIG_MODULE_SIG_FORCE to 'is not set'. But I guess that wasnt the cause of kernel not booting since my /system partition is untouched. I tried both with mkqcdtbootimg and mkbootimg but still nothing
Hey @nlra, I figured out the problem (finally). The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken (resulting in a 7.0MB ramdisk.cpio.gz file)
I managed to pull up the boot.img from the device (via dd if=/dev/block/mmcplk0p33 of=/sdcard/boot.img) and then extract the ramdisk from it, resulting in a 11.4MB file
Then, I was able to boot it BOTH USING mkqcdtbootimg file and mkbootimg python script from AOSP nougat-release branch
Thats it
bamsbamx said:
The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken
Click to expand...
Click to collapse
Nice! Glad you figured out what was going on in your case, and thanks for confirming that both mkqcdbootimg and mkbootimg both work for building the X Compact boot image.
-- Nathan