I am attempting to use NFS on my Xiaomi Redmi Note 9S, it uses a custom ROM called Resurrection Remix OS. I am replacing my old kernel with a newly compiled one, with NFS built-in.
I am using the kernel source found here, the official kernel for the phone made by Xiaomi. I couldn't find the exact kernel source for my custom ROM, but the phone boots regardless.
At first, I only compiled the modules for NFS, however using insmod on sunrpc.ko requires __audit_inode_child, so a new kernel with CONFIG_AUDIT_SYSCALL=y is necessary. I also decided to make all the NFS modules built-in.
I made the changes to my .config, and compiled the entire kernel
(besides the device tree: CONFIG_BUILD_ARM64_DT_OVERLAY=n because of compilation errors).
With the new kernel from arch/arm64/boot/Image, I unpacked the boot.img from my device and swapped out the kernels and it boots, with NFS support listed in /proc/filesystems.
However, now none of the modules from /vendor/lib/modules work. Which is to be expected, they weren't built against this new kernel's source.
Trying to remedy this issue by inserting the newly compiled modules with insmod say disagrees about version of symbol module_layout.
How is this possible? These modules were compiled alongside the running kernel (same source code)
Something must have went wrong when creating the boot image, most likely the wrong kernel was copied (I have multiple kernel sources downloaded and compiled).
I repacked boot.img with a newly compiled kernel image and no module loading needed, every module in /vendor/lib/modules was loaded on boot.
Related
Need help. I have a ZTE blade a460 phone with broken screen and i want to make it something usefull like a nfs server. I want a custom compiled kernel so, i extract the config from the original kernel using the extract-ikconfig script. I compile kernel using this config and the original dtbs from ramdisk but the kernel dont bootup. After much trials i think something special is needed. Knows someone what specific is needed for this machine? compiling Modules for the original kernel needs the extra flag -fno-pic. Is needed for the new kernel too? The phone has 3.10.49 kernel and android 5.1.1 Lollipop. I use arm-linux-androideabi-4.8 (the same as they use to compile the original kernel). Adb boot to boot the new image.
I downloaded android device open source from Samsung OSRC.
It was composed with Platform.tar.gz and Kernel.tar.gz
It seems to do with building AOSP, found mk files.
I'm curious whether it can be used(directly or indirectly) to build newer android version for device and whether I have to build new kernel based on this files.
Thank you.
If you want to build for a newer Android version, you do not need to build another kernel. Just use the kernel provided by Samsung for your device (or the prebuilt kernel from your phone).
When porting a device to a newer Android version you need to adjust the init configuration (init.rc files from your product configuration located in device/<vendor>/<your_device>), but not the kernel specific parts of your init.rc files.
You also need to add the hardware specific vendor binaries to your resulting flash image. Therefore you can extract these libraries from your device. Most of them are located in /system/vendor/lib, but there could be also some libraries in /system/lib and all subdirectories.
It is also possible that some vendor binaries does not work within another software stack. Possible reasons are incompatible HAL interfaces and incompatible libraries. The solution for these cases can be very different and should be evaluated individually.
If you are facing such issues you can have a look at the CyanogenMod sources for a hint. There you can find lots of ports. Best place to look is the product configuration of the particular device. You can also look into another of my answers regarding this topic.
I've noticed that I have some directories inside my android phone which look the same.
What the different between /sbin, /system/sbin, /system/bin, /system/xbin?
/system is the main Android directory for storing immutable components generated by the build of the AOSP. This includes native binaries, native libraries, framework packages, and stock apps. It’s usually mounted read-only from a separate image from the root file system, which is itself mounted from a RAM disk image.
Android also includes many directories commonly found in any Linux system, such as /dev, /proc, /sys, /sbin, /root, /mnt, and /etc. These directories often serve similar if not identical purposes to the ones they serve on any Linux system, although they are very often trimmed down, as is the case of /sbin and /etc, and in some cases are empty, such as /root.
More than 150 command-line utilities are scattered throughout Android’s root file system. /system/bin contains the majority of them, but some “extras” are in /system/xbin, and a handful are in /sbin.
/sbin: In Linux, this would hold binaries essential to the system administrator. In Android, it contains only ueventd and adbd.
/bin: All native binaries and daemons built as part of the AOSP. All modules built with BUILD_EXECUTABLE are here. The only exception is adbd, which has the LOCAL_MODULE_PATH set to /sbin and is therefore installed there instead.
/xbin: “Extra” binaries generated by some of the packages that are built within the AOSP but aren’t essential to the system’s operation.
Thanks goes to Mr: Karim Yaghmour , The great ; The author of Embedded Android tutorial.
I've had several errors in kernel logs on device boot after all partitions were mounted.
ext3_free_blocks_sb: bit already cleared for block ######
After searching I've discovered that a bugfix for the same issue was already integrated in the kernel.
Then I've searched for similar commits on repository and didn't find anything so it seems like the bug was fixed on the mainstream and the issue is Android-related.
From the discussion on RedHat bugtracker about the bug I discovered that it can be reproduced with stress-test utility. Unfortunately, I don't know any of these for ext3 on Android.
The main difficulty with porting such diagnostic tools to Android is it's reduced kernel functionallity. In this case there is a bunch of filesystem stress utilities for regular linux:
Bonnie++
dbench
fsstress and other tools included in LTP
etc.
Most of them require specific headers or BASH script features which are missing in Android.
After rewiewing available set of tools in filesystem test case of LTP I came up with the following approach:
Find a tool with minimal subset of scripts, headers and syscalls.
Compile it using Android NDK.
Install BASH for Android to run required scripts.
Replace missing commands with their' Busybox equivalents.
I'm a Android application developer. For some reasons, I should change the Android kernel a bit. But I don't know anything about kernel. I will be appreciated if someone introduce me a website who explain android kernel modules and other info about it.
In the standard Android open source distribution the kernel is distributed as a pre-built binary in the mydroid/prebuilt/android-arm/kernel folder and the source code is not included. The kernel source was removed from the default manifest for two reasons as I take it. One is that it takes a lot of bandwith and diskspace for a platform component that most people will not work with much. The other reason is that since the kernel is built with the kernel build system and not as part of the aosp build system it makes sense to keep it separated. The common branch for the kernel is the one used by the emulator. There are also branches for experimental, msm (Qualcomm platforms) and Omap (TI platform) and maybe some more. If you want to use the Android kernel with hardware these may be more interesting to you.
Get the Android kernel either by adding it to your repo manifest or manually by running:
git clone git://android.git.kernel.org/kernel/common.git
The kernel built this way should end up in the arch/arm/boot folder of your kernel tree (where you put the code from git clone)
Note that I have used the default paths in the above description, you need to change them to what applies to your setup. It has been a some time since last time I tested this but I think it should work.
Go through the following sites which will also give u some ideas.
Android Porting, Android Platform, Android-Pdk,
Android porting in real target, Build-compile-linux-kernel-android
I guess that since you are talking about kernel programming you are also looking for ways to hook up new hardware with the platform and expose that functionality using your framework extensions to the applications. Hardware is basically added as a standard Linux driver so getting it to work under Linux is a good first step. How to hook it into the Android framework after that depends on what type of hardware it is. You could either use a native process to control it (compare the camera service or radio daemon in the current platform) or just spawn a thread in the application that uses your framework extension. For hardware that does not require that much attention plugging it in using an Android HAL library could also be an option