Raúl Sánchez Siles wrote: > Hello all: > > I have noticed some issues on CFI flash driver related to chip and bus > width > affecting read and writes. > > The system I'm dealing with is based on a Vitesse switch chip which embeds > an ARM926ejs processor. It additionally provides RAM and flash controller. In > this case we are using an spansion S29GL128 16MB flash chip, using a 8bit > width > data bus layout, so on each read/write cycle we can only retrieve 1byte at > once. The flash chip data bus width is 16bit. > > I declare the flash like this: > > flash bank cfi 0x80000000 0x1000000 1 2 0 > You mean you have *two* of those flash chips, each connected to one 8-bit half of the 16-bit bus? > => 1st problem (writing): > > This clashes somehow with the current CFI driver operations as designed > now. > I have discovered that when the connected flash is 8 bit, only byte writes > will > be performed correctly so even this call: > > target->type->write_memory(target, address, 4, 1, value_buf) > > will succeed, the operation isn't carried out correctly. > > I got to workaround the problem for just cfi flash probe. See attached cfi- > write-width.diff What I do there is using chip width instead of bus width for > each write. This works in my case but I'm not sure it's the general way to go. > > This effect expands to larger write operations, for instance in > target_write_u32 (cfi.c:1220) you would need to repeat a byte write operation > 4 > times. > > => 2nd problem (reading) > > But writing is not the only problem. In reading, when chip width is 8bit > whereas bus width is 16bit, single byte operation could be acceptable, > whereas this is no longer valid for halfword or word operations, 16bit and > 32bit, respectively. When you call, for example cfi_query_u16, expected > return > is 0xAABB, where 0xAA is the MSB and 0xBB is the LSB. Current return is > always > 0xBBBB. Similar problem for cfi_query_u32 > > The solution is iterating the necessary times for a 1byte read and then > aggregate each iteration result properly. See attached cfi-read_iteration.diff > In general, I don't think this is the right approach. When you have multiple chips in parallel to make up the data bus width (like 2 8-bit flashs on a 16-bit bus), you can only expect 16-bit read/write operations to work. For one, some CPUs don't have separate write enables for the separate 8-bit parts of the bus, and even if they do, a read may always assert all byte enables and discard the "unused" parts.
I think the only thing that works in general is to only make bus-width sized accesses - ie. 16-bit in case of two 8-bit flashs, which means you have to read/write both chips in parallel. > I guess the x16_as_x8 option defined but not used should be aimed at > handling > this, but this is unimplemented currently. > Um - no. The x16_as_x8 option is used for 16-bit flashes that can be used with an 8-bit data bus. The reason for that option is that in that mode, the "magic" address values used for commands is shifted 1 bit against what is used on "real" 8-bit flashs. The option should only tell that a 16-bit flash chip is connected to a 8-bit bus - having multiple such chips in parallel must be handled by the chip/bus geometry handling. You might have a look at the CFI code in u-boot, which I *think* does handle this situation correct, however, I have no board with such a flash layout, so I can't really tell. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
