Rick
On May 19, 2009, at 3:54 AM, Raúl Sánchez Siles wrote:
Hello:This is my first try to implement the x16_as_x8 flash bank option. It is working for me as I would expect flash to work, but please consider thispatchset as work in progress since it may still has some flaws.Al patches touch just src/flash/cfi.c file and should apply in this order totrunk. The patchset consists of 4 patches, whose interest areas I explain and comment below: 01-x16_as_x8-consolidate_addresses· Manufacturer and device id retrieval in cfi_probe function weren't usingthe generic flash_address. Use it there. 02-x16_as_x8-command_address· Creation of a command_address function intended as flash addresses arranger depending on the x16_as_x8 parameter existence or not. This is basically an override of flash_address function, only that takes into account the x16_as_x8parameter. The other options for this functionality would be adding anadditional parameter to flash_address function or, if it is shown that it is an equivalent of flash_address, include x16_as_x8 functionality into flash_address.03-x16_as_x8-command_address-subst· Substitution of flash_address function for command_address function, except on code specific to intel. I have just focused on spansion flashes and I hadn't review intel flash specifications, so I decided to be conservative at first. Maybe someone can tell if the command_address function is also valid for intel chips. If so this patch could be grown to include those or eventually includethe x16_as_x8 functionality into flash_address not needing this one. 04-x16_as_x8-multibyte_read· cfi_query_u16 and cfi_query_u32 function uses multibyte accesses, this is 2 or 4 byte read. This will fail in the x16_as_x8 case since this would lead reading, e.g.: addresses 0x0 and 0x1 instead of 0x0 and 0x2 in the 16bit case.Do a byte by byte read in the x16_as_x8 case. Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
