From: Valentin Longchamp <valentin.longchamp@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command
Date: Fri, 20 Nov 2015 11:13:30 +0100 [thread overview]
Message-ID: <564EF24A.2010506@keymile.com> (raw)
In-Reply-To: <CAD6G_RQ65Y6P5YAoqqiRbsJxLTmuCbzhBsEGC-7n_dipU9WsUQ@mail.gmail.com>
On 19/11/2015 17:57, Jagan Teki wrote:
> On 13 November 2015 at 18:55, Valentin Longchamp
> <valentin.longchamp@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.
>
>>
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>> ---
>>
>> Changes in v3:
>> - Rebased on v2015.10
>>
>> Changes in v2:
>> - Rebased on v2014.10
>>
>> common/cmd_sf.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/common/cmd_sf.c b/common/cmd_sf.c
>> index ac7f5df..9c51dca 100644
>> --- a/common/cmd_sf.c
>> +++ b/common/cmd_sf.c
>> @@ -152,6 +152,14 @@ static int do_spi_flash_probe(int argc, char * const argv[])
>> return 0;
>> }
>>
>> +static int do_spi_flash_release(int argc, char * const argv[])
>> +{
>> + if (flash)
>> + spi_flash_free(flash);
>> + flash = NULL;
>> +
>> + return 0;
>> +}
>> /**
>> * Write a block of data to SPI flash, first checking if it is different from
>> * what is already there.
>> @@ -540,6 +548,8 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int argc,
>> ret = do_spi_flash_read_write(argc, argv);
>> else if (strcmp(cmd, "erase") == 0)
>> ret = do_spi_flash_erase(argc, argv);
>> + else if (strcmp(cmd, "release") == 0)
>> + ret = do_spi_flash_release(argc, argv);
>> #ifdef CONFIG_CMD_SF_TEST
>> else if (!strcmp(cmd, "test"))
>> ret = do_spi_flash_test(argc, argv);
>> @@ -579,5 +589,6 @@ U_BOOT_CMD(
>> "sf update addr offset|partition len - erase and write `len' bytes from memory\n"
>> " at `addr' to flash at `offset'\n"
>> " or to start of mtd `partition'\n"
>> + "sf release - release the current flash device\n"
>> SF_TEST_HELP
>> );
>> --
>> 1.8.3.1
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
next prev parent reply other threads:[~2015-11-20 10:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-13 13:25 [U-Boot] [PATCH v3 0/3] Serial Flash: call spi_flash_free more coherently Valentin Longchamp
2015-11-13 13:25 ` [U-Boot] [PATCH v3 1/3] cmd_sf: add 'release' command Valentin Longchamp
2015-11-19 16:57 ` Jagan Teki
2015-11-20 10:13 ` Valentin Longchamp [this message]
2015-11-20 17:19 ` Simon Glass
2015-11-23 9:19 ` Valentin Longchamp
2015-11-24 1:49 ` Simon Glass
2015-11-24 16:02 ` Valentin Longchamp
2015-11-25 3:52 ` Stefan Roese
2015-11-25 7:10 ` Valentin Longchamp
2015-11-13 13:25 ` [U-Boot] [PATCH v3 2/3] env_sf: generalize call to spi_flash_free after accesses Valentin Longchamp
2015-11-13 13:25 ` [U-Boot] [PATCH v3 3/3] km_arm: call 'sf release' in the newenv and update scripts Valentin Longchamp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564EF24A.2010506@keymile.com \
--to=valentin.longchamp@keymile.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox