U-boot-2014.10 transplantation 15th days ---- nor flash operation, uboot2014.10 Transplantation

Source: Internet
Author: User

U-boot-2014.10 transplantation 15th days ---- nor flash operation, uboot2014.10 Transplantation

Hardware Platform: tq2440

Development Environment: Ubuntu-3.11

U-boot: 2014.10

This article allows reprint, please indicate the source: http://blog.csdn.net/fulinus


Remove nor flash write protection from running u-boot command lines to remove nor flash write protection:
TQ2440 # flinfoBank # 1: EON EN29LV160AB flash (16 x 16)  Size: 2 MB in 35 Sectors  AMD Legacy command set, Manufacturer ID: 0x1C, Device ID: 0x2249  Erase timeout: 30000 ms, write timeout: 100 ms  Sector Start Addresses:  00000000   RO   00004000   RO   00006000   RO   00008000   RO   00010000   RO   00020000   RO   00030000        00040000        00050000        00060000        00070000   RO   00080000        00090000        000A0000        000B0000        000C0000        000D0000        000E0000        000F0000        00100000        00110000        00120000        00130000        00140000        00150000        00160000        00170000        00180000        00190000        001A0000        001B0000        001C0000        001D0000        001E0000        001F0000   
Write protection is enabled for blocks with RO IDs, which are provided by u-boot itself. Use the following command to unprotect all blocks, but restart the instance:
TQ2440 # protect off allUn-Protect Flash Bank # 1TQ2440 # flinfo         Bank # 1: EON EN29LV160AB flash (16 x 16)  Size: 2 MB in 35 Sectors  AMD Legacy command set, Manufacturer ID: 0x1C, Device ID: 0x2249  Erase timeout: 30000 ms, write timeout: 100 ms  Sector Start Addresses:  00000000        00004000        00006000        00008000        00010000        00020000        00030000        00040000        00050000        00060000        00070000        00080000        00090000        000A0000        000B0000        000C0000        000D0000        000E0000        000F0000        00100000        00110000        00120000        00130000        00140000        00150000        00160000        00170000        00180000        00190000        001A0000        001B0000        001C0000        001D0000        001E0000        001F0000      TQ2440 # 

If you do not have norflash, you can skip this step. Before u-boot starts from nor flash, you should first try to use norflash, as if you were operating on sdram. The nor flash write operation writes 16 bytes starting from 0x33F80000 to the 0 address of nor flash:
TQ2440 # cp.b 33f80000 0 10
If you have not disabled the DEBUG definition, the following information will be displayed: flash_is_busy: 0
Fwc addr 00000aaa cmd aa 00aa 16bit x 16 bit
Fwc addr 00000554 cmd 55 0055 16bit x 16 bit
Fwc addr 00000aaa cmd a0 00a0 16bit x 16 bit.
Norflash comparison
TQ2440 # cmp.b 0 33f80000 10Total of 16 byte(s) were the same
The same description is written in.
Norflash read Operations
TQ2440 # md.b 33f8000033f80000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................33f80010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................33f80020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................33f80030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................TQ2440 #

You may be wondering, why are they all 0? Didn't I copy the code to the position 0x33F80000? Why is it zero? We carefully discovered the u-boot printed information and found that u-boot has been redirected to: U-Boot code: 33F80000-> 33FAA0E0 BSS: -> the code segment of 33FAF838 u-boot plus the BSS segment length is 194616 bytes, about 190 KB
...... Ramsize: 04000000 SDRAM space 64 M
TLB table from 33ff0000 to 33ff4000 TLB redirected to 33ff4000 move 0x4000 (16 K) Up)
Top of RAM usable for U-Boot at: 33ff0000 u-boot available space vertex position on 33ff0000 there is 1 MB of reserved space (hide mem)
Reserving 190 k for U-Boot at: 33fc0000 relocate u-boot to 0x33FC0000
Reserving 4160 k for malloc () at: 33bb0000 the first address of the heap is at 0x33BB0000, and 4160K is the heap vertex address, that is, 0x33FC0000, that is, the first address of the u-boot code.
Reserving 28 Bytes for Board Info at: 33baffe4
Reserving 160 Bytes for Global Data at: 33baff44
New Stack Pointer is: 33baff38

That is to say, the u-boot code is located at 0x33FC0000 again, and the later 4160K is heap, And the bytes in the heap are cleared by 0. Therefore, when we read the bytes at 0x33f80000, they are all 0. Read the content of the starting address 0x33FC0000-0x10:
TQ2440 # md.b 33FBFFF033fbfff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................33fc0000: be 00 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5    ................33fc0010: 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5    ................33fc0020: 60 00 f8 33 c0 00 f8 33 20 01 f8 33 80 01 f8 33    `..3...3 ..3...3
It can be seen that starting from 0x33FC0000 is the starting position of the u-boot code. Modify the value of CONFIG_SYS_TEXT_BASE in the tq2440.h file to run the Code directly from the redirection location, so that the u-boot does not need to be redirected:
#define CONFIG_SYS_TEXT_BASE    0x33FC0000
Compile, burn, and run. Note that the installation and operation address must also be changed. U-boot prints the same information as above: U-Boot 2014.10 (Nov 08 2014-17:39:09)


U-Boot code: 33FC0000-> 33FEA0E0 BSS:-> 33FEF838
CPUID: 32440001
FCLK: 405.600 MHz
HCLK: 101.400 MHz
PCLK: 50.700 MHz
Monitor len: 0002F838
Ramsize: 04000000.
TLB table from 33ff0000 to 33ff4000
Top of RAM usable for U-Boot at: 33ff0000
Reserving 190 k for U-Boot at: 33fc0000
Reserving 4160 k for malloc () at: 33bb0000
Reserving 28 Bytes for Board Info at: 33baffe4
Reserving 160 Bytes for Global Data at: 33baff44
New Stack Pointer is: 33baff38
RAM Configuration:
Bank #0: 30000000 64 MiB
......
U-boot is burned to nor flash: 1. Write Protection 2. nor flash is erased;
TQ2440 # erase all

3. Copy the size of the byte starting with 0x33FC0000 address to the start point of the 0 address of nor flash. Flash writing is slow, waiting for N long ...... after waiting for N long, I suddenly thought that J-link seemed to be able to write directly to Nor flash. In this way, I wrote clean code. However, I still have to wait for it to finish writing and see what will happen. After waiting for half an hour, I still don't know how to stop it. Forget it! Follow the instructions in the document: Use JLINK to burn Uboot to NOR_FLASH configuration process _ 1
The write speed is similar to that of snail bait. Nor flash! How Do I Love You between you and nand flash? It seems that I am wrong. I set this frequency too low, so it is very slow to write. I burned it into nor flash, but it was not started successfully. Why? Continue tomorrow.



































Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.