The idea is to panic() when there is no memory available for normal
operation. Exception: code which can consume arbitrary amount of RAM
(example: files allocated in ramfs) must report error instead of panic().
This patch also fixes code which didn't check for NULL from malloc() etc.
Usage: malloc(), memalign() return NULL when out of RAM.
xmalloc(), xmemalign() always return non-NULL or panic().
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fix NOR CFI flash driver to work on big endian systems.
Basically this transforms the u8/u16/u32/u64 union into
a single u64 value.
Not tested on LE platform. Apply with caution.
Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Move fixing up like geometry reversal into separate functions.
The geometry reversal fixup is now performed
by altering the qry structure directly, which makes the sector init
code slightly cleaner.
based on U-Boot
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
The CFI flash driver starts at flash_init() which calls down into
flash_get_size(). This starts by calling flash_detect_cfi(). If said
function fails, flash_get_size() finishes by attempting to reset the
flash. Unfortunately, it does this with an info->portwidth set to 0x10
which filters down into flash_make_cmd() and that happily smashes the
stack by sticking info->portwidth bytes into a cfiword_t variable that
lives on the stack. On a 64bit system you probably won't notice, but
killing the last 8 bytes on a 32bit system usually leads to a corrupt
return address. Which is what happens on a Blackfin system.
based on U-Boot
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Read out the whole CFI Standard Query structure after successful cfi
identification. This allows subsequent code to access this information
directly without having to go through flash_read_uchar() and friends.
based on U-Boot
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Introduce flash_read{8,16,32,64) and flash_write{8,16,32,64} and use
them to access the flash memory. This makes it clearer when the flash
is actually being accessed; merely dereferencing a volatile pointer
looks just like any other kind of access.
based on U-Boot
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
several first banks can contain 0x7f instead of actual ID
support as done in linux
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
it will reduce the binary size of 28 bytes
and fix some issue observerd during the porting of the at91rm9200ek
when reading the device_id and manufacturor_id
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
While at it remove some unused code and an unbalanced
enable_interrupts().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This file has no useful things for others than the driver,
so move it next to the driver and remove the corresponding
include from other files.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch fixes a alignment problem which may show during this
scenario:
- 32 or 64 attached NOR flash
- flashing an image directly from network to the nor flash
The involved network driver is "smc9111.c".
The data that comes from the network stack and should be written into
the flash isn't 32 bit alligned (at least with this network driver).
This is probably due to the 48 bit wide ethernet addresses.
However the "cfi_flash.c" driver doesn't handle this situation, and
accesses the not-alligned address with a 32 bit pointer.
This patch fixes the problem by reducing the access width if an
alligment problem between source and destination is found.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
When (un)protecting a flash sector with the CFI flash driver a trace
"protect 0x..." is generated, independently of the type of operation. This is
misleading in case of an unprotect. Tell the truth when unprotecting a sector.
Signed-off-by: Matthias Kaehlcke <matthias@kaehlcke.net>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>