Design proposal for dual BMC flash with "golden image"

[Ivan Mikhaylov]

Hey Lei, the main idea is to provide user transparent and safe access to
the golden side with, and to give our manufacturing department (and possibly the
support engineers too) the write lock control and possibility to flash the
golden chip during server assembly and even later if the need arises (like major
bugs discovered in the golden firmware version).

To achieve these goals we've made a utility and some kernel patches for watchdog
and spi nor driver:

- A series of patches for aspeed watchdog and watchdog api.
  A new ioctl was added into the watchdog api that sets a
  `start on reboot` status. It grants us transparent and safe switch into
  golden side without worrying about breaking something on the main spi flash
  side if we want to force-switch to golden side for testing.

- 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

> That's good to know! Could you comment on the design doc and see how
> much difference it has?

Yes, I will do on monday.

> Also, may I ask if Yadro's implementation could be open sourced or not?

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.

Thanks.