RT smart OS for executing RT thread on bare metal machine of Quanzhi D1 Nezha

preface

I got the Nezha development board in advance. When I was excited, I began to study how to run my bare metal program, which is called operating system

Unlike mcu, sbc level cpu is much more complex to run, but fortunately, in the field of system level, the division of labor of different software is clear. Our bare metal program, as the kernel part, is waiting to be booted

Although the system of sbc is very complex, we don't need to care a lot at first to run our small code

Only by taking the first step can we see the vast sky behind

Since you don't have your own OS, you can use it here rt-thread rt-smart as the experimental verification object

uboot

The first object we contact is uboot, which is the bootloader of Nezha development board. Therefore, we need to have a good relationship with him and understand him before we can let him help us complete the boot of the kernel

The guiding path of Nezha development board is roughly as follows: bloom - > SPL - > uboot - > [NAND | MMC]

Through simple playing, we can find the following rules. The primary bootloader in bloom will detect mmc and nand devices. If there is an mmc device, it will load the spl in the mmc boot partition to continue to work. The same is true for nand

There is 256MB of nand flash on the development board, which can have enough space to store our programs, so mmc is not considered

Nezha's uboot and nand

The development board is connected to the serial port tool. When powered on, you can see the system startup information in the serial port. If you don't operate anything, you will enter the tina environment. Therefore, when starting up, press the s keyboard (the same as pressing F2 or F10 when starting up the PC) to enter the uboot environment

The following interface:

First use mtdparts to view nand information

mdtparts default
mtdparts
# The output is as follows:
device nand0 <nand>, # parts = 4
 #: name                size            offset          mask_flags
 0: boot0               0x00100000      0x00000000      1
 1: uboot               0x00300000      0x00100000      1
 2: secure_storage      0x00100000      0x00400000      1
 3: sys                 0x0fb00000      0x00500000      0

active partition: nand0,0 - (boot0) 0x00100000 @ 0x00000000

defaults:
mtdids  : nand0=nand
mtdparts: mtdparts=nand:1024k@0(boot0)ro,3072k@1048576(uboot)ro,1024k@4194304(secure_storage)ro,-(sys)

As you can see from the above, nand has four partitions, the first two bootloader s and the third secure_storage has nothing to do with us. The fourth partition sys is where the user os is stored. At present, it is tina linux system

Take a look at the information in sys

ubi part sys
ubi info l
# The output is as follows:
Volume information dump:
        vol_id          0
        reserved_pebs   1
        alignment       1
        data_pad        0
        vol_type        4
        name_len        3
        usable_leb_size 258048
        used_ebs        1
        used_bytes      258048
        last_eb_bytes   258048
        corrupted       0
        upd_marker      0
        name            mbr
Volume information dump:
        vol_id          1
        reserved_pebs   1
        alignment       1
        data_pad        0
        vol_type        3
        name_len        13
        usable_leb_size 258048
        used_ebs        1
        used_bytes      258048
        last_eb_bytes   258048
        corrupted       0
        upd_marker      0
        name            boot-resource
Volume information dump:
        vol_id          2
        reserved_pebs   1
        alignment       1
        data_pad        0
        vol_type        3
        name_len        3
        usable_leb_size 258048
        used_ebs        1
        used_bytes      258048
        last_eb_bytes   258048
        corrupted       0
        upd_marker      0
        name            env
Volume information dump:
        vol_id          3
        reserved_pebs   1
        alignment       1
        data_pad        0
        vol_type        3
        name_len        10
        usable_leb_size 258048
        used_ebs        1
        used_bytes      258048
        last_eb_bytes   258048
        corrupted       0
        upd_marker      0
        name            env-redund
Volume information dump:
        vol_id          4
        reserved_pebs   29
        alignment       1
        data_pad        0
        vol_type        3
        name_len        4
        usable_leb_size 258048
        used_ebs        29
        used_bytes      7483392
        last_eb_bytes   258048
        corrupted       0
        upd_marker      0
        name            boot
...

