Design proposal for dual BMC flash with "golden image"

Alexander Amelkin a.amelkin at yadro.com
Wed Sep 16 20:35:59 AEST 2020


16.09.2020 13:18, Lei Yu пишет:
> Does the lock/unlock function work on the Macronix chip only? Does it
> apply to other chips?

As Ivan said, it is supported by some other chips as well. At least some 
ST chips have that feature.

Nonetheless, that feature is not a must. We just had to implement 
support for it for the Macronix chips
that we use, or otherwise they would just ignore the #WP pin. Most chips 
that don't have the software
lock/unlock feature can be properly protected/unprotected using the 
traditional #WP pin mechanism.

> On Wed, Sep 16, 2020 at 5:55 PM Ivan Mikhaylov <i.mikhaylov at yadro.com> 
> wrote:
>>> 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?
>>
> The plan is:
> 1. When the primary flash is broken and u-boot could not be started,
> aspeed will switch to the golden side automatically.
> 2. When the primary flash's u-boot is OK, but the kernel/rofs fails a
> couple of times, the u-boot could detect this and switch to the golden
> side by setting the related registers. See example in
> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/aspeed-layer/recipes-bsp/u-boot/files/0005-config-ast-common-Fall-back-to-secondary-flash-on-fa.patch

The main idea behind the new ioctl() is to allow for easy switching into 
the golden chip
for testing purposes when both the u-boot and the kernel/rofs on the 
primary chip are fine.

Alexander



More information about the openbmc mailing list