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>
This stuff has been rotting in the tree for a year now. Remove it. Signed-off-by: Marek Vasut <marex@denx.de>
Check for ctrlc() in operations that take time and loop over the flash addresses. In netconsole, tstc() is expensive. Only check once in a while to not slow down the operation significantly. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Stefan Roese <sr@denx.de>
commit 54652991 Work around bug in Numonyx P33/P30 256-Mbit 65nm flash chips fixes a problem for Numonyx P33/P30 flashes for 256-Mbit, but this leads to problems for smaller versions of this chip e.g. the 32Mbit version with deviceid 0x16 on mgcoge. So move the code for this work around to an own function and check previously manufacturer id and device id to not break other flashes which don't need this work around. Signed-off-by: Holger Brunck <holger.brunck@keymile.com> Signed-off-by: Heiko Schocher <hs@denx.de> cc: Stefan Roese <sr@denx.de> cc: Philippe De Muyter <phdm@macqel.be> cc: Gerlando Falauto <gerlando.falauto@keymile.com> Signed-off-by: Stefan Roese <sr@denx.de>
collect code which protects default sectors in a function, called flash_protect_default. So boardspecific code can call it too. Signed-off-by: Heiko Schocher <hs@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
This patch simplifies the use of CONFIG_SYS_MAX_FLASH_BANKS_DETECT. By moving these optional variables and defines into the common code, board specific code is minimized. Currently only the following board use this feature: APC405, IDS8247, TQM834x And IDS8247 doesn't seem to really need this feature, since its not updating the bank number variable at all. So this patch removes the definition of CONFIG_SYS_MAX_FLASH_BANKS_DETECT from this board port. This new framework will be used by the upcoming lwmon5 update as well. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Heiko Schocher <hs@denx.de> Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
see http://www.jedec.org/download/search/jep106Z.pdf Add some second source legacy flash chips 256x8. Signed-off-by: Niklaus Giger <niklaus.giger@member.fsf.org> Signed-off-by: Stefan Roese <sr@denx.de>
On platforms with multiple NOR chips, currently only the first one can be selected using the "ubi part" command. This patch fixes this problem by using different names for the NOR "mtd devices". It also changes the name of the NOR MTD device from "cfi-mtd" to "norX" (X indexing the device numer) to better match the mtdparts defaults. Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: Andreas Huber <andreas.huber@keymile.com>
If on your board is more than one flash, you must know the size of every single flash, for example, for updating the DTS before booting Linux. So make this function flash_get_info() extern, and you can have all info about your flashes. Signed-off-by: Heiko Schocher <hs@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
include/flash.h was commented to say that the address in flash_info->start was a physical address. However, from u-boot's point of view, and looking at most flash code, it makes more sense for this to be a virtual address. So I corrected the comment to indicate that this was a virtual address. The only flash driver that was actually treating the address as physical was the mtd/cfi_flash driver. However, this code was using it inconsistently as it actually directly dereferenced the "start" element, while it used map_physmem to get a virtual address in other places. I changed this driver so that the code which initializes the info->start field calls map_physmem to get a virtual address, eliminating the need for further map_physmem calls. The code is now consistent. The *only* place a physical address should be used is when defining the flash banks list that is used to initialize the flash_info struct, usually found in the board config file. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Stefan Roese <sr@denx.de>