We see some familiar information. The partition table of the system image is the product packaged by tina sdk

How to boot the system in Ubuntu?
Use printenv to check the environment variables of uboot. The following are the important parts:

boot_normal=sunxi_flash read 45000000 ${boot_partition};bootm 45000000
boot_partition=boot
bootcmd=run setargs_nand_ubi boot_normal

partitions=mbr@ubi0_0:boot-resource@ubi0_1:env@ubi0_2:env-redund@ubi0_3:boot@ubi0_4:rootfs@ubi0_5:dsp0@ubi0_6:recovery@ubi0_7:UDISK@ubi0_8:
root_partition=rootfs

setargs_nand_ubi=setenv bootargs ubi.mtd=${mtd_name} ubi.block=0,${root_partition} earlyprintk=${earlyprintk} clk_ignore_unused initcall_debug=${initcall_debug} console=${console} loglevel=${loglevel} root=${nand_root} rootfstype=${rootfstype} init=${init} partitions=${partitions} cma=${cma} snum=${snum} mac_addr=${mac} wifi_mac=${wifi_mac} bt_mac=${bt_mac} specialstr=${specialstr} gpt=1
ubi_attach_mtdnum=3

Just the above lines are enough. For us, only the first three lines play a key role
bootcmd is a variable executed when uboot is started, and its content is run setargs_nand_ubi and boot_normal

Where setargs_nand_ubi is used to set bootargs, which is something Linux cares about
We mainly look at boot_normal

boot_normal roughly means that the flash tool reads the data of ${boot_partition} (boot after parsing) to the memory 0x45000000, and then bootm boots the kernel at 0x45000000

Therefore, the simple way is to write our own OS program to the boot partition in nand. In theory, it is OK

Build nand and guide your own system

At first, I wanted to use the xfel tool of xboot to write data to nand, but I found that it was not implemented, so it would be more convenient to skip it first and wait for subsequent support

Device / config / chips / D1 / configs / Nezha in tina sdk_ min/sys_ partition. The Fex file is the configuration information of the pack. According to the file, the pack command will boot IMG is packaged into the boot partition of nand. This is what we want, so the easiest way is to replace our own bin file and call boot IMG, and then execute pack in tina sdk to generate tina_d1-nezha_min_uart0.img contains our code

Then use Quanzhi's tool to transfer tina_d1-nezha_min_uart0.img burn to Nezha motherboard The first step is finished

So you can boot normally? The answer is No

In the front, the boot instruction of uboot uses boot 45000000, which boots the linux kernel and contains some things of the boot protocol. As a bare metal program, we can jump to 0x45000000 between the go commands of uboot and run boot_ Change normal to sunxi_flash read 45000000 ${boot_partition};go 45000000 is enough, but at present, tina's default uboot does not compile the go instruction. Enter Lichee / brand-2.0/u-boot-2018 directory, execute make menuconfig, then select the go instruction in command line interface -- > boot commands, save it, recompile it, and package it once

The default environment variable information of tina uboot is in the file device / config / chips / D1 / configs / Nezha / env In CFG, you can set boot_ If normal is changed and then compiled, there is no need to modify the environment variables in the uboot interactive interface

Power on

[the external link image transfer fails. The source station may have an anti-theft chain mechanism. It is recommended to save the image and upload it directly (img-qwssfsuy-164558186288) (/ assets / uploads / files / 1623079923978-d1-rt-smart. PNG)]

bingo!

Boy, the next step is to run your Dreeam OS on Nezha!

The last supplementary note: RISC-V chip runs in SBI environment and S Mode, so the code in M mode of bare metal program cannot run normally

Original link: https://bbs.aw-ol.com/topic/132/
Quanzhi online developer exchange Penguin Group (24-hour online answer of customer service robot): 498263967
Resource acquisition and problem discussion can be conducted in Quanzhi online developer community: https://www.aw-ol.com/
Official account and developer's latest developments can be concerned about WeChat online.

Keywords: Embedded system RTT

Added by rskandarpa on Wed, 23 Feb 2022 04:21:53 +0200