H9200m Development Board experiment document

9200m Development Board experiment documentation

U-boot transplantation based on h9200m Development Board: Our transplantation belongs to the board-level transplantation, that is, our processor has been supported by uboot, to enable the processor to run uboot, It is a board-level porting. For board-level transplantation, you need to create a directory for the target board in the uboot source code/board/, and then create the corresponding flash in it. c. at91rm9200dk. c, at45.c and Link Description file u-boot.lds and makefile, config. MK is enough. Board-level porting also includes environment variable settings.

Procedure:
Because our development board is very similar to the at91rm9200dk currently supported by uboot, the above files do not need to be re-written by themselves. As long as you copy them and make some changes, they can run normally. Therefore:
1. Create a h9200m directory in the Board directory;
2. Copy the Board/at91rm9200dk/* to the directory we just created;
3. Because the norflash of h9200m is different from that of the at91rm9200dk board, we use a flash chip of 4 MB produced by Fujitsu, so we need to modify the flash in h9200m. the C file is actually the Flash Driver.
A. Add the following Fujitsu flash data structure to the original data structure array.
According to the 29lv320be manual, the chip has 8 8 KB and 63 64kb segments.

OrgDef  OrgMBM29LV320BE[] =

{

  { 8,  8*1024 }, /*    8 *  8 kBytes sectors  */ 

  { 63, 64*1024 }, /*  63 * 64 kBytes sectors  */ 

};

B. Add a macro definition

# Define flash_read_reset 0xf0 // macro that defines the reset command

C. In the flash chip recognition function of flash_identification
In the 29lv320be manual, we recommend that you reset the chip first when entering the Autoselect mode to ensure that the chip is in Read mode.
1) Add

/*  Read Reset  */ 

MEM_FLASH_ADDR1 = FLASH_CODE1;

MEM_FLASH_ADDR2 = FLASH_CODE2;

MEM_FLASH_ADDR1 = FLASH_READ_RESET;

Because the chip operation is closely related to the chip actually used, you need to configure the information of the corresponding chip.
2) change suppliers to Fujitsu

/*  Vendor type  */ 

info->flash_id = FUJ_MANUFACT & FLASH_VENDMASK;

printf ("FUJITSU and AMD: ");

3) because we know the flash model used by h9200m, we can remove the program for automatically determining the chip model in flash. C and change it

/*  AMD Flash  */ 

info->flash_id |= AMD_ID_LV320B & FLASH_TYPEMASK; // flash_id = 0x000422F9

 printf ("MBM29LV320B (32Mit, bottom boot sect)/n");

D. In the flash chip information display function of flash_print_info
1) change the information to Fujitsu

case (FUJ_MANUFACT & FLASH_VENDMASK):

  printf ("FUJITSU and AMD: ");

  break;

2) Similarly, we do not need to judge the chip model. Therefore, we should remove the statement and change it

switch (info->flash_id & FLASH_TYPEMASK) {

  case (AMD_ID_LV320B & FLASH_TYPEMASK):

     printf ("MBM29LV320BE (32Mit, bottom boot sect)/n");

     break;

  default:

     printf ("Unknown Chip Type/n");

     return;

}

E. In the flash erase flash erasure Function
1) Change the producer to Fujitsu. Otherwise, the chip cannot be erased.

if ((info->flash_id & FLASH_VENDMASK) != (FUJ_MANUFACT & FLASH_VENDMASK)) {

 return ERR_UNKNOWN_FLASH_VENDOR; 

}

4. In makefile under the uboot root directory, add the following in at91rm9200dk_config

h9200m_config : unconfig

   @$(MKCONFIG)  $(@:_config=)  arm  arm920t  h9200m  NULL  at91rm9200

Where
Arm: CPU architecture (ARCH)
ARM920T: CPU type, which corresponds to the CPU/ARM920T sub-directory.
H9200m: The Development Board model, which corresponds to the Board/h9200m directory.
Null: developer/or distributor ).
At91rm9200: On-Chip System (SOC), corresponding to the sub-directory of CPU/ARM920T/at91rm9200.

5. Select board/h9200m/at91rm9200dk. C.

/* Arch Number of AT91RM9200DK-Board */

GD-> BD-> bi_arch_number = mach_type_at91rm9200;

Change to GD-> BD-> bi_arch_number = mach_type_at91rm9200dk to correspond

The hardware Number of the Target Board corresponds

6. Last

Copy include/configs/at91rm9200dk. h and change it to h9200m. h to modify the content:

# Change define pllar_val0x20263e04 to 0x2026be04.

Set the CPU operating frequency to 180 MHz.

# Change define sdram10x20000080 to 0x20000020.

