Bootloader is very important for embedded devices, it involves a lot of hardware-related knowledge. For self-made embedded development board, it is also an unskippable step, so many people feel a headache for it. This article will use an excellent Bootloader Blob as an example to explain its operating principles and the porting process on the S3C44B0 general-purpose processor in detail to lay the foundation for subsequent software development on embedded devices.
1 Blob Introduction
Blob is an abbreviation of Boot Loader Object. It is a powerful Bootloader. It follows the GPL and the source code is completely open. Blob can be used for simple debugging, but also to start the Linux kernel. Blob was originally written by Jan-Derk Bakker and Erik Mouw for a board called LART (Linux Advanced Radio Terminal). The processor used was Strongarm SA-1100. Blobs have now been ported to many CPUs, including the S3C44B0.
MBA44B0 is a development board based on S3C44B0. This article will be based on the source code of the Blob running on the MBA44B0 development board, and then carry out Blob porting on its own development board.
The main configuration of the development board is:
â—‡ Samsung ARM7 processor S3C44B0;
â—‡ 2MB Flash, address range 0x0000 0000~0x0020 0000;
â—‡ 8MB SDRAM address range 0x0c00 0000~0x0c80 0000;
â—‡ 1 serial port, 2 LED lights;
â—‡JTAG interface;
The crystal oscillator is 6MHz and the system clock frequency is 60MHz.
2 Blob running process analysis
Figure 1 shows the Blob program startup process.
Blob compiled code definition up to 64KB, and this 64KB is divided into two stages to perform. The code for the first stage is defined in start.s and is 1KB in size. It includes the portion that starts execution at address 0x00000000 after the system is powered up. This part of the code runs in Flash. It includes the initialization of some registers of the S3C44B0 and the copying of the second phase of Blob code from Flash to SDRAM. Remove the first stage of the 1KB code, the rest of the code is the second stage of the code. The start file for the second stage is trampoline.s. After being copied to SDRAM, it jumps from the first stage to this file to start executing the rest of the code. The second stage has a maximum size of 63KB. The word trampoline has the meaning of "trampoline". Therefore, in this program, some BSS section settings, stack initialization, etc., are finally jumped to main.c to enter the C function.
Our transplant mainly needs to modify some of the above documents. Before doing the migration, you first need to understand the address space allocation of the memory. The definition of memory space is in /include/blob arch/mba44b0.h.
Figure 2 shows the memory space distribution in Flash. Figure 3 shows the memory space distribution in SDRAM after startup.
As shown in Figure 2, 2MB of Flash space is allocated to Blob, Kernel, and ramdisk, respectively. After the system is powered on, the first stage code is executed. After the corresponding initialization, the second stage code of the Blob is copied to the blob_abs_base RAM address, and then jumps to the second stage to start execution.
In the second stage, jump from assembly to C's Main() function and proceed as follows:
â—‡ External hardware initialization (serial port, USB, etc.)
â—‡ Load kernel from Flash into SDRAM kernel area;
◇ Load ramdisk area of ​​SDRAM from ramdisk in Flash;
â—‡ Depending on the user's choice, enter command line mode or start the kernel.
In the development board we use, the kernel uses uClinux. Due to the limited storage space of Flash, the uClinux kernel stored in Flash is compressed. Blob loads the compressed uClinux kernel to SDRAM address 0x0c300000. If you choose to start uClinux, then the compressed uClinux kernel will self-extract .Text segment to 0x0c00800 (see uClinux/arch/armnommu/Makefile), and then jump to this place and start running uClinux. The specific uClinux porting is not discussed in detail here.
In the SDRAM memory space allocation diagram, you can see the blob_base and blob_abs_base parts. Blob_abs_base Everyone already knows that Blob is copying its own second-stage code to the area where SDRAM is located, and blob_base is the area from which Blob is self-upgraded or debugged. For example, if the Blob can run normally, but for Flash's erase and write can not support very well, you can use the Blob already running to download the newly compiled Blob to the area in the SDRAM for debugging through the serial port. After the debugging is passed, the Blob can be written into Flash to overwrite the original Blob to upgrade. This eliminates the need to reprogram Flash by making minor changes to the blob, which reduces the number of flash writes.
3 Blob transplantation
With a certain understanding of the Blob's operation, you can perform specific Blob porting. The first thing to modify is the start.s file. The specific work is as follows:
â—† Mask off the watchdog WTCON;
â—† The configuration register SYSCFG temporarily turns off the cache and waits for the Blob to run stable before turning on and improving performance.
â—† Initialize the I/O register;
â—† Masked interruptions;
â—† Configure the PLLCON register to determine the main frequency of the system.
â—† Invoking ledasm.s, it is very important for the program to run normally when the serial port is not initialized.
â—† Invokes memsetup in memsetup-s3c44b0.s to initialize memory space, initialize SDRAM refresh rate, etc.
â—† Copy the second stage to SDRAM and jump to the second stage.
In ledasm.s, an assembly language driver for led is provided. There is also a led.c file in the Blob, which is the same as the ledasm.s principle. It is only called in the C language. Modify led is to facilitate the initial stage of debugging. Here according to their own development board to modify.
In memsetup-s3c44b0.s, modify the memory-related configuration in MEMORY_CONFIG and set the SDRAM refresh rate. The relevant source code is as follows:
MEMORY_CONFIG:
.long 0x11101002 /* for memory configuration,
SDRAM refresh speed configuration */
... /*This needs to be modified according to different circumstances*/
.long 0x20
.globl memsetup /* defines the global label so that it can be called by start.s*/
Memsetup:
Ldr r0, =MEMORY_CONFIG /* to configure */
Ldmia r0, {r1-r13}
Ldr r0, =0x01c80000
Stmia r0, {r1-r13}
Mov pc, lr /* program returns */
Trampoline.s does not need to be modified.
After entering Main (), the serial port transmission speed is set in the structure blob_status:
blob_status.downloadSpeed ​​= baud_115200;
blob_status.terminalSpeed ​​= baud_115200;
The initialization code of the serial port is defined in the function s3c44b0_serial_init(), which is in serial-s3c44b0.c. For S3C44B0 serial port, generally only need to initialize the following four registers serial port can work normally. If it does not work, the system clock setting may be different, and you only need to calculate the divisor according to the following formula:
Divisor=(int)(MCLK/(baud ×16))-1
Replace the following divisor. MCLK is the system clock frequency and baud is the baud rate.
/*serial-s3c44b0.c s3c44b0_serial_init() function to initialize the serial port 0 part */
REG(UFCON0) = 0x0; /* turns off fifo*/
REG(ULCON0) = 0x03; /* sets data bit 8, no parity, 1 stop bit*/
REG(UCON0) = 0x05; /* Pulse Interrupt, Interrupt Request or Query Mode */
REG(UBRDIV0) = divisor;/*Set baud rate*/
At this point, the initial migration has been completed. Run ./configure æ¦ith-board=mba-44b0-with-linux-prefix=http:// to configure. Here you can also add some switch options to configure, please refer to the Blob own documentation. If there are no errors, make can be compiled. If it is compiled correctly, you can get the blob in bin format under blob/src/blob and write it to Flash to run. About the link script of the first part and the second part of Blob, you can see the relevant link address in start-ld-script and rest-ld-script.in. The compiler links the program according to these addresses. As you can see in blob/src/blob/Makefile, the two phases are compiled with blob-start and blob-rest respectively, and finally they are combined into a complete Blob binary file by the dd command.
(1) Modification of command line In the Blob version used by the author, BackSpace cannot work, which is very inconvenient for debugging. Check the source code, you can find in the src / blob / lib / command.c, the GetCommand function defines the human-computer interaction section. Change the else if (c =='b' line to else if (c ==0x7f) to support the Backspace feature.
(2) Blob operation If there is no problem in the previous work, after blob/src/blob/blob files are written into Flash, you can see the welcome message from the serial port after power on. After loading the linux kernel and file system, wait for a few seconds. If there is no operation, the operating system will be started, otherwise the prompt appears:
Blob>
Indicates entering the Blob. Many commands are provided in this mode to facilitate hardware debugging, system upgrades, and system boot.
Blob commonly used commands are: blob, boot, xdownload, flashreload, dump, reblob, status, etc.
Different Flash operations are different. The author found that some problems occurred in writing Flash software through Blob. In order to facilitate debugging, I decided to write my own Flash driver.
(3) Flash driver programming Flash as a non-volatile memory, the role of the development board is to save data and power loss is not lost. The biggest difference between EEPROM and EEPROM is that it does not need to increase the voltage of a specific pin for Flash programming, but it can be programmed by writing a specific set of data to a specific address. In this way, it can be erased by software directly on the development board. It is not necessary to use a specific programmer. But its shortcomings are also very obvious: the operation is too complicated, SST39VF160 is a 16M bit Flash of SST company, 16 data line widths, a total of 2MB capacity, divided into 512 sectors, each sector has 4KB, or 32 blocks, 64KB each. Before programming Flash, the corresponding sector, block, or entire chip must be erased before programming.
Flash programming through S3C44B0 requires attention to the following points: First, the external address bus of the S3C44B0 is connected according to the width of the external data bus. For example, the external data bus of this development board is 16-bit wide, so that the address line A0 of S3C44B0 does not access the external address bus, but picks up from A1. Table 1 lists the address lines of the processor and external memory for different external data bus widths.
Flash programming requires writing a specific timing to Flash. If S3C44B0 addresses 0x5555, because the external bus is wrong by one bit, then the address signal sent from Flash appears to be 0xAAAA, and the operation cannot be completed correctly. Observe this, according to the Blob's own Flash driver, you can easily adapt to your own Flash driver.
Conclusion
According to the experience of the author, the Blob is transplanted on the S3C44B0. At present, it has been able to run stably on the development board; and it can be programmed to flash, view memory, and guide uClinux, which lays a good foundation for the subsequent development of the project.
Fan Motor,Blower Motor,Condenser Fan,Condenser Fan Motor
Wentelon Micro-Motor Co.,Ltd. , https://www.wentelon.com