Antonio Borneo wrote: > >> I'm not thrilled about having this information local in the > >> spearsmi > > > > Like generic SPI and SPI-flash layers. The flash > > support shouldn't be SPEAr-specific in the least. > > Understand your comments. > I agree that the table could be shared between SPEAr SMI and a generic > SPI or SPI-flash framework. > But I think this could be the only common part. > > AFAIK, SPI flash is not accessible in CPU memory space directly, but > requires the driver to copy to RAM the flash content. This is stated > also in OpenOCD documentation, chapter 12. > > But, SMI controller is not a generic SPI interface (some devices in > SPEAr family also provide a separate SPI controller, keeping SMI for > flash only). > SMI is a dedicated HW accelerator that hides the SPI protocol and maps > on-the-fly the content of the SPI flash in the CPU memory space.
That is true.. But SPI is still SPI, and maybe some code can be shared. Likewise the flash chips in the table may be relevant elsewhere in the code, so would be better to have their information outside spearsmi, along with enough knowledge to determine if they can be used by spearsmi or not. > The SMI has some limitation while choosing a flash device. The > documentation reports the list of mandatory SPI commands codes that > the flash have to support, since such values are hardcoded in the > controller and cannot be changed. Does the SMI have a "manual" command mode? What you describe is common with SPI flash controllers, but there can also be a generic mode where software can specify one command at a time to execute on SPI? //Peter _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