The read mode of SDRAM is not required.


# Else

# Define _env_addr (phys_flash_1 + 0xe000) define env

Highest-end flashrom (phys_flash_1 + 0x3f0000)

# Define pai_env_size0x2000/* 0x8000
*/Change 0x2000 to 0x10000 because the flash high-end is a sector every 64 K.

# Define phys_flash_size0x200000/* 2 megs main flash

*/Modify the Flash ROM size to 0x400000 /*

4 megs main flash */The Flash capacity on our board is 4 MB

Add the following environment variables under # define config_baudrate 115200:

# define CONFIG_ETHADDR  00:11:43:43:93:5F

# define CONFIG_IPADDR   192.168.0.139

# define CONFIG_SERVERIP 192.168.0.123

# define CONFIG_BOOTARGS "root=/dev/ram rw 

initrd=0x21400000,6000000 ramdisk_size=15360 console=ttyS0,115200 mem=32M"

# define CONFIG_BOOTCOMMAND "run ramdisk;run image;run boot"

# define CONFIG_EXTRA_ENV_SETTINGS  /

"image=cp.b 10020000 21000000 13ffff/0"  /

"ramdisk=cp.b 10160000 21400000 28ffff/0"  /

"boot=bootm/0"  /

""

Okay, so far, our uboot has been configured. To compile the commands that can be recognized by arm, we need to build a cross-compilation environment called cross-compilation, that is to say, the compiler is run on one machine, but the code produced by the compiler runs on another Architecture Machine. Specifically, we use an X86 PC as the development host, build a cross-compilation environment and compile a program that can recognize arm commands (PC X86 architecture, our h9200 Development Board is an ARM architecture ). Because we not only compile uboot and Linux kernel, but also some other application software, those applications require the support of other common library files, such as the libssl library, this library file is required for compiling SSL-related applications. For convenience of future development, we use the development toolkit officially provided by uboot for the ARM architecture, embedded Linux development kit. Of course, we can also compile a cross-compilation platform by ourselves. For details, see the XXXXXXXX document. After downloading the development kit, run. /install [-D <dir>] [<cpu_family1>], where [-D <dir>] is the directory to be installed, [<cpu_family1>] For the CPU architecture to be installed, select arm and enter the command. /install [-D <dir>] After the ARM platform is set up, we need to modify the Linux environment variables so that the tools used for cross-compilation can be found during compilation, enter export Path = $ path: [-D <dir>] (development kit installation path)/usr/bin command. Go to the uboot source code directory. Because uboot selects the source code directory as the code output directory by default during compilation, you can define an environment variable build_dir, let it point to the desired uboot code output directory. We assume that we want to output it to/opt/uboot, So execute the command, mkdir-P/opt/uboot & export build_dir =/opt/uboot, then you can start compiling. First make distclean, then make h9200m_config, and finally make all, in the/opt/uboot directory there are u-boot.bin, U-boot, u-boot.srec files, where the u-boot.bin is to burn into the norflash in the Board binary file.

Burn uboot. Bin into the norflash on the board so that the target board can run uboot 1. Configure the terminal so that we can see the output of the target board and control the target board. Enter minicom-s to move the cursor to serial port setup and press enter to enter the first letter listed in each option in the serial port setup option to modify the serial device to/dev/ttys0 bps/PAR /bits is set to 115200 8n1 hardware flow control is set to no software flow control is set to No. Finally, Press ESC to return to the main menu and choose save setup as DFL to save as the default setting.

2. Start the in-chip Rom program and download uboot to the SDRAM to run the program and write it into norflash. There are several methods: Use a dedicated writer, but it is unrealistic. Use the JTAG debugger, the cost is too high. It is a good way to use a program running on the target board, But where should we find this program? In uboot, is it possible to use the uboot. Bin compiled by us? Yes! However, there is a precondition that include/configs/h9200m is configured. h: # define config_skip_lowlevel_init 1, which is used to skip the initialization of the underlying CPU during uboot. However, this problem occurs again, to make the target board run properly, you must initialize the CPU underlying layer. we can define the macro that skips the initialization of the CPU underlying layer, because of the special nature of at91rm9200 of ATMEL, the chip integrates the Atmel initialization program at91rm9200, so you can skip the uboot initialization program for the CPU underlying layer, however, on our h9200m Development Board, the ultimate goal of ATMEL's initialization program is to use the XMODEM protocol to download the program into the CPU chip RAM, and the on-chip RAM only has 16 K of the Zone, it cannot accommodate our uboot. bin, what should I do? You can use the loader provided by the manufacturer. bin to put our uboot. bin is loaded into the SDRAM to run, but even if the uboot. the bin can run normally and cannot be burned into norflash, because there is no initialization for the CPU underlying layer! Unless we do two uboot. bin, a program that contains the underlying initialization program, one that does not, and the one that does not have the underlying initialization program. It is a good way to debug uboot, there will be no loss in the frequent reading and writing of SDRAM, But Flash is different. Flash has a life limit, and Flash will be decommissioned when it is erased more. (The above description may be a bit difficult. Please straighten it out. ^_^)

