Age | Commit message (Collapse) | Author | Files | Lines |
|
OE-Core commit 26d97acc71379ab6702fa54a23b6542a3f51779c adjusted
how IMAGE_NAME_SUFFIX is used and expect it to no longer be present
in most of the image-conversion instructions. Remove it as necessary
in our image bbclasses.
Tested: Bletchley successfully compiles with latest Yocto subtree
update.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Idaeff6134f2068a6671f4bf22fd0223f08963369
|
|
FLASH_SIZE was previously defaulted in a few bbclasses and bbappends,
but this can result in it not being defined in all recipes if the
machine has not overridden the FLASH_SIZE. openbmc/openbmc#3876
reported one such case where the u-boot-fw-utils recipe does not
receive the correct FLASH_SIZE and ends up erasing the wrong flash
region as if it were the u-boot enviroment. Specify it in the common
include so it is available everywhere.
Resolves openbmc/openbmc#3876.
Change-Id: Iacdde1a5d0081b54321110d655da18bb3846cd14
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
|
|
The script was comparing string with `==` that works in bash but not in
`dash`.
Change it to `=` so that it is more POSIX compliant.
Tested: Verify the build passes with SIGNING_PUBLIC_KEY defined with
both `bash` and `dash`.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: Id825cd111adeae5b1e50ea4f25603728cc122375
|
|
The 32MB images (AST2400/AST2500) need more space than I originally
left for holding the U-Boot binary. Reduce the manifest on those
systems to 4KB instead of 8KB in order to leave enough space for
U-Boot.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I980f2989782577bab4e2560dfb70a1f5fcbf018b
|
|
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Id89782274717a4fdcabb10df19510cbd05571ec1
|
|
Support SIGNING_PUBLIC_KEY so that it generates an unsigned tarball.
Such tarball will be signed by separate tools as needed.
Tested:
* Do not define both SIGNING_KEY and SIGNING_PUBLIC_KEY, it generates
the tarball as before with the dev key.
* Define SIGNING_PUBLIC_KEY and do not define SIGNING_KEY, it generates
tarballs without signature.
* Define SIGNING_KEY and do not define SIGNING_PUBLIC_KEY, it generates
the tarball signed with the SIGNING_KEY.
* Define both SIGNING_KEY and SIGNING_PUBLIC_KEY, it gets error on
building phosphor-image-signing recipe.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: If6cffc477c1aa76674af758e0154b21b7b88c099
|
|
It is desirable to have a single image for both manufacturing and
updates instead of the separate MTD and tarball. Define a JSON
format and populate it, based on a combination of the current MANIFEST
data and learnings from the Meta verified-boot metadata format[1,2].
This JSON file is then embedded into the image itself, so that update
tools can determine the compatibility and correctness of the image
before applying.
An example manifest JSON can be found at [3].
[1]: https://github.com/facebook/openbmc/blob/eda9e95e2d94feaa2749f2a8e97e237bfe7b38e3/tools/flashy/lib/validate/partition/p_fbmeta.go
[2]: https://github.com/facebook/openbmc/blob/eda9e95e2d94feaa2749f2a8e97e237bfe7b38e3/meta-facebook/classes/fbobmc-image.bbclass#L200
[3]: https://gist.github.com/williamspatrick/9bd5e39909df2a3cad4894dc926d5c1c
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Iff0b7a37194297d49ca4f3d6077d5995452d7c72
|
|
The previous static-image building code only confirmed that the
u-boot image was smaller than the offset for the kernel image, but
most systems place the u-boot environment after the u-boot image.
It is possible that we have a u-boot image bigger than the u-boot
partition, which is then overwritten on boot by the u-boot env.
Check for this at image build time and prevent it from happening.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I3a1e6654272cedb3e840bbea4771ae4e464c4ecd
|
|
When the image generation fails due to file size, print out the amount
by which the input file overflows the available size.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Change-Id: I866f97994688671c247b9fe05c59b30b3d6eebd7
|
|
Define a new image type 'static-norootfs' that takes the entire
rootfs and places it as the initramfs for the kernel's FIT image,
so that the BMC is entirely running from a ramdisk.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I0163f5be0a1b176e0db5f89b85f34e4feae8a588
|
|
The EXTENDED_VERSION in the os-release file was an optional field.
Initialize it to a default since there will be a Redfish property for
extended version information that can be mapped to the ExtendedVersion
D-Bus property, choose the VERSION_ID value as the default since that's
what's used for the Version D-Bus property, and set it to a weak
variable so it can still be overwritten.
Need a new function to get the EXTENDED_VERSION from the os-release file
instead of just from a bitbake variable. It is still possible to
overwrite the default value in a conf or bbappend file, same as
BUILD_ID.
Note that the extended version was and still is surrounded by quotes,
since this is a free-format string that may contain spaces.
Tested:
- Verified the extended version string was the same as version in:
- os-release:
VERSION_ID=2.13.0-dev-613-g1e16157845
EXTENDED_VERSION="2.13.0-dev-613-g1e16157845"
- MANIFEST:
version=2.13.0-dev-613-g1e16157845
ExtendedVersion="2.13.0-dev-613-g1e16157845"
- D-Bus properties:
.ExtendedVersion property s "2.13.0-dev-613-g1e16157845"
.Version property s "2.13.0-dev-613-g1e16157845"
- Verified that extended version could be set from a conf file, example:
in meta-ibm/conf/machine/witherspoon.conf:
EXTENDED_VERSION = "My Extended Version"
- Verified that extended version could be set from a bbappend, example:
in meta-ibm/recipes-core/os-release/os-release.bbappend:
EXTENDED_VERSION:witherspoon = "My_Extended_Version_from_bbappend"
Change-Id: I74adf08239c9cd08768be9c5d9cd3384e703da95
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
This adds CompatibleNames field to the manifest file which can contain
compatibility strings as described in the Software interface.
The field is set by the OBMC_COMPATIBLE_NAMES variable in the
machine.conf file, e.g.
OBMC_COMPATIBLE_NAMES = "\
foo.bar \
baz.bim \
"
Also omit ExtendedVersion from the manifest file if it is not set.
Signed-off-by: Justin Ledford <justinledford@google.com>
Change-Id: Id27b4d6ec25ec7c3d3d5942368f40e618535eafe
|
|
Add the BUILD_ID value to the MANIFEST so that it can be used alongside
the VERSION value to generate a version id during firmware updates.
Add a function to read BUILD_ID from the os-release file instead of
reading it from a variable because the BUILD_ID value could be set via a
os_release.bbappend file instead of a .conf file.
Tested: Verified the BUILD_ID value was added to the MANIFEST by
default, and when BUILD_ID was specified in a .conf file, and on a
os-release.bbappend. Ex:
$ cat MANIFEST
purpose=xyz.openbmc_project.Software.Version.VersionPurpose.BMC
version=2.11.0-dev-566-g263df7f852
BuildId=20211025151654
ExtendedVersion=
KeyType=OpenBMC
HashType=RSA-SHA256
MachineName=p10bmc
Change-Id: I3b7beaccbbd47d8820d499180ccdf021b004cf85
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I588025b614416c43aa2d053765ab53bacf890cb5
|
|
Add an addition override for 64MiB static flash layout.
The existing 32MiB layout are unchanged:
partition: size: offset
u-boot: 384 KiB (0 KiB)
u-boot-env: 128 KiB (384 KiB)
kernel/FIT: 4352 KiB (512 KiB)
rootfs: 23808 KiB (4864 KiB)
rwfs: 4MiB (28672 KiB)
The existing 128MiB layout are unchanged:
partition: size: offset
u-boot: 896 KiB (0 KiB)
u-boot-env: 128 KiB (896 KiB)
kernel/FIT: 9 MiB (1 MiB)
rootfs: 86 MiB (10 MiB)
rwfs: 32MiB (96 MiB)
The new layout for 64MiB is as follows:
partition: size: offset
u-boot: 896 KiB (0 KiB)
u-boot-env: 128 KiB (896 KiB)
kernel/FIT: 9 MiB (1 MiB)
rootfs: 32 MiB (10 MiB)
rwfs: 22 MiB (42 MiB)
Signed-off-by: Troy Lee <troy_lee@aspeedtech.com>
Change-Id: I001cf2e9bc30edc34e43c0c4503684050e2a764f
|
|
- We will hit a problem intermittently when we build image-bmc:
We have 2 tasks running in parallel, the `do_generate_static` and
`do_generate_static_alltar`. Both specify to use the same work
directory, and both call to generate the signature files:
do_generate_static_tar[dirs] = " ${S}/static"
do_generate_static_alltar[dirs] = "${S}/static"
Depending on timing, one task can remove the `image-full` file from
the directory and the other task won't find it, and cause built
failed.
Error message: image-full: No such file or directory.
- Resolves openbmc/openbmc#3797
Tested: built obmc-phopshor-image successfully.
Temporarily solve openbmc/issues/3797
Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I7147f6c8db4f3a2a0c0c9bd54ac384ee8882b233
|
|
This patch will add the "ExtendedVersion" field in manifest file.
Note the extended version is typically set in the
openbmc/meta-*/meta-MACHINE/conf/local.conf.sample file
(This is where TEMPLATECONF points to.) by "EXTENDED_VERSION"
variable.
Signed-off-by: Chanh Nguyen <chanh@amperemail.onmicrosoft.com>
Change-Id: I071448badd3b3f56e7d771af0a058bb58db04511
|
|
Currently the contents of the code update tarball are individually
signed and signature files for each file are created.
In order to ensure that the contents of the tarball are the expected
ones as a full package, it is necessary to create an additional single
signature file bashed on the individual signature files.
(From meta-phosphor rev: 80b9baede615563bc15e5218cb051f57ae451b8d)
Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I6373d4f0387e8f64c2c30be05e0d43af4ed9b913
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
There are errors seeing in the eMMC when the empty space of an
image is filled with 0xff like it's done for NOR chips instead of
0s. Create a function to create empty images with 0s.
Also create an empty image for u-boot of 1MB (twice its current
size) so if the u-boot image that is flashed on a system is
smaller than what the system has, there's no leftover data at
the end that can cause issues.
Tested: Booted the new image-u-boot file on HW.
(From meta-phosphor rev: e4c3d766a0cda490758636f563572152a6ddfaa1)
Change-Id: I27f31f76c38bc256b84cad566afa1e98471695db
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
A number of tasks that depend on deployed images erroneously depend on
do_populate_sysroot instead of do_deploy.
This can have a range of side-effects such as failed image tasks because
of missing or stale sub-images in DEPLOY_DIR_IMAGE.
(From meta-phosphor rev: 1595ecbe6726f66bd40fcdde02f946a784bf7376)
Change-Id: I1d20c1a65f10ed38517b5ba5e87946c64b574eaa
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
This reverts commit 86cfbd54a3ef9c7379e044723253a38f850bab56.
There was a change in direction in the eMMC implementation that
didn't require verity verification, so removing from the code.
Documentation reference:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/28443
In addition, oe-core has now a verity bbclass in meta-security
that could be used if needed. Reference:
https://patches.openembedded.org/patch/171851/
(From meta-phosphor rev: 7edade144ae0c6291ded57858dc3f8e05ee873c9)
Change-Id: Ia56a06ef3b09518f7f45241aacfba12a4a57415d
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Create a recipe to add host firmware files to the BMC image files.
Via a bbappend, this recipe provides a mechanism
to have content be added to a flashable BMC image and an image
file to be added to the code update tarball to be updated
during a firmware update.
(From meta-phosphor rev: 39b1ff0dcd12f15dc651aa20cb85cdec903cb5de)
Change-Id: I12b3ced57a6446fd1fc046324ee13e4701581336
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
The eMMC has two boot ext4 partitions with the fitImage in
them. For the code update tarball, create this ext4 filesystem
so that code update can flash it.
(From meta-phosphor rev: 066633db0c7a7023b6644ebfc615c3f93a2732e1)
Change-Id: I561fd71b2d532ab856caaf41a62bc02b2f8c5444
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Compress the ext4 rootfs so that it's faster to transfer to the
BMC and does not take much space. The code update process can
then uncompress it on the fly and write to flash.
Use zstd to compress which has a good compression rate and is also
faster to decompress than xz.
(From meta-phosphor rev: 5e1b6dc499736e219766cc24924dd486ff2a8ccb)
Change-Id: I07aadc413e5e883a6b97d1a374e4bbf215b07786
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
If a u-boot spl file is built, generate a image-u-boot file
with it so that code update can flash the u-boot mtd with
the spl.
(From meta-phosphor rev: 8fe768d9c696730eb67d48c243cbab9b228b8334)
Change-Id: I8ead2155593945602c925b26e85d2b6effc206f9
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
If the [SPL_BINARY][1] variable is set, add the spl binary to
the static image, then increase the u-boot offset by the size
of the spl (default to 64kb).
[1]: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-SPL_BINARY
(From meta-phosphor rev: 31fdddf87d96ddeed1b16639368c6bea991392b1)
Change-Id: I96fef2323dec511257ea17ce6d4aa888d3ba1dbf
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Debugging text to help with filesystem sizing
This can be useful when diagnosing sizing issues
No behavioral change intended
Tested: Output appears as expected
(From meta-phosphor rev: a68b23d5052d6650176547b6ba3a4d9ccf0dc08e)
Signed-off-by: Josh Lehan <krellan@google.com>
Change-Id: I37d5daf038348576c43f5c1fb9e517e6e8aa37a0
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
|
|
Add support to create a rootfs image setup with dm-verity
which allows for secure boot of a BMC’s userspace.
This image type can be enabled by adding 'IMAGE_FSTYPES = "mmc-verity"'
to a machine's conf file.
Tested: Booted an image on QEMU.
(From meta-phosphor rev: 86cfbd54a3ef9c7379e044723253a38f850bab56)
Change-Id: If866a71cb031abfef6b1ab3c5ebe0869b1595300
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
The current version purpose is set to BMC[1]. Make it a configurable
variable for cases where other Purpose value is more appropriate, like
setting it to System if the machine includes the host-fw package that
would package the BMC and host firmware code into a combined image.
1: https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/Version.interface.yaml
Tested: Verified the purpose is still BMC, then verifed that setting the
variable from a machine.conf file changed its value.
(From meta-phosphor rev: 356265535d268858840ddbe52ff8c1e37f084188)
Change-Id: I159e73f9b9c310321dda885b10dbc1cd56a674ee
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Add a new do_generate_ext4_tar() function that creates a tarball with
u-boot, kernel, ext4 rootfs and rwfs image files. This tarball is
intended for systems running with a mmc chip.
(From meta-phosphor rev: 02d65b716915f4424feca600f955937e1d16eb1a)
Change-Id: I3545dbb7c36d4ba5a71fb3735324228e8b609a15
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Create a new do_generate_rwfs_ext4() function that generates an empty
ext4 rwfs image file of arbitrary size 1MB. This file is needed to create
a tarball image for code update to use. The size can later be updated,
this commit is intended as a first step for creating a tarball with ext4
image files.
(From meta-phosphor rev: 846990eb90e662176c9e8c395e1093ebf7e6934c)
Change-Id: Idf9cd1dc4f79c2f6cf7f567b8abaf35123a5ca6a
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
The make_rwfs() was doing some cleanup before creating the rwfs file.
Split it into two functions clean_rwfs() and make_rwfs() for cases where
some prep work is needed before calling the rwfs command, such as when
using mkfs.ext4 that needs to have a file created before it's converted
into ext4.
(From meta-phosphor rev: e82e8bc686b0a17f29d1d296f1d52543f2bc5ae0)
Change-Id: Idebaab86bfd6ff0c02444d9c62543e97e9ba0dcd
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
The make_tar_of_images() function was adding an mtd suffix to the
tarball name. Make the caller pass the suffix instead so that this
function can be used to create tarballs intended for non-mtd systems
such as systems based on a mmc chip.
(From meta-phosphor rev: 7bdbb7a6adaa655ba56ae2e289a59e13c9428b14)
Change-Id: I80ee15337f99ec59cce119668ef7f5afb2313189
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
The mk_nor_image() function just creates an empty image file. Rename it
to mk_empty_image() so that it makes more sense when used to create a
file for other chips such as a mmc instead of a nor, like an empty rwfs
ext4 image file.
(From meta-phosphor rev: fdb81a30d7e86309aeafc6b6ab1ebf8f9cf93d88)
Change-Id: I31231ddaec5a8c195da315841e59ecdfb16647a5
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Added machine name in the image manifest file which can be used to
verify on target while upgrading
(From meta-phosphor rev: ba9f97ed4018c8a6b1d74cb958bfb2a80fd94546)
Change-Id: I31dca600c0a2ff1bd2cf8e13c486e529d245b5d7
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Add an override based on FLASH_SIZE, for use with the hardcoded offsets
that exist when building raw flash images.
This lets us have different flash layouts for different size flash
modules that can be shared between machines.
The existing 32MiB layouts are unchanged:
partition: size: offset
u-boot: 384 KiB (0 KiB)
u-boot-env: 128 KiB (384 KiB)
kernel/FIT: 4352 KiB (512 KiB)
rootfs: 23808 KiB (4864 KiB)
rwfs: 4MiB (28672 KiB)
The new layout is as follows:
partition: size: offset
u-boot: 896 KiB (0 KiB)
u-boot-env: 128 KiB (896 KiB)
kernel/FIT: 9 MiB (1 MiB)
rootfs: 86 MiB (10 MiB)
rwfs: 32MiB (96 MiB)
(From meta-phosphor rev: 9e84ca2ad4aa7f864bb53faa6f21ae580d64d07d)
Change-Id: I4edf302d4e738b31906cd03459ad6f2f44c3c749
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
If we try and generate a `core-image-minimal` and `obmc-phosphor-image`
target in the same workspace we will currently encounter an error in
bitbake complaining about
```
obmc-phosphor-image-1.0-r0 do_image_complete: The recipe obmc-phosphor-image is trying to install files into a shared area when those files already exist. Those files and their manifest location are: rwfs.jffs2
```
This patch fixes the complaint by using a distinctly generated rwfs per
image type.
(From meta-phosphor rev: 8ba81f79c03e673e682079da1f2c62ebb1325645)
Change-Id: I5be72cc7d442f5c5853d87de27a57996a6af98e4
Signed-off-by: William A. Kennington III <wak@google.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Reset the following subtrees on thud HEAD:
poky: 87e3a9739d
meta-openembedded: 6094ae18c8
meta-security: 31dc4e7532
meta-raspberrypi: a48743dc36
meta-xilinx: c42016e2e6
Also re-apply backports that didn't make it into thud:
poky:
17726d0 systemd-systemctl-native: handle Install wildcards
meta-openembedded:
4321a5d libtinyxml2: update to 7.0.1
042f0a3 libcereal: Add native and nativesdk classes
e23284f libcereal: Allow empty package
030e8d4 rsyslog: curl-less build with fmhttp PACKAGECONFIG
179a1b9 gtest: update to 1.8.1
Squashed OpenBMC subtree compatibility updates:
meta-aspeed:
Brad Bishop (1):
aspeed: add yocto 2.6 compatibility
meta-ibm:
Brad Bishop (1):
ibm: prepare for yocto 2.6
meta-ingrasys:
Brad Bishop (1):
ingrasys: set layer compatibility to yocto 2.6
meta-openpower:
Brad Bishop (1):
openpower: set layer compatibility to yocto 2.6
meta-phosphor:
Brad Bishop (3):
phosphor: set layer compatibility to thud
phosphor: libgpg-error: drop patches
phosphor: react to fitimage artifact rename
Ed Tanous (4):
Dropbear: upgrade options for latest upgrade
yocto2.6: update openssl options
busybox: remove upstream watchdog patch
systemd: Rebase CONFIG_CGROUP_BPF patch
Change-Id: I7b1fe71cca880d0372a82d94b5fd785323e3a9e7
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Prevent building unbootable firmware images.
Resolves: openbmc/openbmc#3314
Tested: I checked builds for `palmetto` and `romulus`.
To reproduce the problem I appended a big file to initramfs by modify
`meta-phosphor/common/recipes-phosphor/initfs/obmc-phosphor-initfs.bb`.
The building process failed with message about too large initramfs image.
Change-Id: I0176e9c47a9cb26ce8ba588794e681b6426d567d
Signed-off-by: Alexander Filippov <a.filippov@yadro.com>
|
|
There are duplicated code about generating signatures.
Combine the duplicated code into a bash function so the code is cleaner
and easier to read.
Tested: Generated tarball contains the expected files.
Change-Id: I4144633f36291329dfc4008bb73482fb5a0d43c1
Signed-off-by: Lei YU <mine260309@gmail.com>
|
|
In generated fixed flash layout tarball, add manifest and signature
which can be used for code update by phosphor-software-manager.
Tested: Verify the generated static tar contains image(s), manifest,
public key and their signatures.
Verify that all.tar can be used to do code update by both
legacy method (org.openbmc.control.BmcFlash.service) and
phosphor-software-manager.
Change-Id: Ib6880c8a6d456cce6b0fd47116960d1d448d5d50
Signed-off-by: Lei YU <mine260309@gmail.com>
|
|
Do not rely on the base configuration to set this.
Change-Id: I537f08a1834fb2d2a5fd2f73ca73cfc0566464cb
Tested: Built a witherspoon image
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
In order to secure the BMC, we need to sign all the images and include a
public key in the package with which to verify future update images.
This commit adds a framework to sign the image files with an open
private key and generates a corresponding public key added to the image.
This isn't secure by itself (since the private key is available), but
additional changes can easily provide their own private key, creating a
secure BMC.
To use a secure private key:
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SIGNING_KEY"
SIGNING_KEY=/path/to/secure/key bitbake obmc-phosphor-image
Resolves openbmc/openbmc#2835
Resolves openbmc/openbmc#2836
Resolves openbmc/openbmc#2837
Change-Id: I28919b7de54e3a32e5efcbb4522fb39731e68384
Signed-off-by: Eddie James <eajames@us.ibm.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
The overlay image type doesn't have any code behind it and thus
selecting it in IMAGE_FSTYPES would result in unexpected behavior.
An overlay image type still exists but it was renamed to mtd-static
in an earlier refactor, and this cleanup was omitted.
Tested: Built witherspoon and palmetto images
Change-Id: I7eb41afcf25ae2d251bf671dd0e5a18e1064f7c4
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Move image symlink creation for phosphor-bmc-code-mgmt out
of make_tar_of_images into its own function, so we can run
additional code in between symlink creation and tar file
creation.
Tested: Built witherspoon and palmetto images
Change-Id: I3025db6bb788d7c2bcf5c2a400af647c7c957164
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
Move OpenBMC to Yocto 2.3(pyro).
Tested: Built and verified Witherspoon and Palmetto images
Change-Id: I50744030e771f4850afc2a93a10d3507e76d36bc
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Resolves: openbmc/openbmc#2461
|
|
As with MRW the use of the UBI image scheme is distro policy.
Convert the existing machine feature to a distro feature.
Enable the new distro feature on the systems that use
it(Witherspoon).
Add a distro override and fix-up MF checks to use this override
instead for improved readability.
Tested: Built a Witherspoon image and validated image
Change-Id: I8ab03115bbfc2ecc77cff5c9eb8628903ae88051
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
|
|
The default size of the UBI read-write volume is currently set to 4MB.
There are no plans to store more than one BMC rootfs image on the chip
so in a 32MB flash chip, accounting for the current rootfs image size
of ~15MB with plans to grow to ~20MB with the addition of redfish and
other packages, it is safe to increase the read-write volume size to
6MB since the current size is already almost completely taken up if
there are multiple error logs / dumps on the system.
In addition, make the size configurable from a recipe so that the
size can be changed in a per-system basis. And during code update,
check the current size and update it if it's different, this allows
systems to be able to be resized to a new size by performing factory
reset after a code update that sets the new size.
Tested:
- Booted on QEMU and verified non-ubi system (romulus) retains the
current 4MB read-write volume, and ubi system (witherspoon) has a
6MB volume.
- Code updated to an image that has these changes and verified the
rwfs_size env variable changes to 6MB, and that a subsequent factory
reset rebuilds the volume with size 6MB.
Change-Id: I995eb560c1bd87ee95712c731e3d6e55bc0b2735
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|
|
- When the new ubi layout is flashed onto the BMC, the volumes
were named kernel-0 and rofs-0 by default. This tends to be
misleading as we can't differentiate between two different BMC
versions.
- Now the ubi volumes will be named kernel-<versionID> and
rofs-<versionID> calculated by getting the hash(SHA-512) of
the version and taking the first 8 characters.
- The Uboot env needs to be updated to point to the correct
kernelname which has now changed from kernel-0 to
kernel-<versionID> calculated by getting the HASH(SHA-512)
of the version and taking the first 8 characters.
Resolves openbmc/openbmc#2323
Change-Id: I258d165b399d1ff59ea86f410006f6d03fe13a2e
Signed-off-by: Saqib Khan <khansa@us.ibm.com>
|
|
Name the BMC volume names consistently in the build process and
applications to be <name>-<id> for readability. For names, use
rofs and rwfs instead of ro and rw.
Change-Id: I860f740fb7d0292e4ee09493730db1d1f67c2ae5
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
|