To debug the efs crash issue, many information are needed. To make OEMs collect enough information at the very beginning, below list should be followed:
- Identify the baseband information, including
- Identify the MSM being used, such as Q6085, Q6270 etc.
- Identify the complete build id, such as Q6085BSNACAZ4360. If there was SBA released for your product, please add the SBA version also.
- Identify the NAND or NOR device being used as a target.
- Identify the flash information/Provide flash datasheet by case
- Maker name (Maker ID, Device ID)
- NAND type (MLC/SLC)
- Page size
- OEMs can get above information from the drivers/flash/flash_nand_vendor(toshiba/samsung).c.
* Below is a example for the nand information
* /*==========================================================*/
{
/* Samsung K9F2808U0B flash */
"SAMSUNG_K9F2808", /* Device Name */
1024, /* Block Count */
32, /* Page Count */
512, /* Page Size */
528, /* Total Page Size */
0xEC, /* Maker ID */
0x73, /* Device ID */
FLASH_NAND_8BIT, /* Device width */
FLASH_NAND | FLASH_SLC, /* Device type */
0x0, 0x0, /* dev_specfic_flag1/2 */
}, /* END Samsung K9F2808U0B flash */ - Get the faulty efs dump
- If the flash is nand flash,run the script in T32
- do tools/mjnand/nandimage.cmm-->Save file system partition
- If the flash is nor flash
- v.v fs_base_flash_device/get the fs_base_flash_device.priv.flash address(such as 0x81cf9bc)
- v.v (struct fsi_device_data*)(0x81cf9bc)/get the
- partition_start_baddr(such as 0x01000000)
- partition_limit_baddr(such as 0x01800000)
- d.save.binary efs.bin 0x01000000--0x01800000
- Ge the crash memory dump if the efs issue make fatal error. Take 80-vn752-2 as the reference. OEMs should attach the memory dump and debug elf file.
- flash configurate file qcsblhd_cfgdata.c(secure boot 1.0)/dbl_ebi2_nand.c(secure boot 2.0 nand flash)/dbl_ebi1.c(secure boot 2.0 nor flash)
No comments:
Post a Comment