But here we use the uboot provided by the manufacturer (I am a little lazy, after all, I have compiled a uboot, haha !). After the terminal is configured, connect the h9200m patch cord J100 to 2-3 short connections (select the in-chip Rom to start), reset the system, open the minicom terminal, and "cccccccccc..." will appear in the terminal .....", At this time, the at91rm9200 in-disk ROM program has started to run. Wait for your next step, press Alt + A, S, and use the XMODEM protocol to send loader. binfile, then the supervisor will prompt to download uboot. After the download is complete, "ccccccccccc ......" will continue to appear ........." Continue to use the XMODEM protocol to send the uboot. binfile. At this time, uboot. Bin is sent to the system's SDRAM. After sending the file, uboot starts to run. A prompt> U-boot is displayed.

3. Erase flash before writing to flash, you need to erase it: uboot> protect off all; remove flash sector write to protect uboot> erase all; erase all flash sectors

4. Run uboot. bin to flash, enter the command uboot> TFTP 20000000 at the uboot prompt. After the file is sent to the system's SDRAM, the actual number of uploaded bytes is displayed, remember the hexadecimal representation, and type the following command: uboot> CP. B 20000000 10000000 xxxx; write data sent to the SDRAM into flash XXXX as the number of bytes

OK, our uboot has been burned into norflash, unplug the board power supply, and connect 1-2 of the Jumper J100 (select the off-chip storage device to start). Our uboot should be able to start normally.

The next step is to compile the kernel on the development host (PC): First of all, download the kernel, decompress the tar package of the kernel, and install the corresponding patch, then run make at91rm9200dk_defconfig make menuconfig to configure the kernel. The Kernel configuration should be selected according to actual needs. For debugging convenience, let the Kernel support the NFS file system, nfsroot, BOOTP, or DHCP. After configuration, save and exit and execute make. After the kernel is compiled successfully, copy the vmlinuz file under the kernel source code to the uboot output directory, that is, $ build_dir, then run arm-Linux-objcopy-O binary vmlinuz Linux. bin converts vmlinuz from ELF format to binary Linux. bin gzip-9 Linux. bin: compress the Linux kernel to save space and generate the linux.bin.gz file. /tools/mkimage-A arm-O Linux-T kernel-C gzip-A 20008000-e 20008000/-N 'linux-kernel '-D linux.bin.gz uimage the image file uimage is automatically loaded and our Linux kernel is complete, copy the uimage to the tftpboot directory (tftpboot is the root directory of the TFTP service)

