u-boot.git/include/flash.h, branch v2016.09-rc2 Unnamed repository; edit this file 'description' to name the repository. flash: add device ID for Microchip PIC32 internal flash. 2016-05-20T23:25:50+00:00 Purna Chandra Mandal purna.mandal@microchip.com 2016-03-18T13:06:07+00:00 30fd42cba6e7d4147e2dd4e9dbe9728efbcd24fe Microchip PIC32 has internal parallel flash (non-CFI compliant). These flash devices do not support any identifier command so no standard IDs. Added unique IDs to seperate these flash devices from others supported by U-Boot. Signed-off-by: Purna Chandra Mandal <purna.mandal@microchip.com> 
Microchip PIC32 has internal parallel flash (non-CFI compliant).
These flash devices do not support any identifier command so no
standard IDs. Added unique IDs to seperate these flash devices
from others supported by U-Boot.

Signed-off-by: Purna Chandra Mandal <purna.mandal@microchip.com>
stm32: stm32f4: move flash driver to mtd driver location 2016-03-26T22:49:28+00:00 Vikas Manocha vikas.manocha@st.com 2016-03-09T23:18:13+00:00 9ecb0c416c68d3105bc9b6607bc8601cab2ecf35 Same flash driver can be used by other stm32 families like stm32f7. Better place for this driver would be mtd driver location. Signed-off-by: Vikas Manocha <vikas.manocha@st.com> 
Same flash driver can be used by other stm32 families like stm32f7.
Better place for this driver would be mtd driver location.

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
cfi_flash: give default CONFIG_SYS_MAX_FLASH_SECT in flash.h 2015-11-30T12:00:00+00:00 Thomas Chou thomas@wytron.com.tw 2015-10-31T03:09:36+00:00 5aeeabf43c27b1bf4b3bb86e2b713dd98801df63 Give default CONFIG_SYS_MAX_FLASH_SECT in flash.h, so that the header can be included regardless of the present of flash. The value 512 is the most used. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Signed-off-by: Stefan Roese <sr@denx.de> 
Give default CONFIG_SYS_MAX_FLASH_SECT in flash.h, so that
the header can be included regardless of the present of flash.
The value 512 is the most used.

Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Signed-off-by: Stefan Roese <sr@denx.de>
dm: implement a MTD uclass 2015-11-12T00:26:58+00:00 Thomas Chou thomas@wytron.com.tw 2015-11-07T06:20:31+00:00 d85879938d3fc3557f6ff74a60f95e0975a314ce Implement a Memory Technology Device (MTD) uclass. It should include most flash drivers in the future. Though no uclass ops are defined yet, the MTD ops could be used. The NAND flash driver is based on MTD. The CFI flash and SPI flash support MTD, too. It should make sense to convert them to MTD uclass. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> 
Implement a Memory Technology Device (MTD) uclass. It should
include most flash drivers in the future. Though no uclass ops
are defined yet, the MTD ops could be used.

The NAND flash driver is based on MTD. The CFI flash and SPI
flash support MTD, too. It should make sense to convert them
to MTD uclass.

Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
ARMv7M: add STM32F1 support 2015-05-28T12:18:24+00:00 Matt Porter mporter@konsulko.com 2015-05-05T19:00:24+00:00 2d18ef2364fd3561aaffe97ee3e5e540a40a835d Add ARMv7M STM32F1 support including clocks, timer, gpio, and flash. Signed-off-by: Matt Porter <mporter@konsulko.com> 
Add ARMv7M STM32F1 support including clocks, timer, gpio, and flash.

Signed-off-by: Matt Porter <mporter@konsulko.com>
ARMv7M: Add STM32F4 support 2015-04-22T16:14:55+00:00 rev13@wp.pl rev13@wp.pl 2015-03-01T11:44:40+00:00 eaaa4f7e0e99b7bb1f5caefd96ade7c2ee891bf3 Signed-off-by: Kamil Lulko <rev13@wp.pl> Reviewed-by: Tom Rini <trini@konsulko.com> 
Signed-off-by: Kamil Lulko <rev13@wp.pl>
Reviewed-by: Tom Rini <trini@konsulko.com>
mtd: Handle 29LV800BT 2014-11-19T07:48:41+00:00 Dirk Eibach dirk.eibach@gdsys.cc 2014-11-13T18:21:13+00:00 f3c89d9228157933cf3e34d09b54ea362a6d8838 The device id makes u-boot think that this chip needs cfi_reverse_geometry(), which is not the case. Add it to jedec_flash, so it is handled properly. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc> Signed-off-by: Stefan Roese <sr@denx.de> 
The device id makes u-boot think that this chip needs
cfi_reverse_geometry(), which is not the case.
Add it to jedec_flash, so it is handled properly.

Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc>
Signed-off-by: Stefan Roese <sr@denx.de>
Coding Style cleanup: remove trailing white space 2013-10-14T20:06:53+00:00 Wolfgang Denk wd@denx.de 2013-10-07T11:07:26+00:00 3765b3e7bd0f8e46914d417f29cbcb0c72b1acf7 Signed-off-by: Wolfgang Denk <wd@denx.de> 
Signed-off-by: Wolfgang Denk <wd@denx.de>
Add GPL-2.0+ SPDX-License-Identifier to source files 2013-07-24T13:44:38+00:00 Wolfgang Denk wd@denx.de 2013-07-08T07:37:19+00:00 1a4596601fd395f3afb8f82f3f840c5e00bdd57a Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com> 
Signed-off-by: Wolfgang Denk <wd@denx.de>
[trini: Fixup common/cmd_io.c]
Signed-off-by: Tom Rini <trini@ti.com>
mtd/cfi: add support for SST 4KB sector granularity 2013-01-10T13:39:13+00:00 Angelo Dureghello sysamfw@gmail.com 2012-12-01T00:14:18+00:00 07b2c5c0e5abb8b6b996068471024410a7ef4bd4 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> 
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>