Hi, On 20 November 2015 at 03:13, Valentin Longchamp <valentin.longch...@keymile.com> wrote: > On 19/11/2015 17:57, Jagan Teki wrote: >> On 13 November 2015 at 18:55, Valentin Longchamp >> <valentin.longch...@keymile.com> wrote: >>> The release command is the pendant of the probe command. This command >>> allows to call spi_flash_free from the command line. This may be >>> necessary for some boards where sf probe does change the state of the >>> hardware (like with some pin multiplexing changes for instance). >> >> So you want to change the state of pin multiplexing on your board with >> connected slave devices example: spi nor flash is it? what exactly the >> need of releasing? why can't we use pin multiplexing changes like >> selecting or deselecting particular lines through driver or from board >> files itself. > > That's our use case yes. Let me explain you it again in detail. Some of the > signals used to access the NAND Flash and the SPI NOR are shared. At reset, > they > are available for the SPI NOR, since u-boot is in there and the CPU then > accesses it. > > In an usual boot sequence, the SPI NOR is accessed first (copying u-boot to > the > RAM, reading out the environment) and so the pins are configured in hardware > at > boot time for accessing the SPI NOR. After that, they are configured to access > the NAND where the kernel and filesystem are stored to boot Linux thanks to > env_relocate_spec() calling spi_flash_free() on exit in conjunction with [1] > > Now in the case where the boot sequence is interrupted and some accesses are > done to the SPI NOR, the pins are changed again to SPI NOR to perform these > accesses. But we have to make sure that the pins are configured back to NAND > by > calling spi_flash_free() after these accesses and that's why I introduced the > release() function. > > In our case, there are 2 types of such accesses: > - environment variables write: this is the first patch of the series. It > simply > adds calls to spi_flash_free() at function exit no only in env_relocate_spec() > but also in saveenv() so that the behavior here is coherent for the whole > env_sf > file (spi_flash_probe() at function start, spi_flash_free() at function exit). > - updating u-boot: this is solved for us with the last 2 patches of the > series. > The first one just adds a sf release command that does the opposite/cleanup to > sf probe and the second patch just calls this command in our scripts where > u-boot is updated/the SPI NOR is written. > > We are *indeed* using pin multiplexing changes, in our case, they are > implemented in the spi controller driver: drivers/spi/kirkwood_spi.c. To be > very > specific, in our case this sf release command allows to explicitely call > spi_flash_free() which calls spi_free_slave(), which in our case > (kirkwood_spi.c) sets the pins back to their previous configuration.
Does your board use driver model from SPI and SPI flash? If not I think that should be the first step. Regards, Simon [snip] _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
