From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3xN1Nv1Kj1zDqfk for ; Thu, 3 Aug 2017 04:07:10 +1000 (AEST) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v72I4C18016136 for ; Wed, 2 Aug 2017 14:07:07 -0400 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mx0a-001b2d01.pphosted.com with ESMTP id 2c3hrwp4eb-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 02 Aug 2017 14:07:07 -0400 Received: from localhost by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 Aug 2017 12:07:06 -0600 Received: from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 Aug 2017 12:07:03 -0600 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v72I73Pd31719596; Wed, 2 Aug 2017 11:07:03 -0700 Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5646B78057; Wed, 2 Aug 2017 12:07:03 -0600 (MDT) Received: from adriana-mbp.austin.ibm.com (unknown [9.41.250.82]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTPS id 0FFF478043; Wed, 2 Aug 2017 12:07:03 -0600 (MDT) From: Adriana Kobylak Content-Type: multipart/alternative; boundary="Apple-Mail=_38AC2087-6F63-44A0-813F-A9C1DAB121A8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: OpenBMC Image Management Date: Wed, 2 Aug 2017 12:15:59 -0500 In-Reply-To: Cc: OpenBMC Maillist To: Maxim Sloyko References: <75C63AB7-E340-4A78-BA82-80F96EAEA051@linux.vnet.ibm.com> X-Mailer: Apple Mail (2.3273) X-TM-AS-GCONF: 00 x-cbid: 17080218-0020-0000-0000-00000C7AFBC9 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007472; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000216; SDB=6.00896586; UDB=6.00448535; IPR=6.00676773; BA=6.00005506; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016500; XFM=3.00000015; UTC=2017-08-02 18:07:04 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17080218-0021-0000-0000-00005D8852B0 Message-Id: <9DAA22C7-7A31-47F1-8F14-B0227892DA57@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708020293 X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:07:13 -0000 --Apple-Mail=_38AC2087-6F63-44A0-813F-A9C1DAB121A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 16, 2017, at 5:18 PM, Maxim Sloyko wrote: >=20 > Hi Adriana, >=20 > On Wed, Jan 25, 2017 at 2:15 PM, Adriana Kobylak = > wrote: > Hi, >=20 > Here is a first draft proposal for image management (code update) in = OpenBMC for feedback. >=20 > General: > * Move to UBI volume management (on the BMC and PNOR chips), which = provides dynamic partitioning and wear-leveling. In a limited flash = space environment there might be the need to re-allocate partition space = and resizing in a static partitioning implementation can be very = painful. > * Use CRAMFS for read-only partitions, and UBIFS for read-write = partitions. >=20 > PNOR: > * Implement a new mboxd based on Cyril=E2=80=99s (see Cyril=E2=80=99s = email =E2=80=9CMailbox daemon=E2=80=9D) that handles dbus objects, = generates a virtual PNOR for UBI content, etc. > * Move to memory-based access instead of the current LPC-to-AHD path. > * Allocate just enough space in the initial window for Hostboot=E2=80=99= s TOC, HBB, and HBI partitions, grow as required. > * Ability to =E2=80=98patch=E2=80=99 by copying a Hostboot image *.bin = into a designated directory (/usr/local/ for example). > * Tool to write from PNOR image to BMC format. Implement UBI initially = but it could be extended to support different volume managements on = other BMCs. >=20 > BMC: > *Save multiple firmware versions, starting with 2, to provide the = ability to roll-back if needed. If single BMC chip system, save both = versions there. If two BMC chip system, save other version in 2nd chip. > * Implement various levels of =E2=80=98persistency=E2=80=99, such as = dev, factory, field. Dev persistency would allow for local patches = (/usr/local/ for example) that can be cleared before shipping to = customers. Factory mode could delete the location where user data such = as network settings resides but preserves the mac address and uuid for = example. Etc. >=20 > I'm interested in roll-back feature, do you have something working = already or is this still under construction? >=20 > Sorry, I could not find anything in the docs or code about it. For the roll-back feature, the user would use the RedundancyPriority = interface = (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openb= mc_project/Software/RedundancyPriority.interface.yaml ), to indicate which version they want to re-activate. For example, the = version1 is activated, the priority for it is 0, then version 2 is = activated which sets its priority to 0 and version 1 is set to priority = 1. The user can set the priority of version 1 to 0 to indicate that = version 1 should be activated thus triggering a roll back. This takes = effect on power on for pnor version, and on bmc reboots (still been = worked) for bmc versions. >=20 > Thanks=20 > =20 >=20 > Thanks, >=20 > Adriana > _______________________________________________ > openbmc mailing list > openbmc@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/openbmc = >=20 >=20 >=20 > --=20 > Maxim Sloyko --Apple-Mail=_38AC2087-6F63-44A0-813F-A9C1DAB121A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 16, 2017, at 5:18 PM, Maxim Sloyko <maxims@google.com> = wrote:

Hi Adriana,

On Wed, = Jan 25, 2017 at 2:15 PM, Adriana Kobylak <anoo@linux.vnet.ibm.com> wrote:
Hi,

Here is a first draft proposal for image = management (code update) in OpenBMC for feedback.

General:
* Move to UBI volume management (on = the BMC and PNOR chips), which provides dynamic partitioning and = wear-leveling. In a limited flash space environment there might be the = need to re-allocate partition space and resizing in a static = partitioning implementation can be very painful.
* Use = CRAMFS for read-only partitions, and UBIFS for read-write partitions.

PNOR:
* Implement a new mboxd = based on Cyril=E2=80=99s (see Cyril=E2=80=99s email =E2=80=9CMailbox = daemon=E2=80=9D) that handles dbus objects, generates a virtual PNOR for = UBI content, etc.
* Move to memory-based access instead of = the current LPC-to-AHD path.
* Allocate just enough space = in the initial window for Hostboot=E2=80=99s TOC, HBB, and HBI = partitions, grow as required.
* Ability to =E2=80=98patch=E2= =80=99 by copying a Hostboot image *.bin into a designated directory = (/usr/local/ for example).
* Tool to write from PNOR image = to BMC format. Implement UBI initially but it could be extended to = support different volume managements on other BMCs.

BMC:
*Save multiple firmware versions, starting = with 2, to provide the ability to roll-back if needed. If single BMC = chip system, save both versions there. If two BMC chip system, save = other version in 2nd chip.
* Implement various levels of = =E2=80=98persistency=E2=80=99, such as dev, factory, field. Dev = persistency would allow for local patches (/usr/local/ for example) that = can be cleared before shipping to customers. Factory mode could delete = the location where user data such as network settings resides but = preserves the mac address and uuid for example. Etc.

I'm interested in roll-back feature, do you have something = working already or is this still under construction?

Sorry, I could not find = anything in the docs or code about = it.

For the roll-back feature, the user would use the = RedundancyPriority interface (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master= /xyz/openbmc_project/Software/RedundancyPriority.interface.yaml<= blockquote type=3D"cite" class=3D"">
), to indicate = which version they want to re-activate. For example, the version1 is = activated, the priority for it is 0, then version 2 is activated which = sets its priority to 0 and version 1 is set to priority 1. The user can = set the priority of version 1 to 0 to indicate that version 1 should be = activated thus triggering a roll back. This takes effect on power on for = pnor version, and on bmc reboots (still been worked) for bmc = versions.

Thanks 
 

Thanks,

Adriana
_______________________________________________
openbmc mailing list
openbmc@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/openbmc



-- 
Maxim Sloyko

= --Apple-Mail=_38AC2087-6F63-44A0-813F-A9C1DAB121A8--