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.