Hi Stefan, > Did you take a look at the CONFIG_SYS_FLASH_CFI_AMD_RESET define? I suggest > you give it a try and let me know if this helps. This does help but for the wrong reason:
#ifdef CONFIG_SYS_FLASH_CFI_AMD_RESET /* needed for STM_ID_29W320DB on UC100 */ # undef FLASH_CMD_RESET # define FLASH_CMD_RESET AMD_CMD_RESET /* use AMD-Reset instead */ #endif This just makes the reset code send two AMD_CMD_RESET. > How is this problem solved in the Linux MTD driver (referring to your first > email and the link you posted there)? The Linux way, it is addressed with this patch ============================================== http://lists.infradead.org/pipermail/linux-mtd/2008-August/022499.html Which does this: static int __xipram cfi_probe_chip(struct map_info *map, __u32 base, unsigned long *chip_map, struct cfi_private *cfi) @@ -116,11 +87,7 @@ static int __xipram cfi_probe_chip(struct map_info *map, __u32 base, } xip_disable(); >> This is the code that is similar to our cfi-flash code << - cfi_send_gen_cmd(0xF0, 0, base, map, cfi, cfi->device_type, NULL); - cfi_send_gen_cmd(0xFF, 0, base, map, cfi, cfi->device_type, NULL); - cfi_send_gen_cmd(0x98, 0x55, base, map, cfi, cfi->device_type, NULL); - - if (!qry_present(map,base,cfi)) { + if (!qry_mode_on(base, map, cfi)) { xip_enable(base, map, cfi); return 0; } The new qry_mode_on function handles several "odd" flash cases (yeah, more of these... *sob*) The quick and dirty way ==================================================== 1. Swap the order: (suggested in http://lists.infradead.org/pipermail/linux-mtd/2008-July/022252.html ) flash_write_cmd (info, 0, 0, FLASH_CMD_RESET); flash_write_cmd (info, 0, 0, AMD_CMD_RESET); 2. Follow AMD_CMD_RESET with a FLASH_CMD_RESET: (Suggested by an e-mail from Numonyx) flash_write_cmd (info, 0, 0, AMD_CMD_RESET); flash_write_cmd (info, 0, 0, FLASH_CMD_RESET); flash_write_cmd (info, 0, 0, AMD_CMD_RESET); I tested both methods and they both work on Numonyx M29W128GH (AMD cmdset) and Numonyx PC28F320J3D75 (Intel cmdset) For our local development, I'm probably going to adopt method #1 or method #2. If either method #1 or #2 have a chance to be mainlined, I can submit a patch for them with explanations. Obviously, the Linux method is probably the better solution (until another odd part comes along), the porting of the linux method seems like it will require a lot of time and testing, more than I am capable of committing right now. Thanks for your time, Regards, - Richard Retanubun _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
