led.bin: start.o
arm-linux-ld -Ttext 0x0 -o led.elf $^
arm-linux-objcopy -O binary led.elf led.bin
arm-linux-objdump -D led.elf > led_elf.dis
gcc mkv210_image.c -o mkx210
./mkx210 led.bin 210.bin
%.o : %.S
arm-linux-gcc -o $@ $< -c
%.o : %.c
arm-linux-gcc -o $@ $< -c
clean:
rm *.o *.elf *.bin *.dis mkx210 -fExplanation: The Makefile for the real project separates the compilation and linking process of the program. (When we usually compile with gcc ac -o exe, we actually complete the compilation and linking process in one step. In fact, internally, compilation and linking are always carried out separately and independently. Compilation uses the compiler gcc, and linking uses linker ld.)
The led.elf obtained by the linker is actually our executable program (if it is under the OS, this led.elf can be executed) but in the embedded bare metal, what we need is a file that can be programmed (programmable The file is called the mirror image), so we need to use this led.elf as the raw material to only make the mirror image, and the production tool is arm-linux-objcopy in the cross-compilation tool chain
We use the arm-linux-objdump tool for decompilation (disassembly). Disassembly is actually to reverse the compiled executable program in elf format to obtain the corresponding assembler program and its assembly source code.
- The program mkv210_image.c is actually not executed on the development board, but in the host Linux, so gcc is used instead of arm-linux-gcc when compiling mkv210_image.c. After mkv210_image.c is compiled and linked, an executable file can be obtained. This executable file can process the executable burning file (led.bin) started by USB into the executable burning file (210.bin) started by SD card.
- When the 210 is used as a bare machine, the written program is equivalent to BL1 (the SD card includes the BL1 header file (16 bytes), and the USB boot does not include the BL1 header file (16 bytes)).
210 OS boot process review: SoC on-chip iROM runs the solidified BL0 program, BL0 initializes FLASH, reads BL1 from FLASH and loads it into SoC on-chip iRAM to run BL1, BL1 loads BL2 from FLASH to iRAM to run, BL2 initializes DRAM, and loads it from FLASH Load OS to DRAM to run.
As a bare metal experiment:
Details: BL0 is running, and the boot channel (USB or SD) is judged by OMpin. If it is an SD card boot, it will read BL1 from the onboard eMMC card by default. If the first sector of BL1 on the onboard eMMC card is damaged, it will read from SD channel 2. The external SD card reads BL1.
Checksum will be done after reading BL1 (in the memory area 16KB-16Bytes that needs to be checked, all the contents in the memory will be added in units of bytes, and the final added sum is the checksum, and mkv210_image.c will check The checksum is placed in the third word of the BL1 header file (ie 0xd0020008--0xd002000c), and BL0 will also calculate the checksum.
By comparing the checksum calculated by BL0 and the checksum in the BL1 header file, you can know whether BL1 is correct), and judge whether BL1 is correct. If it is correct, load BL1 to iRAM to run the BL1 program (the BL1 program here refers to 16 bytes of BL1 header + the program we wrote + empty 0)
If it is booted from USB, checksum is not performed after reading the BL1 program, so the 16-byte BL1 header file is not cared, so our program does not need to include the BL1 header file. We put the written program into iRAM 0xd0020010 and run it.
The reason to use mkv210_image.c is to burn the program we wrote plus the 16-byte BL1 header file to the SD card to start. The BL1 program corresponding to the SD card boot mode has 16KB (16 bytes BL1 header file + led.bin + empty 0); the BL1 program corresponding to the USB boot mode only has led.bin.
For more embedded study notes and practical projects, click here to get free