Hello Wolfgang,
Wolfgang Denk wrote:
They are not "outdated". It's just a different (and incompatible) implementation. If you can come up with a patch tp cleanup please do so.
I decided to do that (and it was pretty easy to do), but now I have even more questions...
The major issue is the way chip selects are controlled. Currently, do_spi() function that implements "sspi" command calls spi_xfer() this way:
spi_xfer(spi_chipsel[device], bitlen, dout, din)
where spi_chipsel is a global array of pointers to functions that are supposed to assert/de-assert chip selects for the specified target(s).
I looked at the code for the boards that use this mechanism, and I can see the array statically initialized, like (in board/sacsng/sacsng.c):
/* * The SPI command uses this table of functions for controlling the SPI * chip selects: it calls the appropriate function to control the SPI * chip selects. */ spi_chipsel_type spi_chipsel[] = { spi_adc_chipsel, spi_dac_chipsel }; int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
My question is: where these addresses are relocated? My understanding is that relocation for this type of data should be done manually, but nowhere in the code can I see it. Not for a single board. That means that if people got lucky, they execute the copy of the code from the FLASH, not the relocated one.
Is that OK? I also noticed the same mechanism being used in the FPGA-related code.
And another question. The current implementation(s) of the "eeprom" command assume that there is only 1 SPI device and do not bothr themselves with the chip selects at all. That means, that if you try to execute "eeprom" command after you executed "sspi" (that will de-assert the chip-select at the end or can choose a different one), the results will be unpredictable. I have no problem modifying "eeprom" command for my board, but this will force other people to do modifications as well, so I am not sure what should we do.
Thanks, Vladimir