bmcweb image upload
Lei YU
mine260309 at gmail.com
Fri Apr 26 12:45:51 AEST 2019
On Fri, Apr 26, 2019 at 12:22 AM Patrick Venture <venture at google.com> wrote:
>
> On Thu, Apr 25, 2019 at 8:17 AM Wim Vervoorn <wvervoorn at eltan.com> wrote:
> >
> > Hello Patrick,
> >
> > Thanks for the response. I will try this. Some other thing I noticed is that the image update now uses a TAR file. Basically it transfers the TAR to the system, then untars the file and uses it. This means the mechanism requires twice the size of the TAR file.
This really is a problem for small RAM system.
> Yikes, that's absolutely true and unusable. We only do image uploads
> over in-band mechanisms today for our platforms. And in the future,
> that is likely going to stay the same for the ast2400s -- although
> good to know this issue.
>
> The tar is used for UBI, IIRC< and not a static image layout -- with
> the static image layout, does it still use a tarball? We've stuck
> with static layout instead of using UBI for unrelated reasons.
>
Actually, we have tarball like <machine>-<date>.tar for static layout as well
now, containing separated image-xxx, manifest and signatures.
And we could use the same method as UBI to do code update for static layout.
> >
> > I am now considering to use an ISO file and mount this this will require less memory. What do you think about this, do I overlook something or can this be a viable solution?
>
Yup, this is doable (not necessary ISO though), as long as the free memory is
enough for the BMC code itself.
> We just use the actually image-bmc that's generated and a signature
> file for the updates, but the code to handle this isn't fully upstream
> yet (WIP openbmc/phosphor-ipmi-flash).
More information about the openbmc
mailing list