We have an development board that has been run Yocto system. and we want it to run android system, we already has compiled android image with Yocto kernel that has android's some patch.
We don't know how to flash the android image (such as system.img boot.img and recovery.img and so on) to the development board because of the Yocto system partition different with android system.
we can use fastboot tool to flash Yocto system to EVB.and we want to know:
How to partition eMMC that we can use fastboot tool to flash android system. Do we need to modify Little Kernel code ? and how to modify it in Yocto system.
How to we boot the android system up?
It would be appreciated if you offer any useful information.
Thanks
How to partition eMMC that we can use fastboot tool to flash android system.
You'll need a tool that can partition the eMMC. Considering you are using yocto your best bet is gptfdisk package. gptfdisk recipe is at path poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.0.bb. gptfdisk provides following text-mode partitioning tools
gdisk,
cgdisk,
sgdisk,
fixparts
You can use one of these tools to recreate the partitions in the partition table.
and how to modify it in Yocto system.
Do IMAGE_INSTALL_append = " gptfdisk " in conf file to make the tools of this package part of your image.
How to we boot the android system up?
You'll need 3 partitions
system.img - goes in partition named system
boot.img - goes in system named boot
and recovery.img - goes in system named recovery
Each tool has a man page on Linux. You can read the manuals using man sgdisk, man gdisk, man cgdisk and man fixparts. Some example usages of sgdisk
sgdisk -p </dev/sda> - To print all partitions on the disk
sgdisk --delete=partnum </dev/sda> - Delete a partition. This action deletes the entry from the partition table
There is a lot of way to partition the eMMC, it depends on your system: via USB, sdcard, nfs, uboot...
I think you can have a look at the meta-variscite, especially in the scripts folder. They have flash scripts for Yocto poky images, and android image (on the same boards). They flash from the SDcard to the eMMC.
I ported these scripts for a use with uboot: I run the command ums mmc 0 to start mass storage mode via USB OTG, and on my PC I run an install script which use dd for erasing partitions, fdisk for creating partitions, mkfs to format my device connected by USB.
You can also use mmc part in uboot, but I never tested this option.
Related
I am trying to learn the kernel customization and for this I have target OnePlus 6T device. I am able to compile the kernel source code on my Ubuntu 18 with the following steps:
Download latest dtc from https://packages.ubuntu.com/cosmic/a...piler/download and install it.
Clone kernel source code: git clone https://github.com/OnePlusOSS/androi...lus_sdm845.git
Clone ToolChain: git clone -b linaro-4.9-arm-linux-androideabi https://github.com/ArchiDroid/Toolchain prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-linaro-4.8
Open terminal at prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-linaro-4.9 and run: export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-android-
Navigate to kernel source code path in the same terminal.
export ARCH=arm64 && export SUBARCH=arm64
make clean
make mrproper
mkdir Out
make O=Out sdm845_defconfig
make O=Out DTC_EXT=dtc CONFIG_BUILD_ARM64_DT_OVERLAY=y DTC_EXT=dtc -j4
Following are the last lines of compilation:
CC drivers/media/platform/msm/broadcast/tspp.mod.o
CC drivers/media/platform/msm/dvb/adapter/mpq-adapter.mod.o
CC drivers/media/platform/msm/dvb/demux/mpq-dmx-hw-plugin.mod.o
GZIP arch/arm64/boot/Image.gz
CC drivers/soc/qcom/llcc_perfmon.mod.o
CC drivers/video/backlight/lcd.mod.o
CC net/bridge/br_netfilter.mod.o
LD [M] drivers/char/rdbg.ko
LD [M] drivers/media/platform/msm/broadcast/tspp.ko
LD [M] drivers/media/platform/msm/dvb/adapter/mpq-adapter.ko
LD [M] drivers/media/platform/msm/dvb/demux/mpq-dmx-hw-plugin.ko
LD [M] drivers/soc/qcom/llcc_perfmon.ko
LD [M] drivers/video/backlight/lcd.ko
LD [M] net/bridge/br_netfilter.ko
CAT arch/arm64/boot/Image.gz-dtb
make[1]: Leaving directory '/home/.../KernelCustomization/android_kernel_oneplus_sdm845/Out'
Now, the next step is to flash the image. I have rooted OnePlus 6T device and I am confused with the three image files generated after successful compilation i.e.
arch/arm64/boot/Image.gz-dtb
arch/arm64/boot/Image.gz
arch/arm64/boot/Image
I need a favour in:
What image can I use to flash on android device?
Is booting a image with TWRP is enough to flash kernel?
Found Google documentation
https://source.android.com/devices/bootloader/partitions-images
As per following lines from google documentation:
boot: The boot partition contains a kernel image and a RAM disk combined via mkbootimg. In order to flash the kernel directly without flashing a new boot partition, a virtual partition can be used:
kernel: The virtual kernel partition overwrites only the kernel (zImage, zImage-dtb, Image.gz-dtb) by writing the new image over the old one. To do this, it determines the start location of the existing kernel image in eMMC and copies to that location, keeping in mind that the new kernel image may be larger than the existing one. The bootloader can either make space by moving any data following it or abandoning the operation with an error. If the development kernel supplied is incompatible, you may need to update the dtb partition if present, or vendor or system partition with associated kernel modules.
I think I have to use arch/arm64/boot/Image.gz-dtb for flashing the kernel. My understanding is that Image.gz-dtb is a virtual image that can be used to flash only kernel on android.
Still, I am not able to figure out the correct step to flash it. I am wondering if I will do something wrong then I will break my device so I want to be sure before flashing that it will work.
Any help or guidance will be very helpful at this moment.
I found the steps that are needed to flash the custom kernel on android device i.e.
First we need to get the boot image of stock firmware we can get it by running following commands:
adb shell "ls -la /dev/block/platform/soc/1d84000.ufshc/by-name/" > MoreInfo\msm_partitions.txt
Note the boot partition name e.g. boot_a -> /dev/block/sde11 boot_b -> /dev/block/sde39
Missing steps to make boot.img with command dd command.
Download the latest Android Image Kitchen from this thread.
Run the following with the boot image: unpackimg.sh .img
Locate the zImage file and replace it with your kernel image (rename it to what came out of the boot image)
Run the following to repack: repackimg.sh
Flash the new boot image with fastboot or TWRP!
I need some more information on the missing steps. Actually the process written above is working on devices that has only one boot partition. Does any one know how can I flash my single kernel image on a device that has a/b partitioning?
Update:
I searched over the internet for A/B partitioning and I found that these are used for seamless updates i.e. One partition is active at a time and another partition which is inactive can be used to flash the update. On reboot, another partition will become active and One partition will become inactive. More Info: https://www.xda-developers.com/how-a...opment-on-xda/
If my understanding is true then I just need to follow following steps to find the correct image to be used at the first step of flashing the kernel:
fastboot getvar all | grep “current-slot”
dd if="path to boot of active slot" of=/sdcard/boot.img
Continue with boot.img and flash the kernel with above written steps for flashing a kernel.
Anyone who has this knowledge, please confirm. I will be very thankful to you.
A/B OTA update
Firstly, you need to confirm whether your phone is A/B OTA update or not by following command
fastboot getvar slot-count
If the command returns '2', then your phone supports A/B OTA update which means you have two boot
partitions 'boot_a' and 'boot_b', otherwise, there should only be one partition 'boot'
boot image
The images you built (Image.gz-dtb) are just kernel images with device tree. They
are not enough for flashing to boot partition since there should be ramdisk and boot arguments combined.
The ramdisk content contains normal boot binaries for non-A/B OTA system or recovery binaries for
A/B OTA system. You need to find official ramdisk images and combine with your kernel image. Normally
mkbootimg will be used to create boot image in AOSP android.
Flashing
fastboot flash boot boot.img
This works on both A/B and non-A/B system since image will be flashed to default active partition (boot_a
is by default if you do not have OTA or using 'fastboot set_active' to change it)
On A/B system, you can also use 'fastboot getvar current-slot' to get active slot and specific flash
partition 'fastboot flash boot_a boot.img' or 'fastboot flash boot_b boot.img'
XDA provides scripts to flash kernel images (Image.gz-dtb) with following steps:
a. Dump boot.img from your phone
b. Extract ramdisk.img from boot.img
c. Combine Image.gz-dtb with ramdisk.img to new boot.img
d. Flash new boot.img to boot partition
https://forum.xda-developers.com/oneplus-6t/development/kernel-holydragon-t3878107
provides customized kernel and flash scripts, you should check and find your suitable way to flash your kernel image.
Recently I ported marshmallow on my board. I was exploring USB functions and found an issue:
If I'm using a non-partitioned USB disk with NTFS file system, it's unable to detect it and display a notification as "Corrupted USB disk".
So I tried with other scenarios like, NTFS with partitioned USB disk, FAT32 on non-partitioned USB disk and all these are working fine.
Then I tried to mount it manually from adb shell:
# mount -t ntfs /dev/sda /mnt/usbdisk
and it's working fine.
But I'm still not able to find why it's not able to auto mount it when I've NTFS on non-partitioned USB disk.
Till now what all I came across is, my usb disk should be detected as DISK when non-partitioned but in case of NTFS file system it's taking it as PART i.e. partitioned disk and getting stuck somewhere.
Any suggestion or leads will be great help.
Thanks in Advance.
Please make few things....
U said ported to my board.
Talking about Android marshmallow or any other android ....
It is upon ur phone os to support NTFS file system.
Generally in stock Android there is no NTFS file system support.
Although it also depends upon brand , that they are providing NTFS file system support in their is or not.
Generally custom os ROM for ur phone may help.
I am trying to bring up panda-board omap4430 with Android jellybean pre-built binaries, which I have downloaded from linaro.org (http://releases.linaro.org/12.12/android/panda/).
I am creating two partitions on SD card into file systems.
First is bootable FAT32 containing boot.tar.bz2 and u-boot.img and other ext3 partition is having userdata.tar.bz2 and system.tar.bz2.
After putting my SD card in panda board & connecting it through minicom on my Ubuntu pc, I am not able to see even a single charecter of untaring or something or any logs.
Am I missing something.
I have done Ubuntu porting on Beagle board earlier successfully.
you are flashing it first time on panda board then it has some other method, as they have given like below process
format sd card
copy MLO and u-boot.bin in fat 32 partitions
then follow the given process on OMAPpedia release nots.
I want to change the init.rc file of an android pad. But after I change it and reboot the system, the original init.rc comes back.
How can I make the change to the init.rc persistently without rebuild the system (since I don't have the source code of the system)? Or is there any way to work around?
Unpack the uramdisk using following command in host PC(Linux)
mkdir /tmp/initrc cd /tmp/initrd
sudo mount /dev/sdb1 /mnt
sdb1 is partion where uramdisk/uInitrd resides.
dd bs=1 skip=64 if=/mnt/uInitrd of=initrd.gz
gunzip initrd.gz
At this point running the command file initrd should show:
mkdir fs
cd fs
cpio -id < ../initrd
Make changes to init.rc
Pack uramdisk using following commands:
find ./ | cpio -H newc -o > ../newinitrd
cd ..
gzip newinitrd
mkimage -A arm -O linux -C gzip -T ramdisk -n "My Android Ramdisk Image" -d newinitrd.gz uInitrd-new
A number of Android devices include code to prevent root modifications to the system files. The way this is done is by using the recovery partition. On reboot, they basically restore the system partition using the recovery image. If your system is doing that then you cannot make persistent changes - the best you could do would be to hook up something to run after reboot to re-apply your change. In CyanogenMod they had hooks in the init.rc to run sdcard scripts if found. Perhaps you can create an app or widget to then launch a script to make the mods required using a setuid root script from the data partition. Without building your own ROM you are quite restricted in this area.
Possibly you could fetch the recovery image and try unpacking that, making your changes and repacking and flashing it. But make sure you can recover with fastboot before you try this.
Try this site:
http://bootloader.wikidot.com/linux:boot:android
Read the section at the bottom:
•The Android boot image: boot.img
◦Unpack, re-pack boot image: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images#Background
When an android system boots, uboot unpacks a special compressed ball of files in your boot partition called 'uRamdisk' to RAM, and defines those files to comprise the root directory of the system. uRamdisk normally contains a bunch of directories (system, data, media, etc.) that serve as mountpoints for partitions that contain the files that go in them, but also has some very basic files vital to your system, including the init binary and startup scripts like init.rc.
when you edit the init.rc, you've actually just edited the unpackaged copy of init.rc that resides in your RAM. To really change it then, you have to copy your uRamdisk, extract it, edit the init.rc from there, repackage uRamdisk and then replace the new one with the old one in /boot.
Try looking up the 'xuramdisk' and 'mkuramdisk' scripts, these make the process very simple.
Your root partition (where /init.rc lives) is a ramdisk which is unpacked from an initrd file and mounted every time your device boots. Any changes you make are to the ramdisk only, and will be lost on the next reboot.
If you can get the initrd file, you can mount it on your Linux host system, modify the files there, unmount it, and write it back to your Android.
The initrd file exists in its own partition on the device. If you can figure out which partition it is, you can grab it from the device onto your host, mount it, modify it, and write it back to the device. This is what tripler was talking about above.
In general, modifying boot.img is something that only system developers do. If you're building the entire Android system, you'll have access to the necessary source code. My workflow for this looks like this:
# Modify init.rc
m -j8 bootimage_signed
adb reboot bootloader
fastboot flash boot $OUT/boot.img
fastboot reboot
I don't know if you are still trying to do this but without knowing your exact device nobody can give you an exact answer.
Try taking a dd image of all your internal partitions and use some scripts like those included with android kitchen on xda forums. Your recovery and boot partitions will both have a ram disk but odds are you want to modify the init.rc in the boot.img not recovery, unless you only want the changes present in recovery mode.
The unyaffs thing doesn't apply to all devices and most devices have different partition layouts so you have to figure out which is boot and what type of fs it is. Maybe if you give your device specs you can get a better answer.
Please note that it may be easier for you to use an app like Scripter to run a script at boot time than modify this file.
Before following #tripler's instructions above you need a file called boot.img which can be extracted by (run on rooted Android device, untested without root):
dd if=/dev/block/platform/<someplatform>/by-name/boot of=/sdcard/boot.img
Then connect your Android to your computer and copy the boot.img file from there.
Script:
http://linuxclues.blogspot.ca/2012/11/split-bootimg-python-android.html
Here is a modified, easier to see version of tripler's instructions (assuming boot.img is in tmp):
cd /tmp
mkdir fs
# Now use the linked script above to split the boot.img file into ramdisk.gz and kernel
python split_boot_img.py -i boot.img -o parts
cd fs
gunzip -c ../parts/ramdisk.gz | cpio -id
# make changes to init.rc
At that point you will have to rebuild the boot.img back together before reflashing, which will be device-specific. Can't help you with that, sorry!
You have to edit/change the init.rc before building your Android pad file system. This is the preferred way, and always works.
I have my Nexus One connected with the USB.
When I visit the File Explorer of the DDMS, if I click on the "data" folder the little plus near the name "data" disappear for 2-6 seconds and then reappear but the contenct of the folder "data" is not showed!
Here some other information:
the folder data has permissions drwxrwx--x
the OS of my PC is Windows XP
Eclipse v. 3.5.2
Android SDK 1.6
If the adbd daemon is running as root, you can browse /data using adb-based tools such as the DDMS file explorer or the adb shell.
If it's not, you can access a few files under /data and its children directly by their full path names, but you cannot browse (or 'cd' to) most of the folders, including /data itself.
"rooting" as an unofficial process means varying things and produces varying results - ie, adbd may or may not run as root.
If ro.secure is set to 0 in the startup scripts such as /init.rc, adbd will run as root, but that may not be a good idea on a user device. It is set to 0 on the emulator, and that's why you can browse /data there.
Finally, note that /init.rc is usually contained in a ramdisk image packed onto the kernel - you can't really edit it on the phone but would have to modify the image offline, re-attach it to the kernel, and re-flash them. Though if you have some sort of working 'su' hack you may be able to change the property temporarily and restart adbd.
In this link (http://denniskubes.com/2012/09/25/read-android-data-folder-without-rooting/) Dennis Kubes shows a method for accessing your application's data folder without root access.
Turns out there is a simple solution, the run-as command.
run-as com.your.package ls -l /data/data/com.your.package
run-as com.your.package rm /data/data/com.your.package/databases/mydatabase.db
That will allow you to run commands as your app. You can also use run-as in interactive mode.
run-as com.your.package
shell#android:/data/data/com.your.package $ ls
cache
databases
lib
shared_prefs
rm databases/mydatabase.db
Interactive mode will drop you into the data folder for your app. You can navigate from there.
I don't think anyone really understands this question. Giorgio can use the DDMS File Explorer to browse the ./data folder on his phone. Pentium10 talks about needing root access on the phone.
Well I a retail Nexus One and a developer Nexus. I have always been able to use DDMS File Explorer to browse the ./data folder on my developer phone but not my retail phone. So I rooting my retail phone would help. I didn't.
So the bottom line is there is something different about the retail and developer phones. Until more research is done you won't be able to browse the data folder on your phone.
Hope this helps.