Report the usage of the Advanced Sector Protection (PPB) to the user upon 'flinfo' command. E.g: Bank # 1: CFI conformant flash (16 x 16) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2301 Advanced Sector Protection (PPB) enabled Erase timeout: 16384 ms, write timeout: 2 ms Buffer write timeout: 5 ms, buffer size: 32 bytes Sector Start Addresses: FC000000 E FC020000 E RO FC040000 E FC060000 E FC080000 E ... Signed-off-by: Stefan Roese <sr@denx.de> Cc: Anatolij Gustschin <agust@denx.de> Cc: Holger Brunck <holger.brunck@keymile.com> Tested-by: Holger Brunck <holger.brunck@keymile.com>
Not only Spansion supports the Persistent Protection Bits (PPB) locking. Other devices like the Micron JS28F512M29EWx also support this type of locking/unlocking. Detection of support is done in the same way as done for the Spansion chips - via the 0x49 CFI word. This patch enables this PPB protection mechanism for all AMD type (AMD commandset) chips. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Anatolij Gustschin <agust@denx.de> Cc: Holger Brunck <holger.brunck@keymile.com> Tested-by: Holger Brunck <holger.brunck@keymile.com>
Patch 66863b05 [cfi_flash: add support for Spansion flash PPB sector protection] introduced the PPB (Persistent Protection Bit) locking for Spansion chips. But right now the sector protection status (locked vs unlocked) is set to unlocked for all sectors upon bootup. The real sector protection status is ignored. This patch now reads the current sector protection status and uses it for these AMD/Spansion flash chips. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Anatolij Gustschin <agust@denx.de> Cc: Holger Brunck <holger.brunck@keymile.com> Tested-by: Holger Brunck <holger.brunck@keymile.com>
Consolidate manufacturer matching into the function manufact_match() and use it. Signed-off-by: Stefan Roese <sr@denx.de> Tested-by: Holger Brunck <holger.brunck@keymile.com>
Add support for SST 4KB sector granularity. Many recent SST flashes, i.e. SST39VF3201B and similar of this family are declared CFI-conformant from SST. They support CFI query, but implement 2 different sector sizes in the same memory: a 64KB sector (they call it "block", std AMD erase cmd=0x30), and a 4KB sector (they call it "sector", erase cmd=0x50). Also, CFI query on these chips, reading from address 0x2dh of cfi query struct, detects a number of secotrs for the 4KB granularity (flinfo shows it). For all other aspects, they are CFI compliant, so, as Linux do, i think it's a good idea to handle these chips in the CFI driver, with a fixup to allow 4KB granularity, as should be expected, instead of 64KB. Signed-off-by: Angelo Dureghello <sysamfw@gmail.com> Signed-off-by: Stefan Rose <sr@denx.de>
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
This required manual merging drivers/mtd/nand/Makefile and adding am335x_evm support for CONFIG_SPL_NAND_DRIVERS
IFC_FIR_OP_CMD0 issues command for execution without checking flash readiness. It may cause problem if flash is not ready. Instead use IFC_FIR_OP_CW0 which Wait for tWB time and poll R/B to return high or time-out, before issuing command. NAND_CMD_READID command implemention does not fulfill above requirement. So update its programming. Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: Hemant Nautiyal <hemant.nautiyal@freescale.com>
It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so we end up with various failures or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state already before sending commands to NAND. This behaviour was observed in barebox and kernel, so I assume it affects U-Boot as well. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Marek Vasut <marex@denx.de>