u-boot-2011.06 transplant

Publisher:MeshulunLatest update time:2024-07-10 Source: elecfansKeywords:u-boot Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

Whether it is the nand_write_page_hwecc function or the nand_write_page_hwecc function, there is a for loop body like this inside:

for(i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {

…… ……

}

The three main variables are defined as:

eccsize= chip->ecc.size;

eccbytes = chip->ecc.bytes;

eccsteps = chip->ecc.steps;

Let's introduce the role of this loop: The number of bytes of hardware ECC that can be completed by the NandFlash controller of different CPUs at one time is different. For example, some CPUs can only complete 512 bytes of hardware ECC at a time, but if the NandFlash on the development board has 2048 bytes per page, what should we do? At this time, a loop body is used to get the hardware ECC of a page by looping multiple times. For example, in the above case, it is necessary to loop 4 times (2048÷512=4) to get the hardware ECC of the complete data in this page. In addition, the number of ECC bytes generated by different CPUs for each hardware ECC is also different, some are 3 bytes, and some are 4 bytes.

Then, the meanings of the three variables above are:

ecc.size: The number of bytes checked by hardware ECC each time

ecc.bytes: The number of bytes generated by each hardware ECC

ecc.steps: The number of times each page needs to perform hardware ECC

For S3C2440, hardware ECC can check 2048 bytes at a time and generate 4 bytes of ECC, so ecc.size should be 2048 and ecc.bytes should be 4. ecc.steps is obtained through calculation, that is, the size of each page of NandFlash can be known after the system is powered on, and this value divided by ecc.size is equal to ecc.steps. Therefore, for these three parameters, you only need to define the first two parameters in advance. These two parameters are defined and assigned in the board_nand_init function in the drivers/mtd/nand/s3c2440_nand.c file, namely:

nand->ecc.size = 2048;

nand->ecc.bytes = 4;

u-boot-2011.06 does not fully define the registers of the NandFlash controller of S3C2440, and there are errors, so we also need to modify it. Delete the content from line 167 to line 178 in the arch/arm/include/asm/arch-s3c24x0/s3c24x0.h file and add the following content:

struct s3c2440_nand {

u32 nfconf;

u32 nfcont;

u32 nfcmd;

u32 nfaddr;

u32 nfdata;

u32 nfmeccd0;

u32 nfmeccd1;

u32 nfseccd;

u32 nfstat;

u32 nfestat0;

u32 nfestat1;

u32 nfmecc0;

u32 nfmecc1;

u32 nfsecc;

u32 nfsblk;

u32 nfeblk;

};

Finally, we modify the s3c2440_nand_enable_hwecc function, s3c2440_nand_calculate_ecc function, and s3c2440_nand_correct_data function.

void s3c2440_nand_enable_hwecc(structmtd_info *mtd, int mode)

{

struct s3c2440_nand *nand = s3c2440_get_base_nand();

debugX(1,"s3c2440_nand_enable_hwecc(%p,%d)n", mtd, mode);

writel(readl(&nand->nfcont)| S3C2440_NFCONT_INITECC& ~S3C2440_NFCONT_MECCL,&nand->nfcont);

}

The task of this function is to initialize ECC (i.e. reset ECC) and unlock the main area ECC.

static int s3c2440_nand_calculate_ecc(struct mtd_info *mtd, constu_char *dat,

u_char *ecc_code)

{

struct s3c2440_nand *nand = s3c2440_get_base_nand();

u32 mecc0;

writel(readl(&nand->nfcont)| S3C2440_NFCONT_MECCL,&nand->nfcont);

mecc0 = readl(&nand->nfmecc0);

ecc_code[0] = mecc0 & 0xff;

ecc_code[1] = (mecc0 >> 8) &0xff;

ecc_code[2] = (mecc0 >> 16) &0xff;

ecc_code[3] =(mecc0 >> 24) & 0xff;

debugX(1,"s3c2440_nand_calculate_hwecc(%p,):0xx 0xx 0xx 0xxn",

mtd, ecc_code[0], ecc_code[1], ecc_code[2], ecc_code[3]);

return 0;

}

The function first locks the main area ECC, then reads the register NFMECC0, which stores the main area ECC generated by the hardware, and finally stores four 1-byte ECCs into the ecc_code array.

static int s3c2440_nand_correct_data(struct mtd_info *mtd, u_char*dat,

u_char *read_ecc, u_char *calc_ecc)

{

struct s3c2440_nand *nand = s3c2440_get_base_nand();

u32 meccdata0, meccdata1, estat0, err_byte_addr;

int ret = -1;

u8 repaired;

meccdata0= (read_ecc[1] << 16) | read_ecc[0];

meccdata1= (read_ecc[3] << 16) | read_ecc[2];

writel(meccdata0,&nand->nfmeccd0);

writel(meccdata1,&nand->nfmeccd1);

estat0= readl(&nand->nfestat0);

switch(estat0 & 0x3) {

case 0:

ret = 0;

break;

case 1:

err_byte_addr= (estat0 >> 7) & 0x7ff;

repaired= dat[err_byte_addr] ^ (1 << ((estat0 >> 4) & 0x7));

printf("S3C NAND: 1 bit error detected at byte%ld. "

"Correcting from 0xx to0xx...OKn",

err_byte_addr, dat[err_byte_addr],repaired);

dat[err_byte_addr]= repaired;

ret = 1;

break;

case 2:

case 3:

printf("S3C NAND: ECC uncorrectable errordetected. "

"Not correctable.n");

ret = -1;

break;

}

return ret;

}

The function first stores the ECC in the read_ecc array into registers NFMECCD0 and NFMECCD1, so that the system will automatically verify the data and put the status into register NFESTAT0, and then read the last 4 bits of the register. When it is 0, it means the verification is correct; when it is 1, it means a 1-bit error has occurred (this type of error can be corrected), and we correct it; when it is 2 and 3, it means other types of errors have occurred, which cannot be corrected.

By modifying the above content, we have implemented the hardware ECC of NandFlash.

ECC is sufficient to ensure the correctness of the read data and can correct errors in some cases, but it cannot guarantee the correctness of the written data. In order to ensure the correctness of the written data, u-boot can also define the macro CONFIG_MTD_NAND_VERIFY_WRITE in the include/configs/gq2440.h file to read the written data again and then compare it with the written data to determine the correctness of the written data. This process is called and implemented in the nand_write_page function of the drivers/mtd/nand/nand_base.c file.

6 DM9000 migration

I implemented the DM9000 part in UBOOT. Of course, I just used some ideas. I am quite unfamiliar with network cards.

First, remove the original definition of the CS8900 network card in include/configs/fl2440.h, and then define various macros related to the DM9000 network card:

  1. /*#define CONFIG_CS8900*/ /* we have a CS8900 on-board */

  2. /*#define CONFIG_CS8900_BASE 0x19000300 */

  3. /*#define CONFIG_CS8900_BUS16*/ /* the Linux driver does accesses as shorts */

  4. #define CONFIG_DRIVER_DM9000 1

  5. #define CONFIG_DM9000_BASE 0x20000300

  6. #define DM9000_IO CONFIG_DM9000_BASE

  7. #define DM9000_DATA (CONFIG_DM9000_BASE+4) /* the cmd pin is addr2*/

  8. #define CONFIG_ETHADDR a8:00:3E:26:0A:5B

  9. #define CONFIG_NETMASK 255.255.255.0

  10. #define CONFIG_IPADDR 192.168.1.11

  11. #define CONFIG_SERVERIP 192.168.1.234

  12. #define CONFIG_NET_MULTI

  13. /*

  14. #define CONFIG_NETMASK 255.255.255.0

  15. #define CONFIG_IPADDR 10.0.0.110

  16. #define CONFIG_SERVERIP 10.0.0.1

  17. */

DM9000 hardware connection schematic diagram on FL2440:

It can be seen from the figure that DM9000 is connected to NGCS4. Looking at the address space, we can know that the base address of NGCS4 is 0x20000000, so the base address of the network card is 0x20000300. They said that the 300 at the end is how the internal registers of DM9000 are defined. In reality, my network card works well at this base address, so it should be correct.

CMD is connected to ADDR2. According to the DM9000 manual, when CMD is 1, data information is sent. Therefore, the data address of DM9000 is 0x20000304. This is easy to understand.

Modify the board_eth_init function in fl2440.c:

  1. #ifdef CONFIG_CMD_NET

  2. int board_eth_init(bd_t *bis)

  3. {

  4. return dm9000_initialize(bis);

  5. }

  6. #endif

Modify drivers/net/dm9000x.c and comment out the following paragraph. I don't know the reason, so I don't care.

  1. i = 0;

  2. while (!(dm9000_phy_read(1) & 0x20)) { /* autonegation complete bit */

  3. udelay(1000);

  4. i++;

  5. if (i == 10000) {

  6. printf("could not establish linkn");

  7. return 0;

  8. }

  9. }

  10. /* see what we've got */

  11. lnk = dm9000_phy_read(17) >> 12;

  12. printf("operating at ");

  13. switch (lnk) {

  14. case 1:

  15. printf("10M half duplex ");

  16. break;

  17. case 2:

  18. printf("10M full duplex");

  19. break;

  20. case 4:

  21. printf("100M half duplex");

  22. break;

  23. case 8:

  24. printf("100M full duplex");

  25. break;

  26. default:

  27. printf("unknown: %d ", lnk);

  28. break;

  29. }

  30. printf("moden");

Comment out the contents of this function, otherwise the network card will be automatically disconnected:

  1. static void dm9000_halt(struct eth_device *netdev)

  2. {

  3. #if 0

  4. DM9000_DBG("%sn", __func__);

  5. /* RESET device */

  6. dm9000_phy_write(0, 0x8000); /* PHY RESET */

  7. DM9000_iow(DM9000_GPR, 0x01); /* Power-Down PHY */

  8. DM9000_iow(DM9000_IMR, 0x80); /* Disable all interrupt */

  9. DM9000_iow(DM9000_RCR, 0x00); /* Disable RX */

  10. #endif

  11. }

After compiling, the network card is up.

7 Modify the machine code

u-boot-2011.06boardsamsunggq2440gq2440.c

/* arch number of SMDK2410-Board */
gd->bd->bi_arch_number = 1999;

/* adress of boot parameters */
gd->bd->bi_boot_params = 0x30000100;

Finish!


[1] [2] [3]
Keywords:u-boot Reference address:u-boot-2011.06 transplant

Previous article:ALSA sound card 10_Data transmission from scratch_Study notes
Next article:Camera driver learning

Recommended ReadingLatest update time:2024-11-15 01:42

[Linux bottom layer] U-boot ksz8081 network driver debugging
Micrel is an excellent PHY chip. For more information about the chip, please refer to: ksz8081 datasheet interpretation System version: Ubuntu18.04-64 Compiler version: gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) uboot version: 2018.07-linux4sam_6.0 Board model: at91sama5d3x-xplained MCU mode
[Microcontroller]
A brief discussion on how to pass parameters from U-boot to Kernel under ARM
We may all know that U-boot will pass many parameters to the Linux Kernel, such as serial port baud rate, RAM Size, videofb, MAC Address, etc., and the Linux kernel will also read and process these parameters. The parameters are passed between the two through struct tag. U-boot saves the things to be passed to the k
[Microcontroller]
U-Boot transplanted on FL2440 (4) - supports network card DM9000 and programming yaffs file system
1 Support network card chip DM9000 Under driver, there are network card drivers DM9000x.c and DM9000x.h DM9000 is connected to BANK4, bit width 16 Set the network card base address in include/configs/TX2440.h: At line 56, change the definition of CS8900 to: #define CONFIG_DRIVER_DM9000 1 #define CONFIG_DM9000_BASE 0
[Microcontroller]
Migrate the mtdparts partition of u-boot-1.1.6
Unlike higher versions of u-boot, the mtdparts command does not have a separate file like cmd_mtdparts to implement. However, if you search for uboot, you can see the following code in cmd_jffs2.c:  1 U_BOOT_CMD(  2     mtdparts,    6,    0,    do_jffs2_mtdparts,  3     "mtdparts- define flash/nand partitionsn",  
[Microcontroller]
u-boot-2009.08 transplantation on mini2440 (I) --- Establishing mini2440 engineering environment (1)
Migration environment 1. Host environment: CentOS 5.5 under VMare, 1G memory. 2. Integrated development environment: Eclipse IDE 3. Compilation environment: arm-linux-gcc v4.4.3, arm-none-eabi-gcc v4.5.1. 4. Development board: mini2440, 2M nor flash, 128M nand flash. 5. u-boot version: u-boot-2009.08 6. References: ht
[Microcontroller]
u-boot-2009.08 transplantation on mini2440 (I) --- Establishing mini2440 engineering environment (1)
U-boot porting on mini2440-S3C2440 (2)
1. This article mainly explains the transplantation of U-boot on mini2440-S3C2440. The version used is U-boot-2009.11_tekkaman-master, download address: https://download.csdn.net/download/jinanhezhuang/20823342?spm=1001.2014.3001.5501 1. Download the official u-boot: Download address: 2. Use xftp software to upload
[Microcontroller]
U-boot porting on mini2440-S3C2440 (2)
u-boot transplantation one uboot-2015.04 Makefile analysis
This article takes smdk2410 as an example to illustrate the generation process of uboot 1.uboot generation The steps to generate uboot are as follows: make smdk2410_defconfig make all 2. uboot generation analysis: make smdk2410_defconfig The main Makefile has the following definitions: %config: scripts_basic outputm
[Microcontroller]
u-boot-2014.10 transplantation (3) Identify NOR Flash
The main thing is to add the nor flash model we use to jedec_table File : drivers/mtd/jedec_flash.c jz2440: MX29LV160DB 2M id= 0x2249, MX29LV160B macro needs to be added by yourself #define MX29LV160B      0x2249 mini2440  :SST29LV1601 (AM29LV160DB)   35sectors   id = 0x2249 // for jz2440                 {      
[Microcontroller]
Latest Microcontroller Articles
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号