From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valentin Longchamp Date: Mon, 23 Nov 2015 10:19:29 +0100 Subject: [U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command In-Reply-To: References: <1447421155-13084-1-git-send-email-valentin.longchamp@keymile.com> <1447421155-13084-2-git-send-email-valentin.longchamp@keymile.com> <564EF24A.2010506@keymile.com> Message-ID: <5652DA21.3090800@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, On 20/11/2015 18:19, Simon Glass wrote: > Hi, > > On 20 November 2015 at 03:13, Valentin Longchamp > wrote: >> On 19/11/2015 17:57, Jagan Teki wrote: >>> On 13 November 2015 at 18:55, Valentin Longchamp >>> 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. > No we don't. Could you please elaborate on how this would cover this use case and should be the first step ? I am open to other ways to cover this use case of ours, especially since this was done more than 2 years ago and u-boot has changed since then. However I don't see the direct link between the driver model and how it would allow to make sure spi_flash_free() is called in our u-boot env scripts. Valentin