Nano Pi M4v2 images

-

Below images,


 4.4M boot.img

202K idbloader.img

55                            info.conf

18M kernel.img

383K MiniLoaderAll.bin

570         param4sd.txt

 0  parameter.txt

545    partmap.txt

3.8M  resource.img

681M rootfs.img

4.0M            trust.img

4.0M  uboot.img


resource.img : 

make V=1 shows some commands which builds resulting images,

kernel:

scripts/resource_tool --dtbname ./arch/arm64/boot/dts/rockchip/rk33*-nanopi*-rev*.dtb logo.bmp logo_kernel.bmp

scripts/mkbootimg --kernel arch/arm64/boot/Image --second resource.img -o boot.img


Usage of parm4sd.txt and partmap.txt

In buildroot two text files param4sd.txt and partmap.txt are in buildroot/sd-boot


╭─   ~/learn/github/nanopi/friendlyelec_source/sd-fuse_rk3399/buildroot/sd-boot on   master  ?                                                                       at  11:13:33 PM ─╮

╰─❯ ls -l                                                                                                                                                                                  ─╯

total 8

-rw-r--r-- 1 n n 609 Sep  3  2019 param4sd.txt

-rw-r--r-- 1 n n 564 Sep  3  2019 partmap.txt


From fusing.sh we see that these commands gets executed,

       (cd ${TARGET_OS}/sd-boot && { \

                cp partmap.txt ../; \


       (cd ${TARGET_OS}/sd-boot && { \

               cp param4sd.txt ../; \


This just copy these files and then put in buildroot folder with other images, after that

/tools/sd_update -d /dev/loop30 -p ./buildroot/partmap.txt

partprobe /dev/loop30 -s

resize2fs -f /dev/loop30p1

#cleanup
losetup -d /dev/loop30

Inside partmap.txt we see a line

flash=mmc,1:parm:parm:0x400000,0x0400000:param4sd.txt;

What is this doing?



 Create zero file

RAW_FILE=rk3399-sd-buildroot-linux-4.4-arm64-20210621.img

BLOCK_SIZE=1024

RAW_SIZE=(4000*1000*1000)/1024'

dd if=/dev/zero of=${RAW_FILE} bs=${BLOCK_SIZE} count=0 seek=${RAW_SIZE}

> dd if=/dev/zero of=out/rk3399-sd-buildroot-linux-4.4-arm64-20210621.img bs=1024 count=0 seek=3906250

#make fat partition

sfdisk -u S -L -q ${RAW_FILE} 2>/dev/null << EOF

2048,,0x0C,-

EOF

 > sfdisk -u S -L -q out/rk3399-sd-buildroot-linux-4.4-arm64-20210621.img 2>/dev/null << EOF

2048,,0x0C,-

EOF


# Setup loop device

LOOP_DEVICE=$(losetup -f)

> LOOP_DEVICE=/dev/loop30

> PART_DEVICE=/dev/mapper/loop30

./fusing.sh /dev/loop30 buildroot

DEV_NAME=loop30

BLOCK_CNT=`cat /sys/block/${DEV_NAME}/size` 

BLOCK_CNT=cat /sys/block/loop30/size

> BLOCK_CNT=7812500

> DEV_PART=loop30p1

> REMOVABLE=1

 > ./tools/sd_update -d /dev/loop30 -p ./buildroot/partmap.txt


Now this sd-update binary parses command of partmap.txt and create partitions inside the loop device which affects image.

❯ ./sd_update

Usage: sd_update [ARGS]


Options:

  -d <device  node>       default: none

  -p <partmap file>       default: ./partmap.txt

  -i <images path>        default is "partmap.txt" directory

  -r <raw image file>

  -s                      show device partitioin only

  -f                      force to no warning

  -h                      print this help text


partmap file:

flash=<device>.<dev no>:<partition>:<fstype>:<start>,<length>[:file name];

  <device>                device name

  <dev no>                device number

  <partition>             partition name

  <fstype>                filesystem type, MBR = raw, fat, ext4

  <start>                 partition start address (hex)

  <length>                partition length (hex)

  <file name>             write file to partition


❯ cat ../buildroot/partmap.txt

flash=mmc,1:loader:idb:0x8000,0x280000:idbloader.img;

flash=mmc,1:env:env:0x3F8000,0x8000;

flash=mmc,1:parm:parm:0x400000,0x0400000:param4sd.txt;

flash=mmc,1:uboot:raw:0x800000,0x0400000:uboot.img;

flash=mmc,1:trust:raw:0xC00000,0x0400000:trust.img;

flash=mmc,1:misc:raw:0x1000000,0x0400000;

flash=mmc,1:resc:raw:0x1400000,0x0C00000:resource.img;

flash=mmc,1:kern:raw:0x2000000,0x2000000:kernel.img;

flash=mmc,1:boot:raw:0x4000000,0x2000000:boot.img;

flash=mmc,1:rootfs:ext4:0x6000000,0x25C00000:rootfs.img;

flash=mmc,1:userdata:ext4:0x2BC00000,0x0:userdata.img;


So we can see that rootfs is an ext4 partition whereas boot.img is a raw partition.


https://www.programmersought.com/article/18694792320/



boot image creation:

❯ ./scripts/mkbootimg -h

usage: mkbootimg [-h] --kernel KERNEL [--ramdisk RAMDISK] [--second SECOND]

                 [--dtb DTB]

                 [--recovery_dtbo RECOVERY_DTBO | --recovery_acpio RECOVERY_ACPIO]

                 [--cmdline CMDLINE] [--base BASE]

                 [--kernel_offset KERNEL_OFFSET]

                 [--ramdisk_offset RAMDISK_OFFSET]

                 [--second_offset SECOND_OFFSET] [--dtb_offset DTB_OFFSET]

                 [--os_version OS_VERSION] [--os_patch_level OS_PATCH_LEVEL]

                 [--tags_offset TAGS_OFFSET] [--board BOARD]

                 [--pagesize {2048,4096,8192,16384}] [--id]

                 [--header_version HEADER_VERSION] -o OUTPUT


optional arguments:

  -h, --help            show this help message and exit

  --kernel KERNEL       path to the kernel

  --ramdisk RAMDISK     path to the ramdisk

  --second SECOND       path to the 2nd bootloader

  --dtb DTB             path to dtb

  --recovery_dtbo RECOVERY_DTBO

                        path to the recovery DTBO

  --recovery_acpio RECOVERY_ACPIO

                        path to the recovery ACPIO

  --cmdline CMDLINE     extra arguments to be passed on the kernel command

                        line

  --base BASE           base address

  --kernel_offset KERNEL_OFFSET

                        kernel offset

  --ramdisk_offset RAMDISK_OFFSET

                        ramdisk offset

  --second_offset SECOND_OFFSET

                        2nd bootloader offset

  --dtb_offset DTB_OFFSET

                        dtb offset

  --os_version OS_VERSION

                        operating system version

  --os_patch_level OS_PATCH_LEVEL

                        operating system patch level

  --tags_offset TAGS_OFFSET

                        tags offset

  --board BOARD         board name

  --pagesize {2048,4096,8192,16384}

                        page size

  --id                  print the image ID on standard output

  --header_version HEADER_VERSION

                        boot image header version

  -o OUTPUT, --output OUTPUT

                        output file name


Check the Makefile in nanopi4-linux-v4.4.y/arch/arm64 


RAMDISK_IMG := $(notdir $(wildcard $(objtree)/ramdisk.img))

make_boot_img := \

$(srctree)/scripts/mkbootimg \

--kernel $(objtree)/arch/arm64/boot/Image \

$(if $(RAMDISK_IMG),--ramdisk $(objtree)/ramdisk.img) \

--second resource.img \

-o boot.img && \

echo '  Image:  boot.img (with Image $(if $(RAMDISK_IMG),'ramdisk.img ')resource.img) is ready'; \

$(srctree)/scripts/mkbootimg \

--kernel $(objtree)/arch/arm64/boot/Image.lz4 \

$(if $(RAMDISK_IMG),--ramdisk $(objtree)/ramdisk.img) \

--second resource.img \

-o zboot.img && \

echo '  Image:  zboot.img (with Image.lz4 $(if $(RAMDISK_IMG),'ramdisk.img ')resource.img) is ready'

Comments

Post a Comment

Popular posts from this blog

dev_get_platdata understanding

-
So I see this type of code in platform driver inside kernel, struct gpio_led_platform_data *pdata = dev_get_platdata(&pdev->dev); or this, struct aat2870_platform_data *pdata = dev_get_platdata(&client->dev); So how dev_ get_platdata is helping us. In device.h the definition here is, static inline void *dev_get_platdata(const struct device *dev) { return dev->platform_data; } So if I see from kernel it is always done for to get platform specific data. Like Here is a definition of platform_device, in platform_device.h struct platform_device { const char *name; int id; bool id_auto; struct device dev;  <-------------------- u32 num_resources; struct resource *resource; const struct platform_device_id *id_entry; char *driver_override; /* Driver name to force a match */ /* MFD cell pointer */ struct mfd_cell *mfd_cell; /* arch specific additions */ struct pdev_archdata archdata; }; further struct devic...
Read more

Getting started with pinctrl subsystem linux

-
A pin controller is a piece of hardware, usually a set of registers, that can control PINs. It may be able to multiplex, bias, set load capacitance, set drive strength, etc. for individual pins or groups of pins.   PINMUX   PINCONF - electronic properties e.g. high impedance, tristate, input pin to VDD or GND using a certain resistor value - pull up and pull down so that the pin has a stable value when nothing is driving the rail it is connected to, or when it’s unconnected. Pin configuration can be programmed by adding configuration entries into the mapping table     say that we have a group of pins dealing with an SPI interface on { 0, 8, 16, 24 }, and a group of pins dealing with an I2C interface on pins on { 24, 25 }.   make a group static const unsigned int spi0_pins[] = { 0, 8, 16, 24 }; static const unsigned int i2c0_pins[] = { 24, 25 }; //combine them  static const struct foo_group foo_groups[] = { { .name = "spi0_grp", ...
Read more

How to take systrace in android

-
Image
Install python 2.7 . As systrace does not support python 3.6. Python has its own package manager 'pip'. Use it to install new packages.         download python2.7 install pywin32 and six module on windows. Open power shell in C:/Python27/Scripts path,          pip install pywin32          pip install six   Above packages are not required to be installed on Ubuntu. But if you want other packages of python, we have to install python-pip, however not required for systrace.           sudo apt install python-pip        Then do pip list to see what packages are installed in Ubuntu. Install android studio        Start android studio from the downloaded android studio. That will        have a script to start an...
Read more