* [ECOS] Flash infrastructure rework
@ 2004-07-16 13:39 Andrew Lunn
2004-07-19 14:18 ` Ian Campbell
` (3 more replies)
0 siblings, 4 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-07-16 13:39 UTC (permalink / raw)
To: eCos Disuss
[-- Attachment #1: Type: text/plain, Size: 9493 bytes --]
Hi Folks
Ascom has recently required that Redboot run on a target board which
can be manufactured with two different FLASH devices which are pin
compatible and with two banks of flash in disjoint locations. We also
needed to support two jffs2 file systems simultaneously so allowing
fallback if one was corrupt. The client also wants one image to run on
both boards. The current flash infrastructure cannot support this. Due
to time pressures we have used Ian Campbells patches to get something
going quickly.
However in the background i took a step back and overhauled the whole
flash infrastructure in what i hope is a clean and consistent API with
all the features required:
Multiple device drivers at the same time
Multiple instantiations of the same driver
Probing to detect what is actually on the board
Support for boot block devices which have different size blocks
Thread safe when used with the kernel
Does not pollute the name space
Optional backward compatible with old drivers
Optional backward compatible with old API
Able to support multiple JFFS2 filesystems
Redboot to be able to access multiple devices
Documentation!
Attached are the change. There are two .epk's. One is the new io/flash
code which uses v2 instead of current so you can have it in the
repository at the same time as the current code. The second is a flash
driver which uses the new API for the synthetic target. This installs
parallel the current synth flash driver which allows testing of legacy
and new drivers in the same system. There is also a patch to the rest
of eCos for redboot and jffs2.
Some screen shots....
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 14:27:08, Jul 15 2004
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
RAM: 0x02000000-0x02800000, [0x02006fd0-0x027e1000] available
FLASH: 0x40000000 - 0x400fffff 8 x 0x2000 blocks 15 x 0x10000 blocks
FLASH: 0x40100000 - 0x401fffff 16 x 0x10000 blocks
Here you can see two flash devices, the first one with boot blocks.
In this setup the first device is the new synthetic driver and the
second one is the legacy driver.
RedBoot> fis create -b 0x02000000 -l 0x10000 -f 0x40100000 junk
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0x40000000 0x40000000 0x00020000 0x00000000
FIS directory 0x400EFFFF 0x400EFFFF 0x0000F000 0x00000000
RedBoot config 0x400FEFFF 0x400FEFFF 0x00001000 0x00000000
junk 0x40100000 0x40100000 0x00010000 0xFFFFFFFF
RedBoot>
This creates an entry in the second flash device.
There are still some limitations. The FIS directory and RedBoot config
have to be in the lower device. Also they cannot yet make use of the
boot blocks, but that should be easy to add.
The fileio1 test in the jffs2 package has been extended. If the flash
block io layer has been configured for two devices the second one is
also mounted:
<INFO>: mounting second JFFS2 filesystem on /mnt
<INFO>: reading directory /
<INFO>: entry . [mode 016f0001 ino 00000001 nlink 1 size 0]
<INFO>: entry .. [mode 016f0001 ino 00000001 nlink 1 size 0]
<INFO>: entry etc [mode 016f0001 ino 00000002 nlink 1 size 0]
<INFO>: entry dev<FAIL>: stat() returned -1 No such entity
<INFO>: entry mnt [mode 016f0001 ino 00000001 nlink 1 size 0]
<INFO>: entry var [mode 016f0001 ino 00000008 nlink 1 size 0]
<INFO>: entry tmp [mode 016f0001 ino 00000007 nlink 1 size 0]
<INFO>: entry jffs2.img [mode 004b0008 ino 00000009 nlink 1 size 2013]
<INFO>: reading directory /mnt
<INFO>: entry . [mode 016f0001 ino 00000001 nlink 1 size 0]
<INFO>: entry .. [mode 016f0001 ino 00000001 nlink 1 size 0]
<INFO>: entry etc [mode 016f0001 ino 00000002 nlink 1 size 0]
<INFO>: entry dev [mode 016f0001 ino 00000005 nlink 1 size 0]
<INFO>: entry mnt [mode 016f0001 ino 00000006 nlink 1 size 0]
<INFO>: entry var [mode 016f0001 ino 00000008 nlink 1 size 0]
<INFO>: entry tmp [mode 016f0001 ino 00000007 nlink 1 size 0]
<INFO>: entry jffs2.img [mode 004b0008 ino 00000009 nlink 1 size 2013]
<INFO>: umount /mnt
<INFO>: umount /
In this case the two filesystems are identical so its not the best of
tests. I also need to look into the /dev failure, but i don't think
that is related to the flashiodev code.
There is documentaion in SGML format which describes both the new
application and device API. Note that it might not be 100% correct. I
wrote the documentation first to get my ideas sorted out and then did
the implementation. There was some minor changes along the way which
might not of made it back into the documentation.
The new API is:
typedef int cyg_flash_printf(const char *fmt, ...);
__externC int cyg_flash_init( cyg_flash_printf *pf );
__externC int cyg_flash_get_info(cyg_uint32 devno,
cyg_flash_info_t * info);
__externC int cyg_flash_get_info_addr(cyg_flashaddr_t flash_base,
cyg_flash_info_t * info);
__externC int cyg_flash_verify_addr(const cyg_flashaddr_t address);
__externC bool cyg_flash_code_overlaps(const cyg_flashaddr_t start,
const cyg_flashaddr_t end);
__externC int cyg_flash_get_block_info(size_t *block_size,
cyg_uint32 *blocks);
__externC int cyg_flash_get_limits(cyg_flashaddr_t *start,
cyg_flashaddr_t *end);
__externC size_t cyg_flash_block_size(const cyg_flashaddr_t flash_base);
__externC int cyg_flash_read(cyg_flashaddr_t flash_base,
const void *ram_base,
const size_t len,
cyg_flashaddr_t *err_address);
__externC int cyg_flash_erase(const cyg_flashaddr_t flash_base,
const size_t len,
cyg_flashaddr_t *err_address);
__externC int cyg_flash_program(const cyg_flashaddr_t flash_base,
void *ram_base,
const size_t len,
cyg_flashaddr_t *err_address);
__externC int cyg_flash_lock(const cyg_flashaddr_t flash_base,
const size_t len,
cyg_flashaddr_t *err_address);
__externC int cyg_flash_unlock(const cyg_flashaddr_t flash_base,
const size_t len,
cyg_flashaddr_t *err_address);
__externC const char *cyg_flash_errmsg(const int err);
#ifdef CYGPKG_KERNEL
__externC int cyg_flash_mutex_lock(const cyg_flashaddr_t from,
const size_t len);
__externC int cyg_flash_mutex_unlock(const cyg_flashaddr_t from,
#endif
and the device API is
// Structure of pointers to functions in the device driver
struct cyg_flash_dev_funs {
int (*flash_init) (struct cyg_flash_dev *dev);
size_t (*flash_query) (struct cyg_flash_dev *dev, void * data,
const size_t len);
int (*flash_erase_block) (struct cyg_flash_dev *dev,
const cyg_flashaddr_t block_base);
int (*flash_program) (struct cyg_flash_dev *dev,
cyg_flashaddr_t base,
const void* data, const size_t len);
int (*flash_read) (struct cyg_flash_dev *dev,
const cyg_flashaddr_t base,
void* data, const size_t len);
int (*flash_hwr_map_error) (struct cyg_flash_dev *dev, int err);
int (*flash_block_lock) (struct cyg_flash_dev *dev,
const cyg_flashaddr_t block_base);
int (*flash_block_unlock) (struct cyg_flash_dev *dev,
const cyg_flashaddr_t block_base);
};
// Structure each device places in the HAL table
struct cyg_flash_dev {
struct cyg_flash_dev_funs *funs; // Function pointers
cyg_flashaddr_t start; // First address
cyg_flashaddr_t end; // Last address
cyg_uint32 num_block_infos; // Number of entries
cyg_block_info_t *block_info; // Info about one block size
void *priv; // Devices private data
void *config; // Configuration info
// The following are only written to by the FLASH IO layer.
cyg_flash_printf *pf; // Pointer to diagnostic printf
bool init; // Device has been initialised
#ifdef CYGPKG_KERNEL
cyg_mutex_t mutex; // Mutex for thread safeness
#endif
struct cyg_flash_dev *next; // Pointer to next device
} CYG_HAL_TABLE_TYPE;
See the documentation for explanations of each function.
It needs some more device drivers. I plan to modify both the SST and
the Strata drivers to use the new API, but that work will not start
for another two weeks.
What i would like now is some feedback. Are there any missing
features? Does the APIs make sense. Reading the code do you see
obvious problems?
Im on Holiday for the next two weeks so it would be nice to come back
to a few email of suggestions, improvements and bug fixes.
Thanks
Andrew
[-- Attachment #2: flashv2.epk --]
[-- Type: application/octet-stream, Size: 24080 bytes --]
[-- Attachment #3: synthflashv2.epk --]
[-- Type: application/octet-stream, Size: 7306 bytes --]
[-- Attachment #4: flashv2.diff --]
[-- Type: text/plain, Size: 40339 bytes --]
? devs/flash/synth/current/tests/flash2.c
Index: devs/flash/synth/current/cdl/flash_synth.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/devs/flash/synth/current/cdl/flash_synth.cdl,v
retrieving revision 1.3
diff -u -r1.3 flash_synth.cdl
--- devs/flash/synth/current/cdl/flash_synth.cdl 23 May 2002 23:01:05 -0000 1.3
+++ devs/flash/synth/current/cdl/flash_synth.cdl 16 Jul 2004 11:21:02 -0000
@@ -56,7 +56,7 @@
requires CYGINT_ISO_ERRNO_CODES
implements CYGHWR_IO_FLASH_DEVICE
-
+
include_dir .
include_files ; # none _exported_ whatsoever
description "FLASH memory device support for Synthetic target"
@@ -121,7 +121,7 @@
display "Synth flash tests"
flavor data
no_define
- calculated { "tests/flash1.c"}
+ calculated { "tests/flash1.c tests/flash2.c"}
description "
This option specifies the set of tests for the synth flash package."
}
Index: devs/flash/synth/current/src/synth.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/devs/flash/synth/current/src/synth.c,v
retrieving revision 1.3
diff -u -r1.3 synth.c
--- devs/flash/synth/current/src/synth.c 23 May 2002 23:01:06 -0000 1.3
+++ devs/flash/synth/current/src/synth.c 16 Jul 2004 11:21:02 -0000
@@ -149,7 +149,7 @@
return FLASH_ERR_HWR;
}
flash_info.start = cyg_dev_flash_synth_base;
- flash_info.end = (void *)(((char *)cyg_dev_flash_synth_base) +
+ flash_info.end = (void *)(((char *)cyg_dev_flash_synth_base) -1 +
(CYGNUM_FLASH_SYNTH_BLOCKSIZE * CYGNUM_FLASH_SYNTH_NUMBLOCKS));
return FLASH_ERR_OK;
Index: devs/flash/synth/current/tests/flash1.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/devs/flash/synth/current/tests/flash1.c,v
retrieving revision 1.4
diff -u -r1.4 flash1.c
--- devs/flash/synth/current/tests/flash1.c 24 Nov 2003 11:21:28 -0000 1.4
+++ devs/flash/synth/current/tests/flash1.c 16 Jul 2004 11:21:03 -0000
@@ -1,59 +1,59 @@
-/* Hay, the copyright is usefull for something! */
+/* Hey, the copyright is usefull for something! */
-static char copyright[] = "
-//==========================================================================
-//
-// flash1.c
-//
-// Test flash operations for the synth target synth flash driver
-//
-//==========================================================================
-//####ECOSGPLCOPYRIGHTBEGIN####
-// -------------------------------------------
-// This file is part of eCos, the Embedded Configurable Operating System.
-// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
-//
-// eCos is free software; you can redistribute it and/or modify it under
-// the terms of the GNU General Public License as published by the Free
-// Software Foundation; either version 2 or (at your option) any later version.
-//
-// eCos is distributed in the hope that it will be useful, but WITHOUT ANY
-// WARRANTY; without even the implied warranty of MERCHANTABILITY or
-// FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
-// for more details.
-//
-// You should have received a copy of the GNU General Public License along
-// with eCos; if not, write to the Free Software Foundation, Inc.,
-// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
-//
-// As a special exception, if other files instantiate templates or use macros
-// or inline functions from this file, or you compile this file and link it
-// with other works to produce a work based on this file, this file does not
-// by itself cause the resulting work to be covered by the GNU General Public
-// License. However the source code for this file must still be made available
-// in accordance with section (3) of the GNU General Public License.
-//
-// This exception does not invalidate any other reasons why a work based on
-// this file might be covered by the GNU General Public License.
-//
-// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
-// at http://sources.redhat.com/ecos/ecos-license/
-// -------------------------------------------
-//####ECOSGPLCOPYRIGHTEND####
-//==========================================================================
-//#####DESCRIPTIONBEGIN####
-//
-// Author(s): andrew.lunn@ascom.ch
-// Contributors: andrew.lunn
-// Date: 2000-10-31
-// Purpose: Test a flash driver
-// Description: Try out a number of flash operations and make sure
-// what is in the flash is what we expeect.
-//
-//####DESCRIPTIONEND####
-//
-//==========================================================================
-";
+static char copyright[] =
+"//=========================================================================="
+"//"
+"// flash1.c"
+"//"
+"// Test flash operations for the synth target synth flash driver"
+"//"
+"//=========================================================================="
+"//####ECOSGPLCOPYRIGHTBEGIN####"
+"// -------------------------------------------"
+"// This file is part of eCos, the Embedded Configurable Operating System."
+"// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc."
+"//"
+"// eCos is free software; you can redistribute it and/or modify it under"
+"// the terms of the GNU General Public License as published by the Free"
+"// Software Foundation; either version 2 or (at your option) any later version."
+"//"
+"// eCos is distributed in the hope that it will be useful, but WITHOUT ANY"
+"// WARRANTY; without even the implied warranty of MERCHANTABILITY or"
+"// FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License"
+"// for more details."
+"//"
+"// You should have received a copy of the GNU General Public License along"
+"// with eCos; if not, write to the Free Software Foundation, Inc.,"
+"// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA."
+"//"
+"// As a special exception, if other files instantiate templates or use macros"
+"// or inline functions from this file, or you compile this file and link it"
+"// with other works to produce a work based on this file, this file does not"
+"// by itself cause the resulting work to be covered by the GNU General Public"
+"// License. However the source code for this file must still be made available"
+"// in accordance with section (3) of the GNU General Public License."
+"//"
+"// This exception does not invalidate any other reasons why a work based on"
+"// this file might be covered by the GNU General Public License."
+"//"
+"// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc."
+"// at http://sources.redhat.com/ecos/ecos-license/"
+"// -------------------------------------------"
+"//####ECOSGPLCOPYRIGHTEND####"
+"//=========================================================================="
+"//#####DESCRIPTIONBEGIN####"
+"//"
+"// Author(s): andrew.lunn@ascom.ch"
+"// Contributors: andrew.lunn"
+"// Date: 2000-10-31"
+"// Purpose: Test a flash driver"
+"// Description: Try out a number of flash operations and make sure"
+"// what is in the flash is what we expeect."
+"// "
+"//####DESCRIPTIONEND####"
+"//"
+"//=========================================================================="
+;
#include <cyg/io/flash.h>
#include <cyg/infra/testcase.h>
@@ -64,6 +64,9 @@
#ifndef CYGINT_ISO_STRING_STRFUNCS
# define NA_MSG "Need string functions for test"
#endif
+#ifndef CYGSEM_IO_FLASH_LEGACY_API
+# define NA_MSG "Need legacy IO FLASH API for test"
+#endif
#ifdef NA_MSG
void cyg_user_start(void)
Index: redboot/current/src/flash.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v
retrieving revision 1.67
diff -u -r1.67 flash.c
--- redboot/current/src/flash.c 25 Jun 2004 15:49:43 -0000 1.67
+++ redboot/current/src/flash.c 16 Jul 2004 11:21:05 -0000
@@ -163,11 +163,12 @@
);
// Local data used by these routines
-void *flash_start, *flash_end;
-int flash_block_size, flash_num_blocks;
+cyg_flashaddr_t flash_start, flash_end;
+size_t flash_block_size;
+cyg_uint32 flash_num_blocks;
#ifdef CYGOPT_REDBOOT_FIS
void *fis_work_block;
-void *fis_addr;
+cyg_flashaddr_t fis_addr;
int fisdir_size; // Size of FIS directory.
#endif
#ifdef CYGSEM_REDBOOT_FLASH_CONFIG
@@ -186,8 +187,19 @@
static void
_show_invalid_flash_address(CYG_ADDRESS flash_addr, int stat)
{
- diag_printf("Invalid FLASH address %p: %s\n", (void *)flash_addr, flash_errmsg(stat));
- diag_printf(" valid range is %p-%p\n", (void *)flash_start, (void *)flash_end);
+ cyg_uint32 i=0;
+ cyg_flash_info_t info;
+ int ret;
+
+ diag_printf("Invalid FLASH address %p: %s\n", (void *)flash_addr,
+ cyg_flash_errmsg(stat));
+ do {
+ ret = cyg_flash_get_info(i, &info);
+ if (ret == CYG_FLASH_ERR_OK) {
+ diag_printf(" valid range is %p - %p\n", info.start, info.end);
+ }
+ i++;
+ } while (ret != CYG_FLASH_ERR_INVALID);
}
#ifdef CYGOPT_REDBOOT_FIS
@@ -196,9 +208,9 @@
{
int i;
struct fis_image_desc *img;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
- flash_read(fis_addr, fis_work_block, fisdir_size, (void **)&err_addr);
+ cyg_flash_read(fis_addr, fis_work_block, fisdir_size, &err_addr);
img = (struct fis_image_desc *)fis_work_block;
for (i = 0; i < fisdir_size/sizeof(*img); i++, img++) {
if ((img->name[0] != (unsigned char)0xFF) &&
@@ -214,27 +226,27 @@
fis_update_directory(void)
{
int stat;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
#ifdef CYGSEM_REDBOOT_FLASH_COMBINED_FIS_AND_CONFIG
memcpy((char *)fis_work_block+fisdir_size, config, cfg_size);
#endif
#ifdef CYGSEM_REDBOOT_FLASH_LOCK_SPECIAL
// Ensure [quietly] that the directory is unlocked before trying to update
- flash_unlock((void *)fis_addr, flash_block_size, (void **)&err_addr);
+ cyg_flash_unlock((void *)fis_addr, flash_block_size, &err_addr);
#endif
- if ((stat = flash_erase(fis_addr, flash_block_size, (void **)&err_addr)) != 0) {
- diag_printf("Error erasing FIS directory at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_erase(fis_addr, flash_block_size, &err_addr)) != 0) {
+ diag_printf("Error erasing FIS directory at %p: %s\n", err_addr, cyg_flash_errmsg(stat));
} else {
- if ((stat = flash_program(fis_addr, fis_work_block, flash_block_size,
- (void **)&err_addr)) != 0) {
+ if ((stat = cyg_flash_program(fis_addr, fis_work_block, flash_block_size,
+ &err_addr)) != 0) {
diag_printf("Error writing FIS directory at %p: %s\n",
- err_addr, flash_errmsg(stat));
+ err_addr, cyg_flash_errmsg(stat));
}
}
#ifdef CYGSEM_REDBOOT_FLASH_LOCK_SPECIAL
// Ensure [quietly] that the directory is locked after the update
- flash_lock((void *)fis_addr, flash_block_size, (void **)&err_addr);
+ cyg_flash_lock((void *)fis_addr, flash_block_size, &err_addr);
#endif
}
@@ -243,7 +255,7 @@
{
int stat;
struct fis_image_desc *img;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
bool full_init = false;
struct option_info opts[1];
CYG_ADDRESS redboot_flash_start;
@@ -377,10 +389,10 @@
erase_size = (CYG_ADDRESS)flash_start + CYGBLD_REDBOOT_FLASH_BOOT_OFFSET;
if ( erase_size > erase_start ) {
erase_size -= erase_start;
- if ((stat = flash_erase((void *)erase_start, erase_size,
- (void **)&err_addr)) != 0) {
+ if ((stat = cyg_flash_erase((void *)erase_start, erase_size,
+ &err_addr)) != 0) {
diag_printf(" initialization failed at %p: %s\n",
- err_addr, flash_errmsg(stat));
+ err_addr, cyg_flash_errmsg(stat));
}
}
#endif
@@ -396,10 +408,10 @@
} else {
erase_size = (CYG_ADDRESS)fis_addr - erase_start; // the gap between HWM and fis data
}
- if ((stat = flash_erase((void *)erase_start, erase_size,
- (void **)&err_addr)) != 0) {
+ if ((stat = cyg_flash_erase((void *)erase_start, erase_size,
+ &err_addr)) != 0) {
diag_printf(" initialization failed %p: %s\n",
- err_addr, flash_errmsg(stat));
+ err_addr, cyg_flash_errmsg(stat));
}
erase_start += (erase_size + flash_block_size);
if (fis_addr > cfg_base) {
@@ -407,27 +419,26 @@
} else {
erase_size = (CYG_ADDRESS)cfg_base - erase_start; // the gap between fis and config data
}
- if ((stat = flash_erase((void *)erase_start, erase_size,
- (void **)&err_addr)) != 0) {
+ if ((stat = cyg_flash_erase((void *)erase_start, erase_size,
+ &err_addr)) != 0) {
diag_printf(" initialization failed %p: %s\n",
- err_addr, flash_errmsg(stat));
+ err_addr, cyg_flash_errmsg(stat));
}
erase_start += (erase_size + flash_block_size);
#else // !CYGSEM_REDBOOT_FLASH_CONFIG
erase_size = (CYG_ADDRESS)fis_addr - erase_start; // the gap between HWM and fis data
- if ((stat = flash_erase((void *)erase_start, erase_size,
- (void **)&err_addr)) != 0) {
+ if ((stat = cyg_flash_erase(erase_start, erase_size,&err_addr)) != 0) {
diag_printf(" initialization failed %p: %s\n",
- err_addr, flash_errmsg(stat));
+ err_addr, cyg_flash_errmsg(stat));
}
erase_start += (erase_size + flash_block_size);
#endif
// Lastly, anything at the end
erase_size = ((CYG_ADDRESS)flash_end - erase_start) + 1;
- if ((stat = flash_erase((void *)erase_start, erase_size,
- (void **)&err_addr)) != 0) {
+ if ((stat = cyg_flash_erase(erase_start, erase_size,
+ &err_addr)) != 0) {
diag_printf(" initialization failed at %p: %s\n",
- err_addr, flash_errmsg(stat));
+ err_addr, cyg_flash_errmsg(stat));
}
#ifndef CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS
// In this case, 'fis free' works by scanning for erased blocks. Since the
@@ -448,7 +459,7 @@
bool show_cksums = false;
bool show_datalen = false;
struct option_info opts[2];
- void *err_addr;
+ cyg_flashaddr_t err_addr;
unsigned long last_addr, lowest_addr;
bool image_found;
@@ -471,7 +482,7 @@
if (!scan_opts(argc, argv, 2, opts, i, 0, 0, "")) {
return;
}
- flash_read(fis_addr, fis_work_block, fisdir_size, (void **)&err_addr);
+ cyg_flash_read(fis_addr, fis_work_block, fisdir_size, &err_addr);
// Let diag_printf do the formatting in both cases, rather than counting
// cols by hand....
diag_printf("%-16s %-10s %-10s %-10s %-s\n",
@@ -520,20 +531,37 @@
static int
find_free(struct free_chunk *chunks)
{
- CYG_ADDRESS *fis_ptr, *fis_end;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
+ cyg_flash_info_t info;
struct fis_image_desc *img;
- int i, idx;
- int num_chunks = 1;
-
- // Do not search the area reserved for pre-RedBoot systems:
- fis_ptr = (CYG_ADDRESS *)((CYG_ADDRESS)flash_start +
- CYGNUM_REDBOOT_FLASH_RESERVED_BASE +
- CYGBLD_REDBOOT_MIN_IMAGE_SIZE);
- fis_end = (CYG_ADDRESS *)flash_end;
- chunks[num_chunks-1].start = (CYG_ADDRESS)fis_ptr;
- chunks[num_chunks-1].end = (CYG_ADDRESS)fis_end;
- flash_read(fis_addr, fis_work_block, fisdir_size, (void **)&err_addr);
+ int i=0, idx;
+ int num_chunks = 0;
+ int ret;
+
+ do {
+ ret = cyg_flash_get_info(i, &info);
+ if (ret == CYG_FLASH_ERR_OK) {
+ if (i == 0 ) {
+ // Do not search the area reserved for pre-RedBoot systems:
+ chunks[num_chunks].start = (info.start +
+ CYGNUM_REDBOOT_FLASH_RESERVED_BASE +
+ CYGBLD_REDBOOT_MIN_IMAGE_SIZE);
+ chunks[num_chunks].end = info.end;
+ num_chunks++;
+ } else { // Contiguous flash? If so collapse the chunks together.
+ if (chunks[num_chunks-1].end == (info.start -1)) {
+ chunks[num_chunks-1].end = info.end;
+ } else {
+ chunks[num_chunks].start = info.start;
+ chunks[num_chunks].end = info.end;
+ num_chunks++;
+ }
+ }
+ }
+ i++;
+ } while (ret != CYG_FLASH_ERR_INVALID);
+
+ cyg_flash_read(fis_addr, fis_work_block, fisdir_size, &err_addr);
img = (struct fis_image_desc *) fis_work_block;
for (i = 0; i < fisdir_size/sizeof(*img); i++, img++) {
if (img->name[0] != (unsigned char)0xFF) {
@@ -555,13 +583,11 @@
chunks[idx].end = img->flash_base;
} else {
// Split chunk into two parts
- if ((img->flash_base+img->size) < (CYG_ADDRESS)fis_end) {
- chunks[idx+1].start = img->flash_base + img->size;
- chunks[idx+1].end = chunks[idx].end;
- if (++num_chunks == CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS) {
- diag_printf("Warning: too many free chunks\n");
- return num_chunks;
- }
+ chunks[idx+1].start = img->flash_base + img->size;
+ chunks[idx+1].end = chunks[idx].end;
+ if (++num_chunks == CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS) {
+ diag_printf("Warning: too many free chunks\n");
+ return num_chunks;
}
chunks[idx].end = img->flash_base;
}
@@ -700,12 +726,13 @@
bool length_set = false;
bool img_size_set = false;
bool no_copy = false;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
struct fis_image_desc *img = NULL;
bool defaults_assumed;
struct option_info opts[7];
bool prog_ok = true;
-
+ size_t block_size;
+
init_opts(&opts[0], 'b', true, OPTION_ARG_TYPE_NUM,
(void *)&mem_addr, (bool *)&mem_addr_set, "memory base address");
init_opts(&opts[1], 'r', true, OPTION_ARG_TYPE_NUM,
@@ -726,7 +753,7 @@
return;
}
- flash_read(fis_addr, fis_work_block, fisdir_size, (void **)&err_addr);
+ cyg_flash_read(fis_addr, fis_work_block, fisdir_size, &err_addr);
defaults_assumed = false;
if (name) {
// Search existing files to acquire defaults for params not specified:
@@ -782,24 +809,6 @@
}
// 'length' is size of FLASH image, 'img_size' is actual data size
// Round up length to FLASH block size
-#ifndef CYGPKG_HAL_MIPS // FIXME: compiler is b0rken
- length = ((length + flash_block_size - 1) / flash_block_size) * flash_block_size;
- if (length < img_size) {
- diag_printf("Invalid FLASH image size/length combination\n");
- return;
- }
-#endif
- if (flash_addr_set &&
- ((stat = flash_verify_addr((void *)flash_addr)) ||
- (stat = flash_verify_addr((void *)(flash_addr+length-1))))) {
- _show_invalid_flash_address(flash_addr, stat);
- return;
- }
- if (flash_addr_set && ((flash_addr & (flash_block_size-1)) != 0)) {
- diag_printf("Invalid FLASH address: %p\n", (void *)flash_addr);
- diag_printf(" must be 0x%x aligned\n", flash_block_size);
- return;
- }
if (strlen(name) >= sizeof(img->name)) {
diag_printf("Name is too long, must be less than %d chars\n", (int)sizeof(img->name));
return;
@@ -814,7 +823,30 @@
diag_printf("Can't locate %lx(%ld) bytes free in FLASH\n", length, length);
return;
}
+ flash_addr_set = true;
}
+ if (flash_addr_set) {
+ block_size = cyg_flash_block_size(flash_addr + length);
+#ifndef CYGPKG_HAL_MIPS // FIXME: compiler is b0rken
+ length = ((length + block_size - 1) / block_size) * block_size;
+ if (length < img_size) {
+ diag_printf("Invalid FLASH image size/length combination\n");
+ return;
+ }
+#endif
+ if ((stat = cyg_flash_verify_addr(flash_addr)) ||
+ (stat = cyg_flash_verify_addr((flash_addr+length-1)))) {
+ _show_invalid_flash_address(flash_addr, stat);
+ return;
+ }
+ block_size = cyg_flash_block_size(flash_addr);
+ if ((flash_addr & (flash_block_size-1)) != 0) {
+ diag_printf("Invalid FLASH address: %p\n", (void *)flash_addr);
+ diag_printf(" must be 0x%x aligned\n", flash_block_size);
+ return;
+ }
+ }
+
// First, see if the image by this name has agreable properties
if (img) {
if (flash_addr_set && (img->flash_base != flash_addr)) {
@@ -863,7 +895,7 @@
}
}
#endif
- // If not image by that name, try and find an empty slot
+ // If no image by that name, try and find an empty slot
img = (struct fis_image_desc *)fis_work_block;
for (i = 0; i < fisdir_size/sizeof(*img); i++, img++) {
if (img->name[0] == (unsigned char)0xFF) {
@@ -873,21 +905,23 @@
}
if (!no_copy) {
// Safety check - make sure the address range is not within the code we're running
- if (flash_code_overlaps((void *)flash_addr, (void *)(flash_addr+img_size-1))) {
+ if (cyg_flash_code_overlaps(flash_addr, (flash_addr+img_size-1))) {
diag_printf("Can't program this region - contains code in use!\n");
return;
}
if (prog_ok) {
// Erase area to be programmed
- if ((stat = flash_erase((void *)flash_addr, length, (void **)&err_addr)) != 0) {
- diag_printf("Can't erase region at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_erase(flash_addr, length, &err_addr)) != 0) {
+ diag_printf("Can't erase region at %p: %s\n", err_addr, cyg_flash_errmsg(stat));
prog_ok = false;
}
}
if (prog_ok) {
// Now program it
- if ((stat = flash_program((void *)flash_addr, (void *)mem_addr, img_size, (void **)&err_addr)) != 0) {
- diag_printf("Can't program region at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_program(flash_addr, (void *)mem_addr, img_size,
+ &err_addr)) != 0) {
+ diag_printf("Can't program region at %p: %s\n", err_addr,
+ cyg_flash_errmsg(stat));
prog_ok = false;
}
}
@@ -919,7 +953,7 @@
{
char *name;
int num_reserved, i, stat;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
struct fis_image_desc *img;
if (!scan_opts(argc, argv, 2, 0, 0, (void *)&name, OPTION_ARG_TYPE_STR, "image name"))
@@ -967,8 +1001,8 @@
return;
}
// Erase Data blocks (free space)
- if ((stat = flash_erase((void *)img->flash_base, img->size, (void **)&err_addr)) != 0) {
- diag_printf("Error erasing at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_erase(img->flash_base, img->size, &err_addr)) != 0) {
+ diag_printf("Error erasing at %p: %s\n", err_addr, cyg_flash_errmsg(stat));
} else {
img->name[0] = (unsigned char)0xFF;
fis_update_directory();
@@ -991,7 +1025,7 @@
#if defined(CYGPRI_REDBOOT_ZLIB_FLASH) || defined(CYGSEM_REDBOOT_FIS_CRC_CHECK)
bool decompress = false;
#endif
- void *err_addr;
+ cyg_flashaddr_t err_addr;
init_opts(&opts[0], 'b', true, OPTION_ARG_TYPE_NUM,
(void *)&mem_addr, (bool *)&mem_addr_set, "memory [load] base address");
@@ -1055,11 +1089,12 @@
load_address_end = (unsigned long)p->out_buf;
// Reload fis directory
- flash_read(fis_addr, fis_work_block, fisdir_size, (void **)&err_addr);
+ cyg_flash_read(fis_addr, fis_work_block, fisdir_size, &err_addr);
} else // dangling block
#endif
{
- flash_read((void *)img->flash_base, (void *)mem_addr, img->data_length, (void **)&err_addr);
+ cyg_flash_read(img->flash_base, (void *)mem_addr, img->data_length,
+ &err_addr);
// Set load address/top
load_address = mem_addr;
@@ -1093,10 +1128,11 @@
bool mem_addr_set = false;
bool flash_addr_set = false;
bool length_set = false;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
struct option_info opts[3];
bool prog_ok;
-
+ size_t block_size;
+
init_opts(&opts[0], 'b', true, OPTION_ARG_TYPE_NUM,
(void *)&mem_addr, (bool *)&mem_addr_set, "memory base address");
init_opts(&opts[1], 'f', true, OPTION_ARG_TYPE_NUM,
@@ -1115,18 +1151,20 @@
}
// Round up length to FLASH block size
+ block_size = cyg_flash_block_size(flash_addr + length);
#ifndef CYGPKG_HAL_MIPS // FIXME: compiler is b0rken
- length = ((length + flash_block_size - 1) / flash_block_size) * flash_block_size;
+ length = ((length + block_size - 1) / block_size) * block_size;
#endif
- if (flash_addr_set &&
- ((stat = flash_verify_addr((void *)flash_addr)) ||
- (stat = flash_verify_addr((void *)(flash_addr+length-1))))) {
+ if ((stat = cyg_flash_verify_addr(flash_addr)) ||
+ (stat = cyg_flash_verify_addr((flash_addr+length-1)))) {
_show_invalid_flash_address(flash_addr, stat);
return;
}
- if (flash_addr_set && flash_addr & (flash_block_size-1)) {
+
+ block_size = cyg_flash_block_size(flash_addr);
+ if (flash_addr & (block_size-1)) {
diag_printf("Invalid FLASH address: %p\n", (void *)flash_addr);
- diag_printf(" must be 0x%x aligned\n", flash_block_size);
+ diag_printf(" must be 0x%x aligned\n", block_size);
return;
}
if ((mem_addr < (CYG_ADDRESS)ram_start) ||
@@ -1135,7 +1173,7 @@
diag_printf(" valid range is %p-%p\n", (void *)ram_start, (void *)ram_end);
}
// Safety check - make sure the address range is not within the code we're running
- if (flash_code_overlaps((void *)flash_addr, (void *)(flash_addr+length-1))) {
+ if (cyg_flash_code_overlaps(flash_addr, (flash_addr+length-1))) {
diag_printf("Can't program this region - contains code in use!\n");
return;
}
@@ -1147,15 +1185,18 @@
prog_ok = true;
if (prog_ok) {
// Erase area to be programmed
- if ((stat = flash_erase((void *)flash_addr, length, (void **)&err_addr)) != 0) {
- diag_printf("Can't erase region at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_erase(flash_addr, length, &err_addr)) != 0) {
+ diag_printf("Can't erase region at %p: %s\n", err_addr,
+ cyg_flash_errmsg(stat));
prog_ok = false;
}
}
if (prog_ok) {
// Now program it
- if ((stat = flash_program((void *)flash_addr, (void *)mem_addr, length, (void **)&err_addr)) != 0) {
- diag_printf("Can't program region at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_program(flash_addr, (void *)mem_addr, length,
+ &err_addr)) != 0) {
+ diag_printf("Can't program region at %p: %s\n", err_addr,
+ cyg_flash_errmsg(stat));
prog_ok = false;
}
}
@@ -1169,7 +1210,7 @@
CYG_ADDRESS flash_addr;
bool flash_addr_set = false;
bool length_set = false;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
struct option_info opts[2];
init_opts(&opts[0], 'f', true, OPTION_ARG_TYPE_NUM,
@@ -1187,23 +1228,23 @@
return;
}
if (flash_addr_set &&
- ((stat = flash_verify_addr((void *)flash_addr)) ||
- (stat = flash_verify_addr((void *)(flash_addr+length-1))))) {
+ ((stat = cyg_flash_verify_addr(flash_addr)) ||
+ (stat = cyg_flash_verify_addr((flash_addr+length-1))))) {
_show_invalid_flash_address(flash_addr, stat);
return;
}
- if (flash_addr_set && flash_addr & (flash_block_size-1)) {
+ if (flash_addr_set && flash_addr & (cyg_flash_block_size(flash_addr)-1)) {
diag_printf("Invalid FLASH address: %p\n", (void *)flash_addr);
diag_printf(" must be 0x%x aligned\n", flash_block_size);
return;
}
// Safety check - make sure the address range is not within the code we're running
- if (flash_code_overlaps((void *)flash_addr, (void *)(flash_addr+length-1))) {
+ if (cyg_flash_code_overlaps(flash_addr, (flash_addr+length-1))) {
diag_printf("Can't erase this region - contains code in use!\n");
return;
}
- if ((stat = flash_erase((void *)flash_addr, length, (void **)&err_addr)) != 0) {
- diag_printf("Error erasing at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_erase(flash_addr, length, &err_addr)) != 0) {
+ diag_printf("Error erasing at %p: %s\n", err_addr, cyg_flash_errmsg(stat));
}
}
@@ -1218,7 +1259,7 @@
CYG_ADDRESS flash_addr;
bool flash_addr_set = false;
bool length_set = false;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
struct option_info opts[2];
init_opts(&opts[0], 'f', true, OPTION_ARG_TYPE_NUM,
@@ -1246,13 +1287,13 @@
return;
}
if (flash_addr_set &&
- ((stat = flash_verify_addr((void *)flash_addr)) ||
- (stat = flash_verify_addr((void *)(flash_addr+length-1))))) {
+ ((stat = cyg_flash_verify_addr(flash_addr)) ||
+ (stat = cyg_flash_verify_addr((flash_addr+length-1))))) {
_show_invalid_flash_address(flash_addr, stat);
return;
}
- if ((stat = flash_lock((void *)flash_addr, length, (void **)&err_addr)) != 0) {
- diag_printf("Error locking at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_lock(flash_addr, length, &err_addr)) != 0) {
+ diag_printf("Error locking at %p: %s\n", err_addr, cyg_flash_errmsg(stat));
}
}
@@ -1265,7 +1306,7 @@
CYG_ADDRESS flash_addr;
bool flash_addr_set = false;
bool length_set = false;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
struct option_info opts[2];
init_opts(&opts[0], 'f', true, OPTION_ARG_TYPE_NUM,
@@ -1292,14 +1333,14 @@
return;
}
if (flash_addr_set &&
- ((stat = flash_verify_addr((void *)flash_addr)) ||
- (stat = flash_verify_addr((void *)(flash_addr+length-1))))) {
+ ((stat = cyg_flash_verify_addr(flash_addr)) ||
+ (stat = cyg_flash_verify_addr((flash_addr+length-1))))) {
_show_invalid_flash_address(flash_addr, stat);
return;
}
- if ((stat = flash_unlock((void *)flash_addr, length, (void **)&err_addr)) != 0) {
- diag_printf("Error unlocking at %p: %s\n", err_addr, flash_errmsg(stat));
+ if ((stat = cyg_flash_unlock(flash_addr, length, &err_addr)) != 0) {
+ diag_printf("Error unlocking at %p: %s\n", err_addr, cyg_flash_errmsg(stat));
}
}
#endif
@@ -1309,28 +1350,44 @@
void
_flash_info(void)
-{
+{
+ cyg_uint32 i=0,j;
+ cyg_flash_info_t info;
+ int ret;
+
if (!__flash_init) return;
- diag_printf("FLASH: %p - %p, %d blocks of %p bytes each.\n",
- flash_start, (CYG_ADDRWORD)flash_end + 1, flash_num_blocks, (void *)flash_block_size);
+
+ do {
+ ret = cyg_flash_get_info(i, &info);
+ if (ret == CYG_FLASH_ERR_OK) {
+ diag_printf("FLASH: %p - %p ", info.start, info.end);
+ for (j=0;j < info.num_block_infos; j++) {
+ diag_printf("%d x 0x%x blocks ",
+ info.block_info[j].blocks,
+ info.block_info[j].block_size);
+ }
+ diag_printf("\n");
+ }
+ i++;
+ } while (ret != CYG_FLASH_ERR_INVALID);
}
bool
do_flash_init(void)
{
int stat;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
if (!__flash_init) {
__flash_init = 1;
- if ((stat = flash_init(diag_printf)) != 0) {
- diag_printf("FLASH: driver init failed: %s\n", flash_errmsg(stat));
+ if ((stat = cyg_flash_init(diag_printf)) != 0) {
+ diag_printf("FLASH: driver init failed: %s\n", cyg_flash_errmsg(stat));
return false;
}
- flash_get_limits((void *)0, (void **)&flash_start, (void **)&flash_end);
+ cyg_flash_get_limits(&flash_start, &flash_end);
// Keep 'end' address as last valid location, to avoid wrap around problems
- flash_end = (void *)((CYG_ADDRESS)flash_end - 1);
- flash_get_block_info(&flash_block_size, &flash_num_blocks);
+ flash_end = ((CYG_ADDRESS)flash_end - 1);
+ cyg_flash_get_block_info(&flash_block_size, &flash_num_blocks);
#ifdef CYGOPT_REDBOOT_FIS
fisdir_size = CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_COUNT * CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_SIZE;
fisdir_size = ((fisdir_size + flash_block_size - 1) / flash_block_size) * flash_block_size;
@@ -1345,17 +1402,17 @@
fis_work_block = workspace_end;
# endif
if (CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK < 0) {
- fis_addr = (void *)((CYG_ADDRESS)flash_end + 1 +
- (CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK*flash_block_size));
+ fis_addr = ((CYG_ADDRESS)flash_end + 1 +
+ (CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK*flash_block_size));
} else {
- fis_addr = (void *)((CYG_ADDRESS)flash_start +
- (CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK*flash_block_size));
+ fis_addr = ((CYG_ADDRESS)flash_start +
+ (CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK*flash_block_size));
}
if (((CYG_ADDRESS)fis_addr + fisdir_size - 1) > (CYG_ADDRESS)flash_end) {
diag_printf("FIS directory doesn't fit\n");
return false;
}
- flash_read(fis_addr, fis_work_block, fisdir_size, (void **)&err_addr);
+ cyg_flash_read(fis_addr, fis_work_block, fisdir_size, &err_addr);
#endif
}
return true;
Index: redboot/current/src/io.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/io.c,v
retrieving revision 1.32
diff -u -r1.32 io.c
--- redboot/current/src/io.c 5 Dec 2003 12:51:55 -0000 1.32
+++ redboot/current/src/io.c 16 Jul 2004 11:21:06 -0000
@@ -387,6 +387,7 @@
mon_read_char(&c);
}
*eol = '\0';
+
switch (c) {
#define CTRL(c) ((c)&0x1F)
#if CYGNUM_REDBOOT_CMD_LINE_EDITING != 0
Index: fs/jffs2/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/ChangeLog,v
retrieving revision 1.34
diff -u -r1.34 ChangeLog
--- fs/jffs2/current/ChangeLog 29 Apr 2004 07:16:10 -0000 1.34
+++ fs/jffs2/current/ChangeLog 16 Jul 2004 11:21:07 -0000
@@ -1,3 +1,27 @@
+2004-07-14 Andrew Lunn <andrew.lunn@ascom.ch>
+
+ * tests/fileio1.c (main): If we have two filesystem configured
+ mount the second one on /mnt and list the root of it.
+ * src/fs-ecos.c (jffs2_fo_write): Fixed a typo in a debug print
+ which is normally disabled.
+
+2004-07-12 Andrew Lunn <andrew.lunn@ascom.ch>
+
+ * src/fs-ecos.c (jffs2_fo_lseek): Put back part of the fix for
+ lseeking past the end of the file which was removed during the last
+ merge with MTD.
+
+2004-07-10 Andrew Lunn <andrew.lunn@ascom.ch>
+
+ * src/flashio.c (jffs2_flash_erase): Minor update for new
+ flash API.
+
+2004-06-21 Dirk Eibach <eibach@gdsys.de>
+2004-06-21 Andrew Lunn <andrew.lunn@ascom.ch>
+
+ * src/fs-ecos.c (jffs2_getinfo): Added support for
+ FS_INFO_{FREE|USED} on a filesystem.
+
2004-04-19 Oyvind Harboe <oyvind.harboe@zylin.com>
* src/build.c: JFFS2 can now be used as a write-once, read many mode
Index: fs/jffs2/current/src/flashio.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/src/flashio.c,v
retrieving revision 1.1
diff -u -r1.1 flashio.c
--- fs/jffs2/current/src/flashio.c 11 Dec 2003 23:38:21 -0000 1.1
+++ fs/jffs2/current/src/flashio.c 16 Jul 2004 11:21:07 -0000
@@ -144,7 +144,7 @@
struct jffs2_eraseblock * jeb)
{
cyg_io_flash_getconfig_erase_t e;
- void *err_addr;
+ cyg_flashaddr_t err_addr;
Cyg_ErrNo err;
cyg_uint32 len = sizeof (e);
struct super_block *sb = OFNI_BS_2SFFJ(c);
Index: fs/jffs2/current/src/fs-ecos.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/src/fs-ecos.c,v
retrieving revision 1.27
diff -u -r1.27 fs-ecos.c
--- fs/jffs2/current/src/fs-ecos.c 21 Apr 2004 18:51:21 -0000 1.27
+++ fs/jffs2/current/src/fs-ecos.c 16 Jul 2004 11:21:08 -0000
@@ -1360,7 +1360,7 @@
int err;
D2(printf("jffs2_fo_write page_start_pos %d\n", pos));
- D2(printf("jffs2_fo_write transfer size %d\n", l));
+ D2(printf("jffs2_fo_write transfer size %d\n", len));
err = jffs2_write_inode_range(c, f, &ri, buf,
pos, len, &writtenlen);
@@ -1420,7 +1420,7 @@
// Check that pos is still within current file size, or at the
// very end.
- if (pos < 0 || pos > node->i_size)
+ if (pos < 0 )
return EINVAL;
// All OK, set fp offset and return new position.
Index: fs/jffs2/current/tests/fileio1.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/tests/fileio1.c,v
retrieving revision 1.3
diff -u -r1.3 fileio1.c
--- fs/jffs2/current/tests/fileio1.c 11 Dec 2003 23:33:55 -0000 1.3
+++ fs/jffs2/current/tests/fileio1.c 16 Jul 2004 11:21:09 -0000
@@ -73,6 +73,8 @@
#include <string.h>
#include <dirent.h>
+#include <stdlib.h>
+
#include <cyg/fileio/fileio.h>
#include <cyg/infra/testcase.h>
@@ -416,6 +418,14 @@
//int i;
int existingdirents=-1;
+ struct mallinfo info;
+
+ info = mallinfo();
+ diag_printf("arenasize %d, freeblocks %d, totalallocated %d, totalfree %d, maxfree %d\n",
+ info.arena, info.ordblks, info.uordblks, info.fordblks, info.maxfree);
+
+
+
CYG_TEST_INIT();
// --------------------------------------------------------------
@@ -658,9 +668,33 @@
err = umount( "/jffs2" );
if( err < 0 ) SHOW_RESULT( umount, err );
+#ifdef CYGDAT_IO_FLASH_BLOCK_DEVICE_NAME_2
+ diag_printf("<INFO>: mounting second JFFS2 filesystem on /mnt\n");
+
+ err = mount( CYGDAT_IO_FLASH_BLOCK_DEVICE_NAME_1, "/mnt", "jffs2" );
+ if( err < 0 ) SHOW_RESULT( mount, err );
+
+ err = chdir( "/" );
+ if( err < 0 ) SHOW_RESULT( chdir, err );
+
+ checkcwd( "/" );
+
+ listdir( "/", true, -1, &existingdirents );
+ if ( existingdirents < 2 )
+ CYG_TEST_FAIL("Not enough dir entries\n");
+
+ listdir( "/mnt", true, -1, &existingdirents );
+ if ( existingdirents < 2 )
+ CYG_TEST_FAIL("Not enough dir entries\n");
+
+ diag_printf("<INFO>: umount /mnt\n");
+ err = umount( "/mnt" );
+#endif
+
diag_printf("<INFO>: umount /\n");
err = umount( "/" );
if( err < 0 ) SHOW_RESULT( umount, err );
+
CYG_TEST_PASS_FINISH("fileio1");
}
[-- Attachment #5: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-07-16 13:39 [ECOS] Flash infrastructure rework Andrew Lunn
@ 2004-07-19 14:18 ` Ian Campbell
2004-07-30 10:43 ` Andrew Lunn
2004-08-04 12:54 ` Jani Monoses
` (2 subsequent siblings)
3 siblings, 1 reply; 27+ messages in thread
From: Ian Campbell @ 2004-07-19 14:18 UTC (permalink / raw)
To: Andrew Lunn; +Cc: eCos Disuss
This looks like good stuff. I do especially like the lack of flash_info*
being passed around everywhere like in my own patch. I'll have to find
some time to try it out.
One question -- what do you think of the possibility of supporting paged
flash devices? This was the main motivation with my patch for making the
API take offsets into the flash device rather than absolute memory
addresses.
By paged flash device I mean one where only say 256k are visible in the
memory map at any one time, controlled via a separate I/O location.
Several of our older boards (previously running DOS) have this
architecture.
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-07-19 14:18 ` Ian Campbell
@ 2004-07-30 10:43 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-07-30 10:43 UTC (permalink / raw)
To: Ian Campbell; +Cc: Andrew Lunn, eCos Disuss
> One question -- what do you think of the possibility of supporting paged
> flash devices? This was the main motivation with my patch for making the
> API take offsets into the flash device rather than absolute memory
> addresses.
Thats simple to do. The address does not have to be an address in the
normal address space. It could be a virtual address in the flash
address space. The driver would simply take the virtual flash address
and work out what page that is, map it in, do the copy/erase/write and
then return. I need to double check, but i think the API would allow
this.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-07-16 13:39 [ECOS] Flash infrastructure rework Andrew Lunn
2004-07-19 14:18 ` Ian Campbell
@ 2004-08-04 12:54 ` Jani Monoses
2004-08-04 19:06 ` Andrew Lunn
2004-08-04 19:13 ` Andrew Lunn
2004-08-19 15:21 ` Bart Veer
3 siblings, 1 reply; 27+ messages in thread
From: Jani Monoses @ 2004-08-04 12:54 UTC (permalink / raw)
To: ecos-discuss
Hi Andrew
just two small comments after a quick glance.
> #ifdef CYGPKG_KERNEL
> __externC int cyg_flash_mutex_lock(const cyg_flashaddr_t from,
> const size_t len);
> __externC int cyg_flash_mutex_unlock(const cyg_flashaddr_t from,
> #endif
could use the cyg_drv_mutex API so that even in non-kernel configs such as
redboot, the flash driver is safe from interrupts. This just happened to us:
with interrupts enabled in redboot, flash operations hung sometimes.
> // Structure of pointers to functions in the device driver
> struct cyg_flash_dev_funs {
[...]
> int (*flash_hwr_map_error) (struct cyg_flash_dev *dev, int err);
>
should this be exposed? It looks like it is used after program/erase etc to
convert the stat already returned. Drivers should already return 'normal'
flash errors IMHO.
Also what do you and the other maintainers think of converting the actual
flash code to the cyg_ namespace soon? That way your patch too would have
less differences, and drivers would be easier to adapt to the new API.
Jani
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-04 12:54 ` Jani Monoses
@ 2004-08-04 19:06 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-08-04 19:06 UTC (permalink / raw)
To: Jani Monoses; +Cc: ecos-discuss
On Wed, Aug 04, 2004 at 03:54:46PM +0300, Jani Monoses wrote:
> Hi Andrew
>
> just two small comments after a quick glance.
>
> > #ifdef CYGPKG_KERNEL
> > __externC int cyg_flash_mutex_lock(const cyg_flashaddr_t from,
> > const size_t len);
> > __externC int cyg_flash_mutex_unlock(const cyg_flashaddr_t from,
> > #endif
>
> could use the cyg_drv_mutex API so that even in non-kernel configs such as
> redboot, the flash driver is safe from interrupts. This just happened to us:
> with interrupts enabled in redboot, flash operations hung sometimes.
This is not simple. See the "Danger, Will Robinson! Danger!" section
of the documentation. The setup makes a big difference as to what is
safe and what is not. Disabling all interrupts is the only guarantee
that something will not cause a crass. But in many cases this is not
needed. Also, since eCos is an RTOS, disabling interrupts for a long
time is not a good idea. So i decided it was better to document the
problem and let the programmer decide what to do, ie arrange that
everything runs in RAM, is disable interrupts before calling into
FLASH code.
> > // Structure of pointers to functions in the device driver
> > struct cyg_flash_dev_funs {
> [...]
> > int (*flash_hwr_map_error) (struct cyg_flash_dev *dev, int err);
> >
>
> should this be exposed? It looks like it is used after program/erase etc to
> convert the stat already returned. Drivers should already return 'normal'
> flash errors IMHO.
I was following the old API here. The value from the driver could be
useful when it returns more information than can be returned by the
defined error codes. It also makes it easier to port code from the old
API. If we decide to change this, i would keep the driver API as it
is, and add the call to flash_hwr_map_error inside the io flash layer.
> Also what do you and the other maintainers think of converting the actual
> flash code to the cyg_ namespace soon? That way your patch too would have
> less differences, and drivers would be easier to adapt to the new API.
My patch is about ready to go, by the end of this week i think. So i
think this makes no sense.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-07-16 13:39 [ECOS] Flash infrastructure rework Andrew Lunn
2004-07-19 14:18 ` Ian Campbell
2004-08-04 12:54 ` Jani Monoses
@ 2004-08-04 19:13 ` Andrew Lunn
2004-08-06 13:22 ` Andrew Lunn
2004-08-19 15:21 ` Bart Veer
3 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2004-08-04 19:13 UTC (permalink / raw)
To: eCos Disuss
> However in the background i took a step back and overhauled the whole
> flash infrastructure in what i hope is a clean and consistent API with
> all the features required:
>
> Multiple device drivers at the same time
> Multiple instantiations of the same driver
> Probing to detect what is actually on the board
> Support for boot block devices which have different size blocks
> Thread safe when used with the kernel
> Does not pollute the name space
> Optional backward compatible with old drivers
> Optional backward compatible with old API
> Able to support multiple JFFS2 filesystems
> Redboot to be able to access multiple devices
> Documentation!
This is about ready to go live. The question is how do we do
this. There is a danger there are bugs left which could brick
boards. ie destroy the bootloader and if you don't have jtag there is
no way to recover the hardware.
There are a few options:
I commit it and let people test it. If there are major problems we
undo the change while we debug the problem.
I put the code on a branch so that a few people can test it and so we
get a better idea how stable the code is with hardware i don't have
access to.
I can send patches to people who would like to test.
Suggestions welcome.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-04 19:13 ` Andrew Lunn
@ 2004-08-06 13:22 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-08-06 13:22 UTC (permalink / raw)
To: eCos Disuss
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
> I put the code on a branch so that a few people can test it and so we
> get a better idea how stable the code is with hardware i don't have
> access to.
This is what i decided to do. In cvs there is now a branch called
flash_v2. If you checkout/update to that branch you will get my new
flash code. There is also new generic drivers for SST and
Strata. Since so many targets use strata i did not want to modify them
all to use the new driver. So the strata driver is a new packets along
side the old one. For the SST driver i have modified all targets that
use it. That was easier since only the e7t and the aim711 use this
driver.
I've attached a hardware dependent driver for our platform which makes
use of the sst and strata device. This could be used as an example as
to how to modify the hardware dependent part of a flash driver to use
the new code.
One thing to watch out for is that the hardware dependent driver has
to go into libextras.a. If you forget this the driver will be thrown
away at link time...
And lastly a warning to testers.... There could be bugs which destroy
your boot loader etc. Make sure you can restore the device with jtag
before playing with this code.
Thanks
Andrew
[-- Attachment #2: fzpf_flash.tgz --]
[-- Type: application/x-gtar, Size: 2423 bytes --]
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-07-16 13:39 [ECOS] Flash infrastructure rework Andrew Lunn
` (2 preceding siblings ...)
2004-08-04 19:13 ` Andrew Lunn
@ 2004-08-19 15:21 ` Bart Veer
2004-08-19 16:38 ` Andrew Lunn
3 siblings, 1 reply; 27+ messages in thread
From: Bart Veer @ 2004-08-19 15:21 UTC (permalink / raw)
To: andrew; +Cc: ecos-discuss
Some thoughts on the new flash interface. I know it has been a while
since you asked for comments...
Interrupts
----------
I believe it is very important we sort out the interrupt issue.
Disabling interrupts at a high level while erasing or writing multiple
blocks will affect real-time responsiveness, and should be
unnecessary. Instead that sort of thing should be handled by the
device drivers at a finer grain, to the extent permitted by the
hardware.
For example, the current AMD flash_program_buf() routine does not
perform any locking, relying on higher levels. Each write operation
requires a number of atomic flash writes and reads, with no other
flash accesses allowed (some devices do allow concurrent reads from
other areas of the flash, but that gets messy in a generic AMD
driver). The only safe way to do this is to disable interrupts, but we
need only disable interrupts for each byte or word, not for the whole
block.
flash_erase_block() is more complicated because it requires polling
while the chip does its stuff. Most devices support erase-suspend
(AFAIK) so we could have a sequence: disable interrupts, start the
erase, poll for completion for a short while, suspend it, reenable
interrupts, disable interrupts again, and resume the erase. There is
no need to have interrupts disabled for the entire operation.
If we are going to move interrupt handling down into the drivers then
we'll also have to move any cache manipulation there. The alternative
would be e.g. a potential context switch while the caches are
disabled, and then the system is messed up. Manipulating interrupts
and cache at a finer grain than at present will have a significant
effect on the time taken by the various operations. I haven't done any
experiments yet to know how much longer, and obviously it is going to
depend on the hardware (especially the cache-related bits). Possibly
it can be handled by configury, but that needs investigation as well.
Should we be addressing this issue at this time? Any changes along
these lines involve a serious risk of breaking things for various
targets, but that will always be true. Since we have a flash
development branch I think this is probably going to be as good a time
as any.
Packages
--------
While considering major changes, there is another topic I want to
raise. The current convention is to have per-platform flash device
driver packages, for example devs/flash/arm/ contains 31 separate
packages. Packages are very useful if they can be shared and re-used.
They are also very useful to isolate hardware-specific non-shareable
code in one place, e.g. the platform HAL. Platform-specific flash
driver packages do not fit into either category.
For the various customer ports I have been doing I have been putting
the flash support into the platform HALs. After all the flash device
is an integral part of the platform, just like the RAM, and we don't
have separate device drivers for each platform's RAM subsystem. In the
platform CDL I have something like:
cdl_option CYGHWR_HAL_M68K_M5272C3_FLASH {
display "FLASH memory support"
parent CYGPKG_IO_FLASH
active_if CYGPKG_IO_FLASH
implements CYGINT_DEVS_FLASH_AMD_AM29XXXXX_REQUIRED
requires CYGHWR_DEVS_FLASH_AMD_AM29PL160
flavor none
compile m5272c3_flash.c
description "
The M5272C3 evaluation board comes with a single AM29PL160C
flash memory device."
}
In the platform HAL's src directory I then have a file m5272c3_flash.c
which instantiates the flash device, but only if the generic flash
support support is enabled because of the active_if. Hence all the
platform-specific information remains in one place, the platform HAL,
and there is no proliferation of non-reusable packages elsewhere in
the hierarchy. There is no change to the user experience, everything
works much as before.
Given the number of existing platforms in the repository changing them
all over is probably not an option, but for new platforms I would prefer
not to see unnecessary packages.
The API
-------
Mostly this looks fine, although I think you are trying too hard to
make it similar to the old API. Since we are making major changes we
may as well make the new API as clean as possible.
cyg_flash_init(): could we get rid of this and replace it with a
prioritized static constructor? That way we would know for sure that
the flash drivers have been initialized before the application starts
up. AFAIK the existing flash drivers init routines are all pretty
straightforward so this is not going to add significantly to startup
time. It would eliminate the need in various places to check that the
flash subsystem has been initialized, and the corresponding error
conditions.
Currently cyg_flash_init() provides the cyg_flash_printf function so
we would need a different approach for that. Possibly an exported weak
variable with a default value of &diag_printf, which application code
can then override.
cyg_flash_get_block_info() and cyg_flash_get_limits(): I think we
should just get rid of these completely. Full information on the
flash is available by other calls, and higher-level code such as
RedBoot should be made to use these.
cyg_flash_code_overlaps(): I am not sure this can be cleanly defined.
For example, consider a platform with one flash chip that uses bottom
boot blocks. If we want to make efficient use of this chip then we
want to place the fis and fconfig data in these boot blocks. Hence the
first boot block will contain some startup code followed by a jump to
later in the flash, then we'll have the fis and fconfig blocks, and
then the rest of the code. How would cyg_flash_code_overlaps() work
with that scenario?
cyg_flash_lock() and cyg_flash_unlock(): possibly this functionality
should be provided by a more generic cyg_flash_ioctl() function. That
would also give us a way of supporting device-specific flash
operations in future. Usually I don't like general-purpose ioctl()
routines because they cannot easily be garbage collected by the
linker, but in this case it may be worthwhile.
cyg_flash_errmsg(): should we consider eliminating flash-specific
error codes and switching to errno values? Resulting diagnostics
output will be generic rather than flash-specific, so less useful,
but arguably it would simplify the system. I am not sure we want to
make this change, but we should consider it.
cyg_flash_mutex_lock() and cyg_flash_mutex_unlock(): there may be a
problem with these in some scenarios. If there is a virtual vector
function which calls into RedBoot to e.g. change an fconfig option,
the flash code inside RedBoot won't see the kernel mutex. This is part
of a larger problem, properly synchronizing between virtual vector
functions and a multi-threaded application, but it needs to be
considered.
The Implementation
------------------
I have various comments on the CDL, headers, sources, and
documentation, but this message is long enough already. Some of these
will require discussion, others can be handled by patches. I'll check
out the flash_v2 branch and start experimenting on some of the boards
I have available. Most of these use AMD-compatible chips, and I can
rescue them via BDM when necessary.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-19 15:21 ` Bart Veer
@ 2004-08-19 16:38 ` Andrew Lunn
2004-08-20 14:44 ` Bart Veer
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2004-08-19 16:38 UTC (permalink / raw)
To: Bart Veer; +Cc: andrew, ecos-discuss
On Thu, Aug 19, 2004 at 04:21:14PM +0100, Bart Veer wrote:
> Some thoughts on the new flash interface. I know it has been a while
> since you asked for comments...
No problems, comments are always welcome
> Interrupts
> ----------
>
> I believe it is very important we sort out the interrupt issue.
You are braver than i am. I decided this was too thorny an issue to
tackle and just documented the problem. It is only a problem when the
application or RedBoot is running from ROM. Currently interrupt
disabling is left to the application programmer do use if needed.
> Disabling interrupts at a high level while erasing or writing multiple
> blocks will affect real-time responsiveness, and should be
> unnecessary. Instead that sort of thing should be handled by the
> device drivers at a finer grain, to the extent permitted by the
> hardware.
Agreed. As a general approach, what i would like to do is get a
generic CFI driver working which has all these bells and whistles and
uses the new driver API. Since many flash devices nowadays are CFI
compatible, i think it makes sense to do this rather than look at the
AMD generic driver, the Intel Generic Driver, the SST generic driver
etc.
> If we are going to move interrupt handling down into the drivers then
> we'll also have to move any cache manipulation there. The alternative
> would be e.g. a potential context switch while the caches are
> disabled, and then the system is messed up.
Why is it messed up? The current macros don't just disable it, they
flush and invalidate it first. So a context switch is safe. The higher
priority threads which gets to run will run slower since it does not
have any caching, but thats how it currently works anyway. The only
read danger is if something else unconditional re-enables the cache
and then we are dead when the flash driver gets control again.
> Packages
> --------
>
> While considering major changes, there is another topic I want to
> raise. The current convention is to have per-platform flash device
> driver packages, for example devs/flash/arm/ contains 31 separate
> packages. Packages are very useful if they can be shared and re-used.
> They are also very useful to isolate hardware-specific non-shareable
> code in one place, e.g. the platform HAL. Platform-specific flash
> driver packages do not fit into either category.
>
> For the various customer ports I have been doing I have been putting
> the flash support into the platform HALs.
This is mainly a documentation issue. I would like to spend some time
extending the documentation to include hints for people writing new
drivers. Or maybe it should be part of the Porting guide? But before
spending time on the documentation i would like to see the code stable
and well tested.
> The API
> -------
>
> Mostly this looks fine, although I think you are trying too hard to
> make it similar to the old API. Since we are making major changes we
> may as well make the new API as clean as possible.
>
> cyg_flash_init(): could we get rid of this and replace it with a
> prioritized static constructor? That way we would know for sure that
> the flash drivers have been initialized before the application starts
> up. AFAIK the existing flash drivers init routines are all pretty
> straightforward so this is not going to add significantly to startup
> time. It would eliminate the need in various places to check that the
> flash subsystem has been initialized, and the corresponding error
> conditions.
The danger here is when it tries to print something. I fell fouls of
this myself. I had a configuration with both sst and strata drivers
configured in because our hardware can have one or the other at the
same address. It worked fine on the sst version but locked solid on
the strata version. And it only locked when i had jffs2. jffs2
requires the block device driver for the flash. This gets initialized
by a constructor early on and it called the cyg_flash_init
function. That was calling the sst init function, which failed to find
its device and was printing an error message. But at this point the
virtual vectors were not setup and so diag_printf just locked the
target solid.
For this to work reliably, we need to look at every flash driver and
make sure it cannot print anything during its initialisation routine.
Or we need to be 100% sure the virtual vectors are setup.
We would also have to be careful with the constructor ordering. The
block devices would have to be after the flash device or jffs2 would
get into problems.
> Currently cyg_flash_init() provides the cyg_flash_printf function so
> we would need a different approach for that. Possibly an exported weak
> variable with a default value of &diag_printf, which application code
> can then override.
That would work. jffs2 would also want to override this or you get
lots of output.
>
> cyg_flash_get_block_info() and cyg_flash_get_limits(): I think we
> should just get rid of these completely. Full information on the
> flash is available by other calls, and higher-level code such as
> RedBoot should be made to use these.
I thought about that and changing redoot to use the other calls is
something that is needed when making redboot use bootblocks. Removing
these calls just makes it harder for people porting there own
applications to the new api.
> cyg_flash_code_overlaps(): I am not sure this can be cleanly defined.
> For example, consider a platform with one flash chip that uses bottom
> boot blocks. If we want to make efficient use of this chip then we
> want to place the fis and fconfig data in these boot blocks. Hence the
> first boot block will contain some startup code followed by a jump to
> later in the flash, then we'll have the fis and fconfig blocks, and
> then the rest of the code. How would cyg_flash_code_overlaps() work
> with that scenario?
The HAL needs to be able to implement it. That is the only thing that
knows what goes where. I didn't really like this function to start
with, but redboot uses it quite a lot for user input sanity
checking. We could remove it and hope the user knows what (s)he is
doing.
> cyg_flash_lock() and cyg_flash_unlock(): possibly this functionality
> should be provided by a more generic cyg_flash_ioctl() function. That
> would also give us a way of supporting device-specific flash
> operations in future. Usually I don't like general-purpose ioctl()
> routines because they cannot easily be garbage collected by the
> linker, but in this case it may be worthwhile.
The generally semantic of ioctl is that you have to open the device
first, ie the unix file model. The flash API is not file based so i
don't really think ioctl fits. Im also not sure what extensions could
be added except for NAND devices where you need to add access to the
OOB area. Gary is working on this at the moment i think. It would be
interesting to know how he decided to do it.
> cyg_flash_mutex_lock() and cyg_flash_mutex_unlock(): there may be a
> problem with these in some scenarios. If there is a virtual vector
> function which calls into RedBoot to e.g. change an fconfig option,
> the flash code inside RedBoot won't see the kernel mutex. This is part
> of a larger problem, properly synchronizing between virtual vector
> functions and a multi-threaded application, but it needs to be
> considered.
The calling side of the VV functions which can change the flash should
call these functions. This is exactly what they are for. The problem
comes with knowing what area to lock. Maybe a rogue address is needed
to indicate all devices should be locked?
> The Implementation
> ------------------
>
> I have various comments on the CDL, headers, sources, and
> documentation, but this message is long enough already. Some of these
> will require discussion, others can be handled by patches. I'll check
> out the flash_v2 branch and start experimenting on some of the boards
> I have available. Most of these use AMD-compatible chips, and I can
> rescue them via BDM when necessary.
Great. More testing is definitely needed. I keep finding
configurations which i've not tried and either don't compile or don't
work.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-19 16:38 ` Andrew Lunn
@ 2004-08-20 14:44 ` Bart Veer
2004-08-20 16:37 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Bart Veer @ 2004-08-20 14:44 UTC (permalink / raw)
To: andrew; +Cc: ecos-discuss
>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:
>> Interrupts
>> ----------
>>
>> I believe it is very important we sort out the interrupt issue.
Andrew> You are braver than i am. I decided this was too thorny an
Andrew> issue to tackle and just documented the problem. It is
Andrew> only a problem when the application or RedBoot is running
Andrew> from ROM. Currently interrupt disabling is left to the
Andrew> application programmer do use if needed.
I believe it is a much bigger problem than that. Any scenario
involving ROM RedBoot and a RAM application can be affected. The
application may make a virtual vector call into RedBoot, e.g. a
printf(). Or exceptions or incoming gdb events may drop you into gdb
stubs inside RedBoot. Or concurrent read and write operations in a
flash-based file system - although I am not sure how jffs2 handles
that at the moment. The application may also be manipulating the flash
directly in various ways.
Unless you know exactly what is going on in the application,
interrupts should be disabled before performing a low-level flash op.
Otherwise you end up with code that only works most of the time. I
believe by default this should be handled by eCos, not left to the
application.
>> Disabling interrupts at a high level while erasing or writing
>> multiple blocks will affect real-time responsiveness, and
>> should be unnecessary. Instead that sort of thing should be
>> handled by the device drivers at a finer grain, to the extent
>> permitted by the hardware.
Andrew> Agreed. As a general approach, what i would like to do is
Andrew> get a generic CFI driver working which has all these bells
Andrew> and whistles and uses the new driver API. Since many flash
Andrew> devices nowadays are CFI compatible, i think it makes
Andrew> sense to do this rather than look at the AMD generic
Andrew> driver, the Intel Generic Driver, the SST generic driver
Andrew> etc.
I am not sure we can drop the existing AMD driver, there are an awful
lot of board ports which use it. However any work done sorting out the
interrupt/cache issues in one driver should carry across fairly easily
to other drivers.
Also, the AMD driver may have size advantages because you don't need
the code that does the hardware querying. And it may be easier to
specify which bootblocks should be used for fis and fconfig if you
know exactly which chip(s) may be used, rather than figuring it out at
run-time somehow.
>> If we are going to move interrupt handling down into the
>> drivers then we'll also have to move any cache manipulation
>> there. The alternative would be e.g. a potential context switch
>> while the caches are disabled, and then the system is messed
>> up.
Andrew> Why is it messed up? The current macros don't just disable
Andrew> it, they flush and invalidate it first. So a context
Andrew> switch is safe. The higher priority threads which gets to
Andrew> run will run slower since it does not have any caching,
Andrew> but thats how it currently works anyway. The only read
Andrew> danger is if something else unconditional re-enables the
Andrew> cache and then we are dead when the flash driver gets
Andrew> control again.
Running with caches disabled can easily cost you an order of magnitude
in performance. Suppose your application has a highish priority
thread, regularly woken up by an interrupt, which consumes about 50%
of the available cpu time for its processing. In a lower-priority
thread you do a write to a jffs2 logfile. The flash write starts, the
cache is disabled, an interrupt happens and wakes up the higher
priority thread, it tries to do its processing but will do so much
more slowly than before and can no longer keep up with the incoming
interrupts, and the lower-priority thread doing the flash write never
wakes up again to re-enable the cache. The system is messed up.
The only safe way to handle the cache is to disable interrupts,
manipulate the cache as required, do the appropriate things to the
hardware, restore the cache, and re-enable interrupts. Allowing
interrupts or context switches while the cache is disabled is unsafe.
<snip>
>> cyg_flash_get_block_info() and cyg_flash_get_limits(): I think
>> we should just get rid of these completely. Full information on
>> the flash is available by other calls, and higher-level code
>> such as RedBoot should be made to use these.
Andrew> I thought about that and changing redoot to use the other
Andrew> calls is something that is needed when making redboot use
Andrew> bootblocks. Removing these calls just makes it harder for
Andrew> people porting there own applications to the new api.
I don't think that is a big deal, the functions would remain in the
legacy API. Since we are introducing a new API we should make it as
clean as possible.
>> cyg_flash_code_overlaps(): I am not sure this can be cleanly
>> defined. For example, consider a platform with one flash chip
>> that uses bottom boot blocks. If we want to make efficient use
>> of this chip then we want to place the fis and fconfig data in
>> these boot blocks. Hence the first boot block will contain some
>> startup code followed by a jump to later in the flash, then
>> we'll have the fis and fconfig blocks, and then the rest of the
>> code. How would cyg_flash_code_overlaps() work with that
>> scenario?
Andrew> The HAL needs to be able to implement it. That is the only
Andrew> thing that knows what goes where. I didn't really like
Andrew> this function to start with, but redboot uses it quite a
Andrew> lot for user input sanity checking. We could remove it and
Andrew> hope the user knows what (s)he is doing.
HAL checks may not suffice if the application makes virtual vector
calls. RedBoot could get much the same functionality by detecting
CYG_HAL_STARTUP_ROM and looking for an overlap with its own fis entry,
without needing a dubious flash_code_overlaps() function. That won't
work 100% on all platforms, e.g. there may be startup types other than
ROM which also have RedBoot resident in flash, but it will work on
most.
>> cyg_flash_lock() and cyg_flash_unlock(): possibly this
>> functionality should be provided by a more generic
>> cyg_flash_ioctl() function. That would also give us a way of
>> supporting device-specific flash operations in future. Usually
>> I don't like general-purpose ioctl() routines because they
>> cannot easily be garbage collected by the linker, but in this
>> case it may be worthwhile.
Andrew> The generally semantic of ioctl is that you have to open
Andrew> the device first, ie the unix file model. The flash API is
Andrew> not file based so i don't really think ioctl fits. Im also
Andrew> not sure what extensions could be added except for NAND
Andrew> devices where you need to add access to the OOB area. Gary
Andrew> is working on this at the moment i think. It would be
Andrew> interesting to know how he decided to do it.
I was thinking of a function cyg_flash_ioctl(const cyg_flashaddr_t, ...),
rather than something involving file descriptors. Of course if you use
open/read/write on a flash block device then ioctl() would be readily
mapped onto cyg_flash_ioctl().
Another possible extension that springs to mind is entering/leaving
power saving mode.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-20 14:44 ` Bart Veer
@ 2004-08-20 16:37 ` Andrew Lunn
2004-08-22 13:02 ` Gary Thomas
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Lunn @ 2004-08-20 16:37 UTC (permalink / raw)
To: Bart Veer; +Cc: andrew, ecos-discuss
On Fri, Aug 20, 2004 at 03:44:36PM +0100, Bart Veer wrote:
> >>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:
>
> >> Interrupts
> >> ----------
> >>
> >> I believe it is very important we sort out the interrupt issue.
>
> Andrew> You are braver than i am. I decided this was too thorny an
> Andrew> issue to tackle and just documented the problem. It is
> Andrew> only a problem when the application or RedBoot is running
> Andrew> from ROM. Currently interrupt disabling is left to the
> Andrew> application programmer do use if needed.
>
> I believe it is a much bigger problem than that. Any scenario
> involving ROM RedBoot and a RAM application can be affected.
Yep, thats what i said: "application or redboot is running from ROM".
To be safe you need a RAMROM/RAM redboot and a ROMRAM/RAM application.
> Or concurrent read and write operations in a
> flash-based file system - although I am not sure how jffs2 handles
> that at the moment.
Jffs2 plays nice and uses the flash API. So the mutex locking will
ensure that there are no similtanious operations with anything else.
> The application may also be manipulating the flash directly in
> various ways.
But thats the nornal case of all bets are off if you go direct to the
hardware and ignore the OS. Any application that does that is broken.
> I am not sure we can drop the existing AMD driver, there are an awful
> lot of board ports which use it. However any work done sorting out the
> interrupt/cache issues in one driver should carry across fairly easily
> to other drivers.
I would not drop the driver. Its too much work to change every
platform to use a generic CFI driver. I would more encourage people to
use the new drivers for new ports.
> Also, the AMD driver may have size advantages because you don't need
> the code that does the hardware querying. And it may be easier to
> specify which bootblocks should be used for fis and fconfig if you
> know exactly which chip(s) may be used, rather than figuring it out at
> run-time somehow.
Humm, maybe. I've not looked yet at how redboot would support boot
blocks. The CDL becomes interesting base the current block offsets
concept assumes all blocks are the same size.
> >> If we are going to move interrupt handling down into the
> >> drivers then we'll also have to move any cache manipulation
> >> there. The alternative would be e.g. a potential context switch
> >> while the caches are disabled, and then the system is messed
> >> up.
>
> Andrew> Why is it messed up? The current macros don't just disable
> Andrew> it, they flush and invalidate it first. So a context
> Andrew> switch is safe. The higher priority threads which gets to
> Andrew> run will run slower since it does not have any caching,
> Andrew> but thats how it currently works anyway. The only read
> Andrew> danger is if something else unconditional re-enables the
> Andrew> cache and then we are dead when the flash driver gets
> Andrew> control again.
>
> Running with caches disabled can easily cost you an order of magnitude
> in performance. Suppose your application has a highish priority
> thread, regularly woken up by an interrupt, which consumes about 50%
> of the available cpu time for its processing. In a lower-priority
> thread you do a write to a jffs2 logfile. The flash write starts, the
> cache is disabled, an interrupt happens and wakes up the higher
> priority thread, it tries to do its processing but will do so much
> more slowly than before and can no longer keep up with the incoming
> interrupts, and the lower-priority thread doing the flash write never
> wakes up again to re-enable the cache. The system is messed up.
OK. We have a different definition of messed up. Going by that
definition, all current eCos systems using flash are messed up. Thats
exactly what happens today!
I was interpreting you to mean messed up as crashed. If the cache had
been disabled but not flush and invalidated, a context switch under
those conditions could lead to a crash when the thread access
inconsistent memory.
I supposed it should be safe to disable interrupts, disable the cache,
do what is needed and then reenable the cache and lastly
interrupts. There is no need to flush and invalidate the cache which
will save a lot of time.
But its not as simple as that. Its target dependent. eg on the ARM you
don't actually need to do anything with the cache. You setup the MMU
so the range of memory the flash occupies if none-cacheable, not
bufferable and then just access it as normal. Its not optimial since
you loose some performance on reads, but its much simpler.
> >> cyg_flash_get_block_info() and cyg_flash_get_limits(): I think
> >> we should just get rid of these completely. Full information on
> >> the flash is available by other calls, and higher-level code
> >> such as RedBoot should be made to use these.
>
> Andrew> I thought about that and changing redoot to use the other
> Andrew> calls is something that is needed when making redboot use
> Andrew> bootblocks. Removing these calls just makes it harder for
> Andrew> people porting there own applications to the new api.
>
> I don't think that is a big deal, the functions would remain in the
> legacy API. Since we are introducing a new API we should make it as
> clean as possible.
OK. I will take these out.
>
> >> cyg_flash_code_overlaps(): I am not sure this can be cleanly
> >> defined. For example, consider a platform with one flash chip
> >> that uses bottom boot blocks. If we want to make efficient use
> >> of this chip then we want to place the fis and fconfig data in
> >> these boot blocks. Hence the first boot block will contain some
> >> startup code followed by a jump to later in the flash, then
> >> we'll have the fis and fconfig blocks, and then the rest of the
> >> code. How would cyg_flash_code_overlaps() work with that
> >> scenario?
>
> Andrew> The HAL needs to be able to implement it. That is the only
> Andrew> thing that knows what goes where. I didn't really like
> Andrew> this function to start with, but redboot uses it quite a
> Andrew> lot for user input sanity checking. We could remove it and
> Andrew> hope the user knows what (s)he is doing.
>
> HAL checks may not suffice if the application makes virtual vector
> calls. RedBoot could get much the same functionality by detecting
> CYG_HAL_STARTUP_ROM and looking for an overlap with its own fis entry,
> without needing a dubious flash_code_overlaps() function. That won't
> work 100% on all platforms, e.g. there may be startup types other than
> ROM which also have RedBoot resident in flash, but it will work on
> most.
OK. Like i said, i didn't like this function, so im happy to remove
it. Gary, what do you say?
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-20 16:37 ` Andrew Lunn
@ 2004-08-22 13:02 ` Gary Thomas
0 siblings, 0 replies; 27+ messages in thread
From: Gary Thomas @ 2004-08-22 13:02 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Bart Veer, eCos Discussion
On Fri, 2004-08-20 at 10:37, Andrew Lunn wrote:
> On Fri, Aug 20, 2004 at 03:44:36PM +0100, Bart Veer wrote:
> >
> > >> cyg_flash_code_overlaps(): I am not sure this can be cleanly
> > >> defined. For example, consider a platform with one flash chip
> > >> that uses bottom boot blocks. If we want to make efficient use
> > >> of this chip then we want to place the fis and fconfig data in
> > >> these boot blocks. Hence the first boot block will contain some
> > >> startup code followed by a jump to later in the flash, then
> > >> we'll have the fis and fconfig blocks, and then the rest of the
> > >> code. How would cyg_flash_code_overlaps() work with that
> > >> scenario?
> >
> > Andrew> The HAL needs to be able to implement it. That is the only
> > Andrew> thing that knows what goes where. I didn't really like
> > Andrew> this function to start with, but redboot uses it quite a
> > Andrew> lot for user input sanity checking. We could remove it and
> > Andrew> hope the user knows what (s)he is doing.
> >
> > HAL checks may not suffice if the application makes virtual vector
> > calls. RedBoot could get much the same functionality by detecting
> > CYG_HAL_STARTUP_ROM and looking for an overlap with its own fis entry,
> > without needing a dubious flash_code_overlaps() function. That won't
> > work 100% on all platforms, e.g. there may be startup types other than
> > ROM which also have RedBoot resident in flash, but it will work on
> > most.
>
> OK. Like i said, i didn't like this function, so im happy to remove
> it. Gary, what do you say?
I don't care what it's called, or how it works, but I firmly believe
that RedBoot needs a way to determine if the FLASH operation that the
user requests is about to destroy the FLASH/ROM environment. I know
that what's in there now is not perfect, but it catches 95%+ of the
cases. RedBoot needs some way to ask the FLASH infrastructure "if I
let you write/erase <here>, will I wake up in the morning?"
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* [ECOS] Flash infrastructure rework
@ 2004-09-08 12:25 Savin Zlobec
0 siblings, 0 replies; 27+ messages in thread
From: Savin Zlobec @ 2004-09-08 12:25 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
Hi Andrew,
working with flash_v2 I've found two problems:
1) RedBoot's CYGNUM_REDBOOT_FLASH_BASE
is of flavor data with default value 0, so RedBoot will always
try to get flash info with cyg_flash_get_info_addr wich will
result in error if CYGNUM_REDBOOT_FLASH_BASE
is not set correctly. One possible solution would be to set its
flavor to booldata.
2) cyg_flash_erase/program/read loops have their condition set
to addr <= end_addr, many flash drivers calculate flash end address
as CYGNUM_FLASH_BASE+ (flash_dev_info->device_size * CYGNUM_FLASH_SERIES).
If the end address is not in the flash then erase/program/read ops
beyond the flash space can result in endless loops (the lower layer funs are
actually called with length = 0).
savin
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-09 8:47 David Marqvar (DAM)
@ 2004-08-10 2:33 ` Vivek Kumar
0 siblings, 0 replies; 27+ messages in thread
From: Vivek Kumar @ 2004-08-10 2:33 UTC (permalink / raw)
To: "David Marqvar (DAM)"
Cc: Vivek Kumar, Andrew Lunn, ecos-discuss, Vivek.Kumar
Hi,
I am still trying to work with the company to give over there licenses. I
know this is not the right form to ask this but if someone has successfully
dealt with there company please send me an email.
Once I get that issue sorted out I will post my sources online and would
definitely need a lot of help with testing and proper integration to eCos
I am new to esco, and have never used these exact files with esco so I am
expecting some more challenging work for me, and of course all help would
be welcome
-vivek
>
> Hi,
>
> This is really great to hear.
> Vivek, please let me know if I can be to any help for you (testing,
> porting, .cdl-files, etc., etc.)
> I'm really looking out for CFI support. The chip-mess I know :-|
>
> Best regards,
> David Marqvar
>
> -----Original Message-----
> From: Vivek Kumar [mailto:vivek@employees.org]=20
> Sent: 6. august 2004 19:19
> To: David Marqvar (DAM); Andrew Lunn
> Cc: ecos-discuss@ecos.sourceware.org; Vivek.Kumar@zeevo.com
> Subject: Re: [ECOS] Flash infrastructure rework
>
> Hi,
>
> The exact cfi specs can be downloaded from www.jedec.com (registration
> is probably required). AMD and Intel would cover all bases. SST has its
> own extensions (so does Mitsubishi) but they are almost similar to the
> AMD type.
>
> The implementation is really simple, but the the real pain was to take
> care of is the 'diversions' which the vendors take and not tell you.
>
> The things I remember offhand are
>
> - SST flash lists its sectors twice, so if you add all of them up=20
> you get double the flash size.
> - SST also needs some extended commands to enter the CFI mode.
> - AMD extensions V1.1 and below do not tell whether its a top boot
>
> flash or a bottom boot and the sectors are sometime stored as=20
> smallest first or the largest first. We had to read the Flash ID
>
> to determine what to do with the sectors.
> =20
> and on and on and on=20
>
>
> At one point we were thinking why the hell did we try cfi? But having
> one that I can say for sure its really good we did that. Marketing now
> does not now come to me every other day asking if I can add driver
> support for xxx flash, which most of the time meant reading the spec
> adding another table and testing it. Whew..
>
> -Vivek
>
> http://www.vivekkumar.net
>
> > -----Original Message-----
> > From: David Marqvar (DAM) [mailto:DAM@tt.dk]
> > Sent: Friday, August 06, 2004 6:45 AM
> > To: Andrew Lunn
> > Cc: ecos-discuss@ecos.sourceware.org
> > Subject: RE: [ECOS] Flash infrastructure rework
> >=20
> >=20
> > Sounds great.
> >=20
> > I've been wanting to make a general flash driver based on CFI which=20
> > would support the two main programming algorithm's around: Intel
> > (Strata) and AMD (don't know if it's really these companies that=20
> > invented the algorithm, anyway I think you know what I mean). Is SST=20
> > yet another programming algorithm or =3D=3D ADM?
> >=20
> > Though CFI I can read the physical layout of the flash and the=20
> > programming algorithm to use.
> > This way the flash-driver could be generel, not limited to one or more
>
> > certian devices.
> >=20
> > Do you see any show-stoppers for creating such driver?
> >=20
> > /David
> >=20
> > -----Original Message-----
> > From: ecos-discuss-owner@ecos.sourceware.org
> > [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew=20
> > Lunn
> > Sent: 6. august 2004 15:23
> > To: eCos Disuss
> > Subject: Re: [ECOS] Flash infrastructure rework
> >=20
> > > I put the code on a branch so that a few people can test it and so=20
> > > we get a better idea how stable the code is with hardware i don't=20
> > > have access to.
> >=20
> > This is what i decided to do. In cvs there is now a branch called=20
> > flash_v2. If you checkout/update to that branch you will get my new=20
> > flash code. There is also new generic drivers for SST and Strata.=20
> > Since so many targets use strata i did not want to modify them all to=20
> > use the new driver. So the strata driver is a new packets along side=20
> > the old one. For the SST driver i have modified all targets that use=20
> > it. That was easier since only the e7t and the aim711 use this driver.
> >=20
> > I've attached a hardware dependent driver for our platform which makes
>
> > use of the sst and strata device. This could be used as an example as=20
> > to how to modify the hardware dependent part of a flash driver to use=20
> > the new code.
> >=20
> > One thing to watch out for is that the hardware dependent driver has=20
> > to go into libextras.a. If you forget this the driver will be thrown=20
> > away at link time...
> >=20
> > And lastly a warning to testers.... There could be bugs which destroy=20
> > your boot loader etc. Make sure you can restore the device with jtag=20
> > before playing with this code.
> >=20
> > Thanks
> > Andrew
> >=20
> > --
> > Before posting, please read the FAQ:=20
> > http://ecos.sourceware.org/fom/ecos
> > and search the list archive:=20
> > http://ecos.sourceware.org/ml/ecos-discuss
> >=20
> >=20
> > _____________________
> > Confidentiality note: This email and any attachments may contain
> private, confidential, and privileged material for the sole use of the
> intended recipient. Any unauthorized review, use, disclosure or
> distribution is strictly prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and destroy all
> copies of the original message.
> >=20
>
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-09 12:58 Doyle, Patrick
0 siblings, 0 replies; 27+ messages in thread
From: Doyle, Patrick @ 2004-08-09 12:58 UTC (permalink / raw)
To: 'David Marqvar (DAM)', Andrew Lunn; +Cc: ecos-discuss
Not having thought about it too much (at all), I have been planning on
writnig a CFI driver as well, based on the hacks I made to the strata driver
that I published several months ago. I hadn't thought about making it
support both Intel and AMD algorithms, since I only have Intel-algorithm
based parts to play with. We should coordinate, however, so we don't
duplicate work.
--wpd
> -----Original Message-----
> From: David Marqvar (DAM) [mailto:DAM@tt.dk]
> Sent: Friday, August 06, 2004 9:45 AM
> To: Andrew Lunn
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Flash infrastructure rework
>
>
> Sounds great.
>
> I've been wanting to make a general flash driver based on CFI which
> would support the two main programming algorithm's around: Intel
> (Strata) and AMD (don't know if it's really these companies that
> invented the algorithm, anyway I think you know what I mean).
> Is SST yet
> another programming algorithm or == ADM?
>
> Though CFI I can read the physical layout of the flash and the
> programming algorithm to use.
> This way the flash-driver could be generel, not limited to one or more
> certian devices.
>
> Do you see any show-stoppers for creating such driver?
>
> /David
>
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of
> Andrew Lunn
> Sent: 6. august 2004 15:23
> To: eCos Disuss
> Subject: Re: [ECOS] Flash infrastructure rework
>
> > I put the code on a branch so that a few people can test it
> and so we
> > get a better idea how stable the code is with hardware i don't have
> > access to.
>
> This is what i decided to do. In cvs there is now a branch called
> flash_v2. If you checkout/update to that branch you will get my new
> flash code. There is also new generic drivers for SST and
> Strata. Since
> so many targets use strata i did not want to modify them all
> to use the
> new driver. So the strata driver is a new packets along side the old
> one. For the SST driver i have modified all targets that use it. That
> was easier since only the e7t and the aim711 use this driver.
>
> I've attached a hardware dependent driver for our platform which makes
> use of the sst and strata device. This could be used as an
> example as to
> how to modify the hardware dependent part of a flash driver to use the
> new code.
>
> One thing to watch out for is that the hardware dependent
> driver has to
> go into libextras.a. If you forget this the driver will be thrown away
> at link time...
>
> And lastly a warning to testers.... There could be bugs which destroy
> your boot loader etc. Make sure you can restore the device with jtag
> before playing with this code.
>
> Thanks
> Andrew
>
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list
> archive: http://ecos.sourceware.org/ml/ecos-discuss
>
Patrick Doyle
DSP Design Engineer
(603) 546-2179
This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above. If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited. If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies. Thank you for your
cooperation.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-09 8:47 David Marqvar (DAM)
2004-08-10 2:33 ` Vivek Kumar
0 siblings, 1 reply; 27+ messages in thread
From: David Marqvar (DAM) @ 2004-08-09 8:47 UTC (permalink / raw)
To: Vivek Kumar, Andrew Lunn; +Cc: ecos-discuss, Vivek.Kumar
Hi,
This is really great to hear.
Vivek, please let me know if I can be to any help for you (testing,
porting, .cdl-files, etc., etc.)
I'm really looking out for CFI support. The chip-mess I know :-|
Best regards,
David Marqvar
-----Original Message-----
From: Vivek Kumar [mailto:vivek@employees.org]
Sent: 6. august 2004 19:19
To: David Marqvar (DAM); Andrew Lunn
Cc: ecos-discuss@ecos.sourceware.org; Vivek.Kumar@zeevo.com
Subject: Re: [ECOS] Flash infrastructure rework
Hi,
The exact cfi specs can be downloaded from www.jedec.com (registration
is probably required). AMD and Intel would cover all bases. SST has its
own extensions (so does Mitsubishi) but they are almost similar to the
AMD type.
The implementation is really simple, but the the real pain was to take
care of is the 'diversions' which the vendors take and not tell you.
The things I remember offhand are
- SST flash lists its sectors twice, so if you add all of them up
you get double the flash size.
- SST also needs some extended commands to enter the CFI mode.
- AMD extensions V1.1 and below do not tell whether its a top boot
flash or a bottom boot and the sectors are sometime stored as
smallest first or the largest first. We had to read the Flash ID
to determine what to do with the sectors.
and on and on and on
At one point we were thinking why the hell did we try cfi? But having
one that I can say for sure its really good we did that. Marketing now
does not now come to me every other day asking if I can add driver
support for xxx flash, which most of the time meant reading the spec
adding another table and testing it. Whew..
-Vivek
http://www.vivekkumar.net
> -----Original Message-----
> From: David Marqvar (DAM) [mailto:DAM@tt.dk]
> Sent: Friday, August 06, 2004 6:45 AM
> To: Andrew Lunn
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Flash infrastructure rework
>
>
> Sounds great.
>
> I've been wanting to make a general flash driver based on CFI which
> would support the two main programming algorithm's around: Intel
> (Strata) and AMD (don't know if it's really these companies that
> invented the algorithm, anyway I think you know what I mean). Is SST
> yet another programming algorithm or == ADM?
>
> Though CFI I can read the physical layout of the flash and the
> programming algorithm to use.
> This way the flash-driver could be generel, not limited to one or more
> certian devices.
>
> Do you see any show-stoppers for creating such driver?
>
> /David
>
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew
> Lunn
> Sent: 6. august 2004 15:23
> To: eCos Disuss
> Subject: Re: [ECOS] Flash infrastructure rework
>
> > I put the code on a branch so that a few people can test it and so
> > we get a better idea how stable the code is with hardware i don't
> > have access to.
>
> This is what i decided to do. In cvs there is now a branch called
> flash_v2. If you checkout/update to that branch you will get my new
> flash code. There is also new generic drivers for SST and Strata.
> Since so many targets use strata i did not want to modify them all to
> use the new driver. So the strata driver is a new packets along side
> the old one. For the SST driver i have modified all targets that use
> it. That was easier since only the e7t and the aim711 use this driver.
>
> I've attached a hardware dependent driver for our platform which makes
> use of the sst and strata device. This could be used as an example as
> to how to modify the hardware dependent part of a flash driver to use
> the new code.
>
> One thing to watch out for is that the hardware dependent driver has
> to go into libextras.a. If you forget this the driver will be thrown
> away at link time...
>
> And lastly a warning to testers.... There could be bugs which destroy
> your boot loader etc. Make sure you can restore the device with jtag
> before playing with this code.
>
> Thanks
> Andrew
>
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
>
>
> _____________________
> Confidentiality note: This email and any attachments may contain
private, confidential, and privileged material for the sole use of the
intended recipient. Any unauthorized review, use, disclosure or
distribution is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-06 16:40 ` Vivek Kumar
@ 2004-08-06 18:06 ` Gary Thomas
0 siblings, 0 replies; 27+ messages in thread
From: Gary Thomas @ 2004-08-06 18:06 UTC (permalink / raw)
To: Vivek Kumar; +Cc: eCos Discussion
On Fri, 2004-08-06 at 10:40, Vivek Kumar wrote:
> Hi,
>
> Some time back I wrote a generic cfi flash driver for our proprietary
> operating
> system. Since we were thinking of making a possible port to the eCOS from
> our
> proprietary operating system I made the api so that they could be easily
> used
> with ecos operating system. I was planning to clean up the API's and post it
> online.
>
> We have tested the flash drivers on following flashes and they seems quite
> stable.
>
> - Alliance
> - AMD
> - Atmel
> - CSR/Fujitsu Flashes
> - EON
> - MXIC
> - SST
>
>
> Being new to eCOS Iam not really sure about the exact procedure for
> submitting a
> patch, But I'll be glad to share my code if you are interested.
>
We'd love to see this. Please review these documents which describe
the procedures and policies for accepting contributions:
http://ecos.sourceware.org/assign.html
http://ecos.sourceware.org/patches.html
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
[not found] <0175EEA85416D811893E009027D0F5D79389D4@MAILHOST>
@ 2004-08-06 17:19 ` Vivek Kumar
0 siblings, 0 replies; 27+ messages in thread
From: Vivek Kumar @ 2004-08-06 17:19 UTC (permalink / raw)
To: David Marqvar, Andrew Lunn; +Cc: ecos-discuss, Vivek.Kumar
Hi,
The exact cfi specs can be downloaded from www.jedec.com (registration
is probably required). AMD and Intel would cover all bases. SST has its
own extensions (so does Mitsubishi) but they are almost similar to the
AMD type.
The implementation is really simple, but the the real pain was to take
care of is the 'diversions' which the vendors take and not tell you.
The things I remember offhand are
- SST flash lists its sectors twice, so if you add all of them up
you get double the flash size.
- SST also needs some extended commands to enter the CFI mode.
- AMD extensions V1.1 and below do not tell whether its a top boot
flash or a bottom boot and the sectors are sometime stored as
smallest first or the largest first. We had to read the Flash ID
to determine what to do with the sectors.
and on and on and on
At one point we were thinking why the hell did we try cfi? But having
one that I can say for sure its really good we did that. Marketing now
does not now come to me every other day asking if I can add driver
support for xxx flash, which most of the time meant reading the spec
adding another table and testing it. Whew..
-Vivek
http://www.vivekkumar.net
> -----Original Message-----
> From: David Marqvar (DAM) [mailto:DAM@tt.dk]
> Sent: Friday, August 06, 2004 6:45 AM
> To: Andrew Lunn
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Flash infrastructure rework
>
>
> Sounds great.
>
> I've been wanting to make a general flash driver based on CFI which
> would support the two main programming algorithm's around: Intel
> (Strata) and AMD (don't know if it's really these companies that
> invented the algorithm, anyway I think you know what I mean). Is SST yet
> another programming algorithm or == ADM?
>
> Though CFI I can read the physical layout of the flash and the
> programming algorithm to use.
> This way the flash-driver could be generel, not limited to one or more
> certian devices.
>
> Do you see any show-stoppers for creating such driver?
>
> /David
>
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
> Sent: 6. august 2004 15:23
> To: eCos Disuss
> Subject: Re: [ECOS] Flash infrastructure rework
>
> > I put the code on a branch so that a few people can test it and so we
> > get a better idea how stable the code is with hardware i don't have
> > access to.
>
> This is what i decided to do. In cvs there is now a branch called
> flash_v2. If you checkout/update to that branch you will get my new
> flash code. There is also new generic drivers for SST and Strata. Since
> so many targets use strata i did not want to modify them all to use the
> new driver. So the strata driver is a new packets along side the old
> one. For the SST driver i have modified all targets that use it. That
> was easier since only the e7t and the aim711 use this driver.
>
> I've attached a hardware dependent driver for our platform which makes
> use of the sst and strata device. This could be used as an example as to
> how to modify the hardware dependent part of a flash driver to use the
> new code.
>
> One thing to watch out for is that the hardware dependent driver has to
> go into libextras.a. If you forget this the driver will be thrown away
> at link time...
>
> And lastly a warning to testers.... There could be bugs which destroy
> your boot loader etc. Make sure you can restore the device with jtag
> before playing with this code.
>
> Thanks
> Andrew
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
> _____________________
> Confidentiality note: This email and any attachments may contain private, confidential, and privileged material for the sole use of the intended recipient. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
[not found] <0175EEA85416D811893E009027D0F5D79389D3@MAILHOST>
@ 2004-08-06 16:40 ` Vivek Kumar
2004-08-06 18:06 ` Gary Thomas
0 siblings, 1 reply; 27+ messages in thread
From: Vivek Kumar @ 2004-08-06 16:40 UTC (permalink / raw)
To: ecos-discuss
Hi,
Some time back I wrote a generic cfi flash driver for our proprietary
operating
system. Since we were thinking of making a possible port to the eCOS from
our
proprietary operating system I made the api so that they could be easily
used
with ecos operating system. I was planning to clean up the API's and post it
online.
We have tested the flash drivers on following flashes and they seems quite
stable.
- Alliance
- AMD
- Atmel
- CSR/Fujitsu Flashes
- EON
- MXIC
- SST
Being new to eCOS Iam not really sure about the exact procedure for
submitting a
patch, But I'll be glad to share my code if you are interested.
-vivek
http://www.vivekkumar.net
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, August 04, 2004 1:12 PM
> To: Doyle, Patrick
> Cc: eCos Disuss
> Subject: Re: [ECOS] Flash infrastructure rework
>
>
> On Wed, Aug 04, 2004 at 04:06:49PM -0400, Doyle, Patrick wrote:
> > > > Regardless, I might want to beta test it for you -- I have
> > > > been working with a board that has two different FLASH
> > > > devices on it. I'll have to give that one a little think.
> > >
> > > That would be great. That is exactly the sort of thing
> this new code
> > > is for.
> > >
> > > What are the two devices? I have drivers for strata and sst.
> > >
> > One is ths strata, the other (looking at ecos.db to refresh
> my memory) is
> > the AMD_AM29XXXXX driver.
>
> OK. Its actually quite easy to convert to the new driver API, so it
> should not take too long before you have a working system.
>
> > Plus, I want to rework my strata flash patches
> > that I posted some time ago (and have not yet been
> accepted, because they
> > were so extensive) to be an entirely new flash device
> driver, a cfi_flash
> > driver. Perhaps you have already accomplished that for me
> in your new
> > strata driver.
>
> No, we have just ported the existing strata driver to the new API. I
> was thinking about writing a cfi_flash driver, but i want to get my
> current code committed first. Thats also why i not looked at your
> strata patches.
>
> > Of course, now that you mention strata, I could probably
> beta test your
> > patch on our two boards as well.
>
> Great. Do you have jtag hardware to recover them if it all goes wrong?
>
> Andrew
>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-06 13:43 David Marqvar (DAM)
@ 2004-08-06 14:08 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-08-06 14:08 UTC (permalink / raw)
To: David Marqvar (DAM); +Cc: ecos-discuss
On Fri, Aug 06, 2004 at 03:45:14PM +0200, David Marqvar (DAM) wrote:
> Sounds great.
>
> I've been wanting to make a general flash driver based on CFI which
> would support the two main programming algorithm's around: Intel
> (Strata) and AMD (don't know if it's really these companies that
> invented the algorithm, anyway I think you know what I mean).
You can find the specification at
www.amd.com/us-en/assets/content_type/ DownloadableAssets/cfi_r20.pdf
Promoters of the specification are :Intel, AMD, Fujitsu and Sharp,
plus i bet others implement it.
> Is SST yet another programming algorithm or == ADM?
The SST 39VF160 supports CFI.
> Though CFI I can read the physical layout of the flash and the
> programming algorithm to use. This way the flash-driver could be
> generel, not limited to one or more certian devices. Do you see any
> show-stoppers for creating such driver?
None at the moment. You are the third person interested in doing this
implementation. I suggest that before you start you drop an email to
the list and see what help you can get.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-06 13:43 David Marqvar (DAM)
2004-08-06 14:08 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: David Marqvar (DAM) @ 2004-08-06 13:43 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-discuss
Sounds great.
I've been wanting to make a general flash driver based on CFI which
would support the two main programming algorithm's around: Intel
(Strata) and AMD (don't know if it's really these companies that
invented the algorithm, anyway I think you know what I mean). Is SST yet
another programming algorithm or == ADM?
Though CFI I can read the physical layout of the flash and the
programming algorithm to use.
This way the flash-driver could be generel, not limited to one or more
certian devices.
Do you see any show-stoppers for creating such driver?
/David
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: 6. august 2004 15:23
To: eCos Disuss
Subject: Re: [ECOS] Flash infrastructure rework
> I put the code on a branch so that a few people can test it and so we
> get a better idea how stable the code is with hardware i don't have
> access to.
This is what i decided to do. In cvs there is now a branch called
flash_v2. If you checkout/update to that branch you will get my new
flash code. There is also new generic drivers for SST and Strata. Since
so many targets use strata i did not want to modify them all to use the
new driver. So the strata driver is a new packets along side the old
one. For the SST driver i have modified all targets that use it. That
was easier since only the e7t and the aim711 use this driver.
I've attached a hardware dependent driver for our platform which makes
use of the sst and strata device. This could be used as an example as to
how to modify the hardware dependent part of a flash driver to use the
new code.
One thing to watch out for is that the hardware dependent driver has to
go into libextras.a. If you forget this the driver will be thrown away
at link time...
And lastly a warning to testers.... There could be bugs which destroy
your boot loader etc. Make sure you can restore the device with jtag
before playing with this code.
Thanks
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-04 20:23 Doyle, Patrick
0 siblings, 0 replies; 27+ messages in thread
From: Doyle, Patrick @ 2004-08-04 20:23 UTC (permalink / raw)
To: 'Andrew Lunn'; +Cc: 'eCos Disuss'
> Hmmm, one small worry -- I'm not actually using Intel flash,
> I'm using the Micro equivalent, which may, or may not, report
Of course I meant "Micron" here.
Patrick Doyle
DSP Design Engineer
(603) 546-2179
This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above. If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited. If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies. Thank you for your
cooperation.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-04 20:17 Doyle, Patrick
0 siblings, 0 replies; 27+ messages in thread
From: Doyle, Patrick @ 2004-08-04 20:17 UTC (permalink / raw)
To: 'Andrew Lunn', Doyle, Patrick; +Cc: eCos Disuss
> No, we have just ported the existing strata driver to the new API. I
> was thinking about writing a cfi_flash driver, but i want to get my
> current code committed first. Thats also why i not looked at your
> strata patches.
>
We should definitely talk -- I wouldn't want one of us to duplicate work
that the other is doing, nor would I want one of us to think "I'll just wait
until he does it", and later find out that he never got around to it. But,
I'm glad to hear your thinking along the same lines.
> > Of course, now that you mention strata, I could probably
> beta test your
> > patch on our two boards as well.
>
> Great. Do you have jtag hardware to recover them if it all goes wrong?
Yup, no worries.
Hmmm, one small worry -- I'm not actually using Intel flash, I'm using the
Micro equivalent, which may, or may not, report the Intel ID code. I've
never worried about it since I've been using my CFI support. Well, the
worst that will happen is that it won't be recognized at boot.
--wpd
Patrick Doyle
DSP Design Engineer
(603) 546-2179
This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above. If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited. If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies. Thank you for your
cooperation.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-04 20:06 Doyle, Patrick
@ 2004-08-04 20:12 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-08-04 20:12 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: eCos Disuss
On Wed, Aug 04, 2004 at 04:06:49PM -0400, Doyle, Patrick wrote:
> > > Regardless, I might want to beta test it for you -- I have
> > > been working with a board that has two different FLASH
> > > devices on it. I'll have to give that one a little think.
> >
> > That would be great. That is exactly the sort of thing this new code
> > is for.
> >
> > What are the two devices? I have drivers for strata and sst.
> >
> One is ths strata, the other (looking at ecos.db to refresh my memory) is
> the AMD_AM29XXXXX driver.
OK. Its actually quite easy to convert to the new driver API, so it
should not take too long before you have a working system.
> Plus, I want to rework my strata flash patches
> that I posted some time ago (and have not yet been accepted, because they
> were so extensive) to be an entirely new flash device driver, a cfi_flash
> driver. Perhaps you have already accomplished that for me in your new
> strata driver.
No, we have just ported the existing strata driver to the new API. I
was thinking about writing a cfi_flash driver, but i want to get my
current code committed first. Thats also why i not looked at your
strata patches.
> Of course, now that you mention strata, I could probably beta test your
> patch on our two boards as well.
Great. Do you have jtag hardware to recover them if it all goes wrong?
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-04 20:06 Doyle, Patrick
2004-08-04 20:12 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Doyle, Patrick @ 2004-08-04 20:06 UTC (permalink / raw)
To: 'Andrew Lunn'; +Cc: eCos Disuss
> > Regardless, I might want to beta test it for you -- I have
> > been working with a board that has two different FLASH
> > devices on it. I'll have to give that one a little think.
>
> That would be great. That is exactly the sort of thing this new code
> is for.
>
> What are the two devices? I have drivers for strata and sst.
>
One is ths strata, the other (looking at ecos.db to refresh my memory) is
the AMD_AM29XXXXX driver. Plus, I want to rework my strata flash patches
that I posted some time ago (and have not yet been accepted, because they
were so extensive) to be an entirely new flash device driver, a cfi_flash
driver. Perhaps you have already accomplished that for me in your new
strata driver.
Of course, now that you mention strata, I could probably beta test your
patch on our two boards as well.
--wpd
Patrick Doyle
DSP Design Engineer
(603) 546-2179
This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above. If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited. If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies. Thank you for your
cooperation.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [ECOS] Flash infrastructure rework
2004-08-04 19:49 Doyle, Patrick
@ 2004-08-04 19:55 ` Andrew Lunn
0 siblings, 0 replies; 27+ messages in thread
From: Andrew Lunn @ 2004-08-04 19:55 UTC (permalink / raw)
To: Doyle, Patrick; +Cc: 'Andrew Lunn', eCos Disuss
On Wed, Aug 04, 2004 at 03:49:24PM -0400, Doyle, Patrick wrote:
> Is there the possibility of adding it as its own CYGPKG_NEW_FLASH package?
I suppose so, but what about all the changes to redboot and there is
one minor change to jffs2? It makes more sense to replace the existing
package and patch everything else.
> Regardless, I might want to beta test it for you -- I have been working with
> a board that has two different FLASH devices on it. I'll have to give that
> one a little think.
That would be great. That is exactly the sort of thing this new code
is for.
What are the two devices? I have drivers for strata and sst.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: [ECOS] Flash infrastructure rework
@ 2004-08-04 19:49 Doyle, Patrick
2004-08-04 19:55 ` Andrew Lunn
0 siblings, 1 reply; 27+ messages in thread
From: Doyle, Patrick @ 2004-08-04 19:49 UTC (permalink / raw)
To: 'Andrew Lunn', eCos Disuss
Is there the possibility of adding it as its own CYGPKG_NEW_FLASH package?
Regardless, I might want to beta test it for you -- I have been working with
a board that has two different FLASH devices on it. I'll have to give that
one a little think.
--wpd
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Wednesday, August 04, 2004 3:14 PM
> To: eCos Disuss
> Subject: Re: [ECOS] Flash infrastructure rework
>
>
> > However in the background i took a step back and overhauled
> the whole
> > flash infrastructure in what i hope is a clean and
> consistent API with
> > all the features required:
> >
> > Multiple device drivers at the same time
> > Multiple instantiations of the same driver
> > Probing to detect what is actually on the board
> > Support for boot block devices which have different
> size blocks
> > Thread safe when used with the kernel
> > Does not pollute the name space
> > Optional backward compatible with old drivers
> > Optional backward compatible with old API
> > Able to support multiple JFFS2 filesystems
> > Redboot to be able to access multiple devices
> > Documentation!
>
> This is about ready to go live. The question is how do we do
> this. There is a danger there are bugs left which could brick
> boards. ie destroy the bootloader and if you don't have jtag there is
> no way to recover the hardware.
>
> There are a few options:
>
> I commit it and let people test it. If there are major problems we
> undo the change while we debug the problem.
>
> I put the code on a branch so that a few people can test it and so we
> get a better idea how stable the code is with hardware i don't have
> access to.
>
> I can send patches to people who would like to test.
>
> Suggestions welcome.
>
> Andrew
>
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list
> archive: http://ecos.sourceware.org/ml/ecos-discuss
>
Patrick Doyle
DSP Design Engineer
(603) 546-2179
This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above. If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited. If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies. Thank you for your
cooperation.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2004-09-08 12:25 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-16 13:39 [ECOS] Flash infrastructure rework Andrew Lunn
2004-07-19 14:18 ` Ian Campbell
2004-07-30 10:43 ` Andrew Lunn
2004-08-04 12:54 ` Jani Monoses
2004-08-04 19:06 ` Andrew Lunn
2004-08-04 19:13 ` Andrew Lunn
2004-08-06 13:22 ` Andrew Lunn
2004-08-19 15:21 ` Bart Veer
2004-08-19 16:38 ` Andrew Lunn
2004-08-20 14:44 ` Bart Veer
2004-08-20 16:37 ` Andrew Lunn
2004-08-22 13:02 ` Gary Thomas
2004-08-04 19:49 Doyle, Patrick
2004-08-04 19:55 ` Andrew Lunn
2004-08-04 20:06 Doyle, Patrick
2004-08-04 20:12 ` Andrew Lunn
2004-08-04 20:17 Doyle, Patrick
2004-08-04 20:23 Doyle, Patrick
2004-08-06 13:43 David Marqvar (DAM)
2004-08-06 14:08 ` Andrew Lunn
[not found] <0175EEA85416D811893E009027D0F5D79389D3@MAILHOST>
2004-08-06 16:40 ` Vivek Kumar
2004-08-06 18:06 ` Gary Thomas
[not found] <0175EEA85416D811893E009027D0F5D79389D4@MAILHOST>
2004-08-06 17:19 ` Vivek Kumar
2004-08-09 8:47 David Marqvar (DAM)
2004-08-10 2:33 ` Vivek Kumar
2004-08-09 12:58 Doyle, Patrick
2004-09-08 12:25 Savin Zlobec
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).