From: Sascha Hauer <s.hauer@pengutronix.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] net/e1000: implement protect and unprotect for attached flash
Date: Tue, 28 Nov 2017 08:59:58 +0100 [thread overview]
Message-ID: <20171128075958.ldvyyw2x64d5gbxk@pengutronix.de> (raw)
In-Reply-To: <20171127213156.24187-1-u.kleine-koenig@pengutronix.de>
On Mon, Nov 27, 2017 at 10:31:56PM +0100, Uwe Kleine-König wrote:
> Some supported flash devices (e.g. SST25VF040) are write protected after
> power up. If the device holds a valid firmware image the i210 can handle
> that just fine. If however there is no firmware programmed, a procedure
> is needed to remove this protection before an image can be flashed.
>
> So implement the needed callbacks to make the commands protect and
> unprotect do the right thing.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Applied, thanks
Sascha
> ---
> Hello,
>
> this is the last patch (for now at least) for my quest to improve flashing a
> firmware image for i210. Up to today I was convinced I need to implement the
> spi bitbanging access mode for the flash. But after I got this implemented up
> to a working prototype I noticed that the already used flash burst mode can
> also access the status register which results in less and prettier code.
>
> Best regards
> Uwe
>
> drivers/net/e1000/e1000.h | 2 ++
> drivers/net/e1000/eeprom.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 72 insertions(+)
>
> diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
> index b49e1198160a..50d49118f5e4 100644
> --- a/drivers/net/e1000/e1000.h
> +++ b/drivers/net/e1000/e1000.h
> @@ -2110,6 +2110,8 @@ struct e1000_eeprom_info {
> #define E1000_FLSWCTL_CMD_WRITE 0b0001
> #define E1000_FLSWCTL_CMD_ERASE_SECTOR 0b0010
> #define E1000_FLSWCTL_CMD_ERASE_DEVICE 0b0011
> +#define E1000_FLSWCTL_CMD_RDSR 0b0100
> +#define E1000_FLSWCTL_CMD_WRSR 0b0101
> #define E1000_FLSWCTL_CMD(c) ((0b1111 & (c)) << 24)
>
> #define E1000_FLSWCTL_CMD_ADDR_MASK 0x0FFFFFFF
> diff --git a/drivers/net/e1000/eeprom.c b/drivers/net/e1000/eeprom.c
> index 0f1305c8499b..eeae318dcdfa 100644
> --- a/drivers/net/e1000/eeprom.c
> +++ b/drivers/net/e1000/eeprom.c
> @@ -3,6 +3,7 @@
> #include <malloc.h>
> #include <linux/math64.h>
> #include <linux/sizes.h>
> +#include <linux/mtd/spi-nor.h>
>
> #include "e1000.h"
>
> @@ -1410,6 +1411,73 @@ fail:
> return ret;
> }
>
> +static int e1000_mtd_sr_rmw(struct mtd_info *mtd, u8 mask, u8 val)
> +{
> + struct e1000_hw *hw = container_of(mtd, struct e1000_hw, mtd);
> + uint32_t flswdata;
> + int ret;
> +
> + ret = e1000_flash_mode_wait_for_idle(hw);
> + if (ret < 0)
> + return ret;
> +
> + e1000_write_reg(hw, E1000_FLSWCNT, 1);
> + e1000_flash_cmd(hw, E1000_FLSWCTL_CMD_RDSR, 0);
> +
> + ret = e1000_flash_mode_check_command_valid(hw);
> + if (ret < 0)
> + return -EIO;
> +
> + ret = e1000_poll_reg(hw, E1000_FLSWCTL,
> + E1000_FLSWCTL_DONE, E1000_FLSWCTL_DONE,
> + SECOND);
> + if (ret < 0) {
> + dev_err(hw->dev,
> + "Timeout waiting for FLSWCTL.DONE to be set (RDSR)\n");
> + return ret;
> + }
> +
> + flswdata = e1000_read_reg(hw, E1000_FLSWDATA);
> +
> + flswdata = (flswdata & ~mask) | val;
> +
> + e1000_write_reg(hw, E1000_FLSWCNT, 1);
> + e1000_flash_cmd(hw, E1000_FLSWCTL_CMD_WRSR, 0);
> +
> + ret = e1000_flash_mode_check_command_valid(hw);
> + if (ret < 0)
> + return -EIO;
> +
> + e1000_write_reg(hw, E1000_FLSWDATA, flswdata);
> +
> + ret = e1000_poll_reg(hw, E1000_FLSWCTL,
> + E1000_FLSWCTL_DONE, E1000_FLSWCTL_DONE,
> + SECOND);
> + if (ret < 0) {
> + dev_err(hw->dev,
> + "Timeout waiting for FLSWCTL.DONE to be set (WRSR)\n");
> + }
> +
> + return ret;
> +}
> +
> +/*
> + * The available spi nor devices are very different in how the block protection
> + * bits affect which sectors to be protected. So take the simple approach and
> + * only use BP[012] = b000 (unprotected) and BP[012] = b111 (protected).
> + */
> +#define SR_BPALL (SR_BP0 | SR_BP1 | SR_BP2)
> +
> +static int e1000_mtd_lock(struct mtd_info *mtd, loff_t ofs, size_t len)
> +{
> + return e1000_mtd_sr_rmw(mtd, SR_BPALL, SR_BPALL);
> +}
> +
> +static int e1000_mtd_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
> +{
> + return e1000_mtd_sr_rmw(mtd, SR_BPALL, 0x0);
> +}
> +
> int e1000_register_invm(struct e1000_hw *hw)
> {
> int ret;
> @@ -1521,6 +1589,8 @@ int e1000_register_eeprom(struct e1000_hw *hw)
> hw->mtd.read = e1000_mtd_read;
> hw->mtd.write = e1000_mtd_write;
> hw->mtd.erase = e1000_mtd_erase;
> + hw->mtd.lock = e1000_mtd_lock;
> + hw->mtd.unlock = e1000_mtd_unlock;
> hw->mtd.size = eeprom->word_size * 2;
> hw->mtd.writesize = 1;
> hw->mtd.subpage_sft = 0;
> --
> 2.11.0
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2017-11-28 8:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 21:31 Uwe Kleine-König
2017-11-28 7:59 ` Sascha Hauer [this message]
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=20171128075958.ldvyyw2x64d5gbxk@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=u.kleine-koenig@pengutronix.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