Record my experience of using uboot on mini2440

Record my tortuous experience of using uboot on mini2440.

First, I used the code that came with the board: u-boot-1.1.6. But when compiling, it always prompts that there is an error. I don't know if this version is the same as tekk's version. I modified some places myself, but I feel that the compilation system of uboot is different from that of general open source software. When compiling, it always prompts that the implementation of a function cannot be found, that is, undefined reference to _,,,,, the Internet says that you need to add options such as nostdlib in the makefile, but it still cannot compile.

Later I downloaded tekk's version, and it seemed that everyone was using his version.

Let me first talk about the difference between supervivi and uboot.

The mini2440 is programmed with supervivi in ​​norflash. It is very convenient to use, but one disadvantage of supervivi is that it does not support booting from nfs. Although it supports booting the root file system of nfs, it does not support booting the kernel of nfs. In other words, it is possible to put the root file system on the nfs server, but supervivi does not support putting the compiled kernel on the nfs server.

Generally speaking, when we are developing drivers, we often need to modify the kernel and then recompile it. Therefore, if you use supervivi, you need to use dnw to burn the kernel. This is actually not very convenient.

I think the advantage of uboot over supervivi is that uboot supports loading kernels on nfs servers. In this way, every time we modify the kernel, we don't need to use dnw to burn it, uboot will automatically help us complete this task. Therefore, I decided to compile uboot and burn it to nandflash, and keep supervivi in ​​norflash.

In addition, the kernel formats supported by supervivi and uboot are different. When burning the kernel with supervivi, the zImage file is burned, while the image file after burning with uboot is processed: zImage.img. Compared with zImage, this file has an additional file header, which is generated by the zImage file through the mkimage tool of uboot. Therefore, supervivi and uboot cannot load the same kernel file.

I downloaded the uboot code from this link: https://github.com/tekkamanninja/U-boot-2009.11_tekkaman . I also studied how to use github, but I still don't know how to search for open source code on github. The search seems to be not as intuitive as sourceforge. I have been looking for kernel projects, but I don't have a suitable project. I hope friends who see the blog can recommend some.

After downloading, unzip it in the virtual machine and compile it. The code needs to be placed in the Linux disk itself, not the shared Windows disk. Before compiling, you need to modify the Makefile and set the variable CrossCompile to arm-linux-. The instructions for compiling uboot are as follows: make distclean; make mini2440_config; make. You need to modify the crosscompile variable first and then compile, otherwise an error will occur.

After the compilation is completed, you can use supervivi to burn and then test.

In the process of using uboot, two problems are mainly solved:

1. The problem of uboot environment variables not being saved. In the uboot interface, you can modify environment variables using setenv and saveenv. Because tekk sets the environment variables to boot from nfs, and the IP addresses are hardcoded in the code, these environment variables need to be modified in uboot. As a result, after each modification, it is found that when starting the system, a prompt such as bad CRC or NAND, using default environment will appear, which means that the modified environment variables do not work.

After careful analysis of the flash partition, in the Linux kernel code of mini2440, the flash partition table is in the file mach-mini2440.c;

static struct mtd_partition mini2440_default_nand_part[] = { 
        [0] = { 
                .name = "supervivi", ;This is the partition where the bootloader is located. You can place u-boot, supervivi, etc., corresponding to
/dev/mtdblock0 
                .size = 0x00040000, 
                .offset = 0, 
        }, 
        [1] = { 
                .name = "param", ;This is the parameter area of ​​supervivi, which is actually part of the bootloader. If u-boot is too
large, you can overwrite this area without affecting system startup, corresponding to /dev/mtdblock1 
                .offset = 0x00040000, 
                .size = 0x00020000, 
        }, [2] = { 
                .name = "Kernel", ;The partition where the kernel is located is 5M in size, which is enough to hold most of the customized giant kernels, such as the kernel using a larger Linux Logo pictures, etc., corresponding to /dev/mtdblock2 
                .offset = 0x00060000, 
                .size = 0x00500000, 
        }, 
        [3] = { 
                .name = "root", ;File system partition, friendly arm is mainly used to store yaffs2 file system content, corresponding to /dev/mtdblock3
                .offset = 0x00560000, 
                .size = 1024 * 1024 * 1024, // 
        }, 
        [4] = { 
                .name = "nand", ;This area represents the entire nand flash, which is mainly reserved for use. For example, in the future, the entire nand flash can be backed up by accessing and reading /dev/mtdblock4 through an application. 
                .offset = 0x00000000, 
                .size = 1024 * 1024 * 1024, // 
        }

}  

Obviously, our uboot environment variables should be placed in the param partition, that is, the part from 0x40000 to 0x60000. Then we go to the uboot code, there is a location to save the environment variables, in the file include/configs/mini2440.h: #define CONFIG_ENV_OFFSET 0x60000. From here we can see that the environment variables overlap with the location of the linux kernel, so there is an error in loading the environment variables. For this reason, we need to modify here: #define CONFIG_ENV_OFFSET 0x60000. After the modification, compile, and re-download, we find that the environment variables can be saved.

2. Here are my environment variable settings:

If booting the system from nandflash:

[u-boot@MINI2440]# printenv
bootargs=noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0,115200
bootcmd=nboot 30008000 0 0x60000;bootm
bootdelay=1
baudrate=115200
ethaddr=08:08:11:18:12:27
ipaddr=192.168.17.135
serverip=192.168.17.1
gatewayip=192.168.17.1
netmask=255.255.255.0
stdin=serial
stdout=serial
stderr=serial
ethact=dm9000
tekkaman=hello wusq

If the system is started from nfs:

bootargs=noinitrd root=/dev/mtdblock3 init=/linuxrc console=ttySAC0,115200

bootdelay=1
baudrate=115200
ethaddr=08:08:11:18:12:27
ipaddr=192.168.17.135
serverip=192.168.17.1
gatewayip=192.168.17.1
netmask=255.255.255.0
stdin=serial
stdout=serial
stderr=serial
ethact=dm9000
tekkaman=hello wusq
bootcmd=nfs 0x30008000 192.168.17.2:/opt/FriendlyARM/mini2440/linux-2.6.32.2/zImage.img; bootm

If you want to load the root file system on nfs, you also need to modify bootargs: similar to the following

bootargs=noinitrd root=/dev/nfs rw nfsroot=192.168.0.1:/home/tekkaman/working/nfs/rootfs 

ip=192.168.0.2:192.168.0.1::255.255.255.0 console=ttySAC0,115200 init=/linuxrc mem=64M

3. The last question is how to turn off the buzzer sound when uboot starts. I refer to the method on the Internet: http://www.arm9home.net/read.php?tid-4735-fpage-6.html

In this version, there are two places to set the buzzer to sound when U-boot starts.
The first place is in:
boardmini2440mini2440.c file,
#if defined(CONFIG_MINI2440_LED)
        gpio->GPBDAT = 0x00000181;
#endif


The second place is the display_banner function of lib_armboard.c:
#if defined(CONFIG_MINI2440_LED)     
        S3C24X0_GPIO * const gpio = S3C24X0_GetBase_GPIO();
        gpio->GPBDAT = 0x101; //tekkamanninja
#endif

Solution:
Step 1: Modify the boardmini2440mini2440.c file in the first place:
Change it to:
#if defined(CONFIG_MINI2440_LED)
        gpio->GPBDAT = 0x00000180;
#endifStep


2: Check the start_armboot function in the file to see if the following code exists:
#if defined(CONFIG_MINI2440_LED)     
        gpio->GPBDAT = 0x0; //tekkamanninja
#endif

In this way, the buzzer will sound for a while when the U-boot system starts, and stop when the startup is completed, so there will be no long beeping phenomenon.

If you do not want the buzzer to sound, change the display_banner function in lib_armboard.c:
#if defined(CONFIG_MINI2440_LED)     
        S3C24X0_GPIO * const gpio = S3C24X0_GetBase_GPIO();
        gpio->GPBDAT = 0x101; //tekkamanninja
#endif

Change to:
#if defined(CONFIG_MINI2440_LED)     
        S3C24X0_GPIO * const gpio = S3C24X0_GetBase_GPIO();
        gpio->GPBDAT = 0x100; //tekkamanninja
#endif

In this way, you can use uboot to boot the kernel.