Related
kaiser ubuntu port based on zubuntu by Omegamoon for Sharp Zaurus was successfully launched on HTC Nike!
Instructions:
1. download kernel
http://84.23.71.227/kerneloftheday/zImageUbuntu
2. download ubuntu basefiles and rootfs
3. place ubuntu.img, haret, initrd.gz and zImageUbuntu to Storage Card/ubuntu/
4. place this default.txt there too
Code:
set RAMADDR 0x10000000
set MTYPE 1724
set KERNEL zImageUbuntu
set initrd initrd.gz
set cmdline "pm.sleep_mode=1 mddi.width=320 mddi.height=480 lcd.density=160 board-htcnike-keypad.keypadlayout=1 board-htcnike-keypad.sticky_timer_time_ms=350 no_console_suspend"
boot
5. change board-htcnike-keypad.keypadlayout=1 to 0 if you have 20key nike.
6. run haret and press "Run", ubuntu & kernel will be loaded to login prompt, login with username root and no password, you will get root shell.
7. write
Code:
export TSLIB_TSDEVICE=/dev/input/event0
ts_calibrate
and calibrate your screen.
8. write startx and see LXDE running on your nike! you've got real linux box in pocket!
Note, rootfs for ubuntu needs 1GB of free space on your sdcard!
For now, you cannot work with screen, we have some difference from kaiser panel's, i.e. ubuntu gui is completely unusable, this thread were started to find out why.
based on this thread from kaiser forum.
Credits: dzo, Omegamoon, domy007, mblaster and guys from Rhodubuntu thread.
I dont get any response when i try to calibrate screen on niki 200
thats strange, it must work.
I will debug on touchscreen problems, but ubuntu running and that is great, now we have only input-devices problems, and this is more better than nothing.
Sounds great, but wouldn't it be better to try something smaller like puppylinux or Feather linux ?
zubuntu is only we have compiled for ARM and working with our hardware that starts X and tested on other htc's devices.
rzk333 said:
zubuntu is only we have compiled for ARM and working with our hardware that starts X and tested on other htc's devices.
Click to expand...
Click to collapse
Ok thanks for the information, did some reading before and was always wondering why they use ubuntu but this answer set things straight.
Greetz,
Great to see a full linux distro around for htc devices. I will fix the '_' tomorrow... Any other missing characters?
How is the speed of ubuntu? Is it very sluggish or usable?
'=' character maybe, for export line.
zImageUbuntu is updated (your link is still valid).
'=' and '-'are on '*'-button, '_' is Alt-
I have included the msm_fb_refresh and the keypad changes into my auto-updated-kernel, so you should be able to use the fresh kernels from my thread with ubuntu if you want recent updates (zImageUbuntu is not automatically updated).
got some progress,
1) msm refresh thread seems to disable sleep mode in android, thread polls framebuffer many times in second and drains battery.
2) linux logo on bootup must be disabled - logo gets over ts_calibrate's first crosshair point.
2) still trying to make touchscreen and tslib friends - i2c bus debug messages logs saying that touchscreen is connected and recieves data correctly.
found some data:
/dev/input/event0 - htcnike-kbd
/dev/input/event1 - htcnike-ts
but still no data from touchscreen...
rzk333 said:
got some progress,
1) msm refresh thread seems to disable sleep mode in android, thread polls framebuffer many times in second and drains battery.
2) linux logo on bootup must be disabled - logo gets over ts_calibrate's first crosshair point.
2) still trying to make touchscreen and tslib friends - i2c bus debug messages logs saying that touchscreen is connected and recieves data correctly.
found some data:
/dev/input/event0 - htcnike-kbd
/dev/input/event1 - htcnike-ts
but still no data from touchscreen...
Click to expand...
Click to collapse
Disabled msm refresh thread from the android kernels again. The kernel you linked in your first post is now automatically updated with anything new in the repository. Bootlogo is disabled, too. Good luck with tslib, let me know if when you need something else to be hacked into the kernel.
mblaster
I've just test the usb ether function in the zImage from the post
showthread.php?p=6675397
and it works just fine.
(Just when I had managed to make adbd works... but ssh is more reliable)
Thanks gTan64.
wow, that is good, now I can dump system state without hours of keyboard typing
I've managed to get internet by usb (cdc only) thanks to gTan64: just apply the patch from is post ("Debian on the vogue"), you can extract it from the download links.
And the TOUCHSCREEN WORK!!!!!!!
But you need to compile tslib from the tslib git (github.com/kergoth/tslib.git), the one in the rootfs from this post doesn't work.
Will make a more complete post later, I think.
Bye.
Ubuntu always shows me a black screen when I try to startup it!
What can I do make it work?
omg, I knew that something is wrong with tslib in this rootfs!
thanks for r&d, if you will make some packages & mans, I'll add them to first post.
Maybe you can upload some pics ?
But you need to compile tslib from the tslib git
Click to expand...
Click to collapse
I tried to compile - but no luck, autoconf fails to make configure...
I also uploaded debian rootfs and posted links in gTan's Debian on Vogue thread.
nothing happened last month?
Yesterday I discovered a very interesting source release from Samsung: GT-S5830G_GB_Opensource.zip
Normally, there is a shared Samsung source release for the msm7k range of devices (Ace, Mini, Callisto, Beni, Gio; there is also partial support included for my GT-I5500/Europa, but I adapted the source to properly support my phone). All of these devices usually depend on Samsung's proprietary FSR (Flex Sector Remapper) drivers in order to access the flash memory, which are taken from the stock ROMs, but our dependence on this driver locks us into the 2.6.35 kernel since we don't have access to the driver source.
The new source that I found for the GT-S5830G model, however, appears to contain modifications for the purpose of transitioning from Samsung's proprietary FSR driver to the open source MTD (via msm_nand) driver. If this can work correctly, using this driver would be much preferred over the proprietary Samsung stuff.
Here's the source that I uploaded to github: https://github.com/psyke83/android_kernel_samsung_msm/tree/purenand
Some observations that I have made, keeping in mind that I'm testing on my GT-I5500:
There are two separate configs for the cooper rev03 (Galaxy Ace): the standard defconfig that uses fsr/rfs, and a "purenand" config that uses the mtd/yaffs2 drivers instead of fsr/rfs. In other words, it's using the open drivers for flash access. Here is the diff: https://gist.github.com/3365123
The dpram driver (Samsung's driver for communication with baseband, used by RIL) is patched to support MTD instead of BML when the proper config is set.
The drivers/mtd/devices/msm_nand.c driver is modified by Samsung, but they applied their patches to an older revision of msm_nand.c from Froyo. Here is the diff when comparing this file vs the Froyo revision, so you can see more clearly the changes: https://gist.github.com/3365161
By default, the msm_nand.c driver causes the kernel to hang on my device (this is true for both this source and the older 2.6.35 Samsung source not based on purenand). I have isolated the hang to the flash_onfi_probe function.
As you can see here, Samsung added code to bypass this function on the Cooper board, and use the secondary detection method only. If I include my board to this ifdef block, it solves the issue with the kernel hanging on my device. I also need to patch some checks in the onenand detection, because the driver explicitly looks for onenand devices with a device_id of 0x40 and num_of_buffers as 0x201, but the chip on the GT-I5500 is different (device_id is 0x50, num_of_buffers is 0x101). This patch solves these problems: https://gist.github.com/3365222
Here is a dmesg log from my device after patching the code: https://gist.github.com/3360727. For comparison purposes, look at the block mapping that the fsr driver reports for my device when using the BML mapping: https://github.com/psyke83/android_device_samsung_galaxy5/blob/gingerbread/BoardConfig.mk#L53
As you can see, the partitions names and order detection is correct for the msm_nand driver, but the address mappings are exactly half of what they are supposed to be (e.g. the first partition, mibib, should range from 0x00000000-0x00180000, but the mtd driver detects the memory range as 0x00000000-0x000C0000.
If I try to perform a "nandump -f /sdcard/cache.img /dev/mtd/mtd13", there are no obvious errors in the dmesg log, but the tool will dump the cache partition until the sd card becomes full (over 300mb in my case, but the real /cache partition is only 25MB), and will then output "nanddump: short write". The resulting dump will be filled with 0xFF when examined with a hex editor (even though I'm sure that the /cache partition is not blank in reality).
These are my findings so far. I'd appreciate any kernel hackers to help me out. If we can crack this problem and get open onenand drivers working, then our devices will no longer be locked to any specific kernel release. If you know any developers for the Samsung devices I mentioned at the beginning of the post, or anyone else who may be able to help, please direct them to this thread. Thanks!
Reserved for future use
I have also posted this topic on the MadTeam forum, and posted a lot of further details. Please see: http://madteam.co/forum/development-8/(devs-only)-mtdonenand-driver-development/
Post this on General Discussion, this section is inactive
What is Kexec?
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
Code:
unmkbootimg /path/to/your/boot.img
This will dump a zImage (rename it to zImage-dtb now, for semantics sake), and a ramdisk, labeled initramfs.cpio.gz (Initial RAM File System, in the form of a cpio.gz archive).
Now, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Code:
su
cd /sdcard/PathToYourFolder/
kexec --load-hardboot zImage-dtb –initrd=initramfs.cpio.gz --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu –dtb
Now, lets dissect the different arguments we are passing to Kexec:
--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Code:
kexec -e
Although this guide is for the Nexus 6 (shamu), it should work all devices supported bu MultiROM, or on any device with a kernel that supports Kexec/Kexec Hardboot.
I hope this helped you to better understand what Kexec is/how to use it.
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
(I'm cross-posting from "General Discussion", I think I picked the wrong forum. Sorry!)
I have:
Downloaded the exact kernel version running on my device from an AOSP mirror (4.9.170) (https://github.com/aosp-mirror/kernel_common.git)
Downloaded the exact compiler used to compile the kernel from my device:
Ran `cat /proc/version`, which returns "Linaro GCC 5.3-2016.05", which I downloaded from https://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/aarch64-linux-gnu/
Took the kernel configuration from `/proc/config.gz`, copied it to the kernel source directory `kernel_common` as `.config`
Ran `make ARCH=arm64 CROSS_COMPILE=xxx oldconfig`
What I'm seeing:
First, the downloaded kernel source for 4.9.170 seems to think that my `config` is incomplete, since it will prompt me to answer ~15 extra configuration questions.
Second, this old Linaro compiled doesn't appear to support `-fstack-protector-strong` despite it being explicitly enabled in the `/proc/config.gz` file. So I end up disabling it with `./scripts/config --disable CONFIG_CC_STACKPROTECTOR_STRONG`
Finally, after successfully compiling, I take `net/ipv4/tcp_westwood.ko`, just as a test module, and try to load it on my Android device, and it fails:
`insmod: failed to load tcp_westwood_5.ko: Exec format error`
And in dmesg output: `tcp_westwood: disagrees about version of symbol module_layout`
My questions:
Can I assume that the `/proc/config.gz` file is not the actual file used to compile the running kernel, considering it doesn't completely configure the 4.9.170 kernel?
Am I on the right path to getting a kernel module that my kernel will load?
Background information:
I'm hoping this isn't very relevant, but just to head off some questions
This is a T95 Android TV device running what appears to be, to this newbie's eyes, a very Frankenstein'd Android 10 install (See https://www.cnx-software.com/2020/0...-comes-with-mali-g31-gpu-supports-android-10/)
I can't find any official - or unofficial - source for this device, which is why I'm going to all the trouble above.
I really appreciate any help, thank you!