From: Ivan Mikhaylov <i.mikhaylov@yadro.com>
To: Lei Yu <yulei.sh@bytedance.com>
Cc: Alexander Amelkin <a.amelkin@yadro.com>,
openbmc <openbmc@lists.ozlabs.org>
Subject: Re: Design proposal for dual BMC flash with "golden image"
Date: Wed, 16 Sep 2020 12:58:53 +0300 [thread overview]
Message-ID: <27aecca09a3f74d12974bfafde830ded5d69a7e0.camel@yadro.com> (raw)
In-Reply-To: <CAGm54UHG611qtbKObUkFOYjaSkSd+tMabJ=kOwo9TkauyejyRg@mail.gmail.com>
On Tue, 2020-09-15 at 11:38 +0800, Lei Yu wrote:
> > - A series of patches for implementing flash locks for Macronix chips that
> > we
> > use
> > - A utility which gives control of golden side, called `gftool` and
> > providing
> > abilities to:
> > - lock/unlock golden side
> > - reboot into golden side
> > - reflash golden side from main
> >
>
> Does the lock/unlock function work on the Macronix chip only? Does it
> apply to other chips?
It can be applied to different chips, macronix locks are not supported for now
in upstream. You can check here -
https://elixir.bootlin.com/linux/v5.9-rc5/source/drivers/mtd/spi-nor , chipswith SPI_NOR_HAS_LOCK.
> > Yes, but the watchdog series of patches is more like a hack for now.
> > We're expanding the watchdog api so that it grants the user control of WDT2
> > via
> > ioctl(watchdog start on reboot) and allows for rebooting into golden chip
> > using
> > WDT2. However the upstream kernel maintainers won't accept it as they say
> > it's a
> > driver level decision, and we're exporting it to the user. That's something
> > they
> > don't want to accept. That may be fine though as theoretically the patch set
> > may
> > be kept only in the openbmc linux kernel, but that will put an additional
> > support burden on Joel and the community. I'm discussing that with Joel.
>
> OK, thanks.
> For now, we use "devmem" to manipulate the registers for testing purpose.
> It's nice to have that driver, but in productions there will be no
> need to use devmem nor the ioctl on watchdog, so it's not a must for
> us to use the driver.
>
And how you switch safely into golden side in this case?
Thanks.
next prev parent reply other threads:[~2020-09-16 9:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 8:49 Design proposal for dual BMC flash with "golden image" Lei Yu
2020-09-11 11:48 ` Alexander Amelkin
2020-09-11 12:01 ` Lei Yu
2020-09-11 14:26 ` Ivan Mikhaylov
2020-09-15 3:38 ` Lei Yu
2020-09-16 9:58 ` Ivan Mikhaylov [this message]
2020-09-16 10:18 ` Lei Yu
2020-09-16 10:35 ` Alexander Amelkin
2020-09-16 12:06 ` Ivan Mikhaylov
2020-09-16 12:13 ` Lei Yu
2020-09-22 14:19 ` Ivan Mikhaylov
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=27aecca09a3f74d12974bfafde830ded5d69a7e0.camel@yadro.com \
--to=i.mikhaylov@yadro.com \
--cc=a.amelkin@yadro.com \
--cc=openbmc@lists.ozlabs.org \
--cc=yulei.sh@bytedance.com \
/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;
as well as URLs for NNTP newsgroup(s).