RE: [EXTERNAL] Re: BMC update via TFTP

[Bonnie Lo/WYHQ/Wiwynn <Bonnie_Lo@wiwynn.com>]

Dear Joseph,

In my understanding, the BMC firmware update flow is as below:
1. Trigger reboot 
2. Systemd stop all service
3. Unmount file system
4. image is in /run/initramfs 
5. Do the flashcp command to update the flash 

If there is any misunderstanding, please correct me.

Based on the discussion with Neeraj.
We want to be able to update BMC firmware without having to trigger the BMC reboot command before the system do flashcp command.
It means that we can do the flashcp first. If the flashcp command complete and success, then we do the reset manually.
Is it workable on current upstream code?
If not, why? I means is there any advantage to trigger the reboot before we do the flashcp.

Thanks,
Bonnie

-----Original Message-----
From: openbmc <openbmc-bounces+bonnie_lo=wiwynn.com@lists.ozlabs.org> On Behalf Of Joseph Reynolds
Sent: Wednesday, December 11, 2019 5:11 AM
To: Neeraj Ladkani <neladk@microsoft.com>; Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com>; openbmc@lists.ozlabs.org; Patrick Venture <venture@google.com>
Subject: Re: [EXTERNAL] Re: BMC update via TFTP

On 12/10/19 12:58 PM, Neeraj Ladkani wrote:
> Are there any thoughts to get rid of BMC reset to trigger FW update? I understand FW reset is required after the update.

I'm not sure I understand the question.  I think the answer depends on the [Software.VersionPurpose][1].
For VersionPurpose=BMC or System, the BMC must be reset.
For VersionPurpose=Host, PSU, or Other, I don't know why the BMC would need to be reset.

Do you want to be able to update non-BMC firmware without having to reset the BMC?

- Joseph

[1]: 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fphosphor-dbus-interfaces%2Fblob%2Fmaster%2Fxyz%2Fopenbmc_project%2FSoftware%2FVersion.interface.yaml&amp;data=02%7C01%7CBonnie_Lo%40wiwynn.com%7C9d56d702cea54e52e29808d77db630a1%7Cde0795e0d7c04eebb9bbbc94d8980d3b%7C1%7C0%7C637116093768947793&amp;sdata=vAh3kDz2onq8b0%2Flx1AyPNyFngyPLag7go%2Fruw9nEtU%3D&amp;reserved=0

>
> -----Original Message-----
> From: openbmc <openbmc-bounces+neladk=microsoft.com@lists.ozlabs.org> 
> On Behalf Of Joseph Reynolds
> Sent: Monday, December 9, 2019 5:25 PM
> To: Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com>; 
> openbmc@lists.ozlabs.org
> Subject: [EXTERNAL] Re: BMC update via TFTP
>
> On 12/9/19 10:06 AM, Alexander Tereschenko wrote:
>> On 06-Dec-19 23:52, Joseph Reynolds wrote:
>>> I was thinking along the lines of adding [SFTP][] (or SCP) support 
>>> and then migrating existing TFTP users to the new secure solution.

[...snip...]

>> Yes, that could be a solution for the problem we discuss, providing 
>> both integrity and confidentiality, without any major OpenBMC 
>> development necessary - but it would mean more operational burden for 
>> BMC admins. The problem with SCP/SFTP in this context is that for 
>> this to work in the same manner as TFTP, the BMC must be an SSH 
>> client - i.e. have some sort of identity/credentials for the SCP/SFTP 
>> server provisioned first. That might not be the easiest solution to 
>> setup, but it's of course possible and can be automated if OpenBMC 
>> provides respective config knobs.
>>
>> Existing ways we have in code-update.md either don't require 
>> credentials (TFTP), so being a client is easy, or are not making a 
>> "client" from BMC, it's the admin who uploads stuff (SCP/REST).
> Yes, that's what I was thinking.  (And no, I am not going to recommend 
> setting up a SCP or SFTP server that allows anonymous access.)
>
> This highlight the need for OpenBMC to put together a guide to provisioning your BMC.    Such as guide would give us a place to talk about uploading to the BMC SSH client certificates needed to access and download the firmware images.
>
> - Joseph
>
>> regards,
>> Alexander
>>