The next step is to create a root file system: Because the embedded Linux development kit we installed earlier has integrated a root file system for arm, therefore, you only need to make a slight modification. 1. Open the TFTP service on the PC, and the TFTP service is controlled by the xinetd service;
2. Enable the DHCP service on the PC.
Option root-path "/XXX"; <-- this is the NFS output directory.
: FILENAME "/tftpboot/uimage ";
Be careful when enabling this service. Make sure that the service is disconnected from the thiz Intranet. Otherwise, the MIS department will ask you to settle the account, but it is none of my business. ^_^ !!!!
3. Open the NFS service on the PC and use the arm directory under the development tool directory as the NFS output directory;
4. Copy the device files on the PC/dev to the dev directory in the arm directory under the development tools directory.
CP-AP/dev/* XXX/ARM/dev/
5. Run the command in the xxx/ARM/etc directory.
Touch mtab
Change the default running level in inittab to 1. Because there are few resources on the board, do not enable any services.
Cat fstab <EOF
None/proc defaults 0 0
None/proc/bus/USB usbfs defaults 0 0
EOF
Okay. Now the root file system has been completed. Let's debug it together.

Enable minicom, connect 1-2 of the J100 patch cord on the h9200m board to the power supply, and press any key to enter the command switching mode when uboot is down, first, you have to modify some environment variables printenv and you will see the default environment variables of uboot. Most of them are familiar with the default environment variables. They are all included/configs/h9200m. setenv bootargs root =/dev/nfs IP = 192.168.0.139 console =/dev/ttys0, 115200 mem = 32 m RW setenv bootcmd BOOTP 21000000/; run boot saveenv defined in H

Reset the target board. You will see that uimage is downloaded from the PC after the uboot countdown, decompress the Linux kernel, and then run the Linux kernel. When the kernel runs to the mounted root file system, you will find that the NFS root file system to be mounted (root =/dev/nfs in the bootargs variable of uboot tells the kernel), and then broadcast, after the DHCP response, the system sends the kernel-related information, so the kernel knows where the NFS root file system is and mounts it. After everything is normal, the familiar Linux Command Line appears, OK, we have finished porting the h9200m-based Linux operating system.

The Linux operating system is running, but it does not do anything. Isn't it too cheap? No, you have to find something to do for it. What should you do? Compile some application software that it wants to run! Compile a BitTorrent server and client. The BitTorrent server must be parsed by python. /configure -- prefix =/usr-share-Library & make install after a long wait, python will compile and install it, And the BitTorrent service will be executed to upload files, everything on the BT server is normal. Compile the ctorrent client and execute it. /configure & make: Execute the ctorrent file, and the file can be downloaded normally. Everything works on the BT client.

After all the experiments are completed, we can create a small root file system, further cut the Linux kernel, and finally write the kernel and root file system into flash, you will find that it is so painful to wait for uboot to burn a large file (that is, it is actually not big, just two or three megabytes !! (Profound understanding !!), If you are a perfect target, you can try to modify the uboot source code under the Board/h9200m/flash. int write_buff (flash_info_t * info, uchar * SRC, ulong ADDR, ulong CNT) of C multiple-character writing function. The original function is to continuously call write_word (Info, WP, data) single-word writing function, until all the writing is completed, but by reading the 29lv320be chip manual, the chip has the fast writing function (FAST Program). The fast writing mode flow is as follows:

The modified program is as follows:

Int write_buff (flash_info_t * info, uchar * SRC, ulong ADDR, ulong CNT)

{

Ulong WP, Data, result;

Int RC;

Int cflag, iflag;

Int chip1;

/* Check whether the target address to be written is in Word Alignment. That is, bit0 of the address must be 0 */

If (ADDR & 1 ){

Printf ("unaligned destination not supported/N ");

Return err_align;

};

/* Similarly, check whether the source address is word aligned */

If (INT) SRC & 1 ){

Printf ("unaligned source not supported/N ");

Return err_align;

};

/* Check if Flash is (sufficiently) erased */
Result = * (volatile 2010*) ADDR; // return 0 xFFFF

Data = * (volatile 2010*) SRC;

If (Result & Data )! = Data)

Return err_not_erased;

WP = ADDR; // Destination Address

Rc = err_ OK; // initial rc = err_ OK

If (CNT = 1)

Goto

Onebyte;

/*

* Disable Interrupts which might cause a timeout

* Here. Remember that our exception vectors are

* At address 0 in the flash, and we don't want

* (Ticker) exception to happen while the flash

* Chip is in programming mode.

*/

Cflag = icache_status ();

Icache_disable ();

Iflag = disable_interrupts ();

/* Set to fast mode */

Mem_flash_addr1 = 0xaa;

Mem_flash_addr2 = 0x55;

Mem_flash_addr1 = 0x20;

/* FAST program mode */

While (CNT> = 2)

{

Data = * (volatile 2010*) SRC); // get data from source

Mem_flash_addr1 = 0xa0; // command

* (Volatile 2010*) WP = (volatile 2010) data; // Program

/* Arm simple, non interrupt dependent timer */

Reset_timer_masked ();

/* Wait Until flash is ready */

Chip1 = 0;

Do {

Result = * (volatile 2010*) WP;

/* Check timeout */

If (get_timer_masked ()> pai_flash_erase_tout ){

Chip1 = err | TMO;

Goto

Quit;

}

If (! Chip1 & (Result & 0x80) = (Data & 0x80) // If word finished quit while

Chip1 = ready;

} While (! Chip1 );

/* Verify data */

If (* (volatile 2010*) WP! = Data)

{

Chip1 = err;

Goto

Quit;

}

/* Adjust src dst cnt */

SRC + = 2;

WP + = 2;

CNT-= 2;

}

Quit:

Mem_flash_addr1 = 0x90; // reset fast mode

Mem_flash_addr1 = 0xf0;

If (chip1 = ERR)

Rc = err_prog_error;

If (iflag)

Enable_interrupts ();

If (cflag)

Icache_enable ();

Onebyte:

If (CNT = 0) // return if all finished return RC;

Else

{

Data = (* (volatile u8 *) SRC) | (* (volatile u8 *) (WP + 1) <8 );

If (rc = write_word (Info, WP, data ))! = 0 ){

Return (RC );

}

SRC + = 1;

WP + = 1;

CNT-= 1;

}

Return RC;

}

Test, the write speed is indeed much faster.