summaryrefslogtreecommitdiff
path: root/meta-phosphor/classes/image_types_phosphor.bbclass
AgeCommit message (Collapse)AuthorFilesLines
2023-08-10meta-phosphor: adjust IMAGE_NAME_SUFFIX usePatrick Williams1-0/+2
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
2023-06-20meta-phosphor: simplify FLASH_SIZE specificationPatrick Williams1-1/+0
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>
2023-06-20meta-phosphor: image-signing: Make script POSIX compliantLei YU1-1/+1
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
2023-03-27meta-phosphor: static-norootfs: reduce manifest size for 32MB flashPatrick Williams1-1/+1
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
2023-03-20meta-phosphor: retab all bitbake filesPatrick Williams1-182/+182
Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Change-Id: Id89782274717a4fdcabb10df19510cbd05571ec1
2023-03-20image_types_phosphor: Add SIGNING_PUBLIC_KEYLei YU1-10/+27
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
2023-03-11meta-phosphor: static-norootfs: add manifest JSON to imagePatrick Williams1-5/+91
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
2023-03-11meta-phosphor: add offset for uboot environmentPatrick Williams1-2/+5
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
2023-01-18meta-phosphor: image: Show bytes when over sizeJoel Stanley1-1/+1
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
2023-01-14meta-phosphor: introduce static non-rootfs image typePatrick Williams1-2/+76
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
2022-08-08Initialize EXTENDED_VERSION to a defaultAdriana Kobylak1-1/+1
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>
2022-03-28image_types_phosphor: Add compatible name to MANIFESTJustin Ledford1-2/+7
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
2021-11-10image_types: Add BUILD_ID to MANIFESTAdriana Kobylak1-0/+2
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>
2021-08-11meta-phosphor: prep for new override syntaxPatrick Williams1-19/+19
Signed-off-by: Patrick Williams <patrick@stwcx.xyz> Change-Id: I588025b614416c43aa2d053765ab53bacf890cb5
2021-06-15phosphor: image_types_phosphor: 64MiB flash default layoutTroy Lee1-0/+3
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
2021-06-03image_type_phosphor: fix signatures generationGeorge Liu1-1/+0
- 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
2021-02-25image_types_phosphor: Adding the extended version in MANIFESTChanh Nguyen1-0/+2
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
2021-01-14image_type_phosphor: Support single signature for the tarball contentsGeorge Liu1-0/+8
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>
2020-11-17image_types_phosphor: mmc: Fill empty image with zerosAdriana Kobylak1-1/+9
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>
2020-11-13image-types-phosphor: depend on imagesBrad Bishop1-7/+7
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>
2020-09-01Revert "image_types_phosphor.bbclass: Add a mmc-verity image type"Adriana Kobylak1-99/+2
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>
2020-07-17phosphor-hostfw-image: Create recipeAdriana Kobylak1-2/+11
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>
2020-07-15image_types_phosphor: Add ext4 boot fs to eMMC tarballAdriana Kobylak1-2/+22
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>
2020-05-27image_types_phosphor.bbclass: mmc tar: Compress ext4 rootfsAdriana Kobylak1-1/+3
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>
2020-04-29image_types_phosphor: Create a image-u-boot file with splAdriana Kobylak1-2/+18
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>
2020-04-14image_types_phosphor: Add u-boot spl to static imageAdriana Kobylak1-1/+12
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>
2020-03-16image_types_phosphor: Add debug text for fs sizingJosh Lehan1-1/+5
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>
2020-02-10image_types_phosphor.bbclass: Add a mmc-verity image typeAdriana Kobylak1-2/+99
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>
2019-11-20image_types_phosphor: Make Version Purpose configurableAdriana Kobylak1-1/+4
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>
2019-10-23image_types_phosphor: Add do_generate_ext4_tar()Adriana Kobylak1-2/+27
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>
2019-10-23image_types_phosphor: Add do_generate_rwfs_ext4()Adriana Kobylak1-0/+15
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>
2019-10-23image_types_phosphor: Split make_rwfs()Adriana Kobylak1-3/+12
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>
2019-10-23image_types_phosphor: Remove mtd from make_tar_of_images()Adriana Kobylak1-4/+4
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>
2019-10-23image_types_phosphor: Rename mk_nor_image()Adriana Kobylak1-3/+3
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>
2019-10-17meta-phosphor: Adding machine name in MANIFESTVijay Khemka1-0/+2
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>
2019-09-27phosphor: image_types_phosphor: flash overridesBrad Bishop1-0/+6
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>
2019-09-23image_types_phosphor: Make rwfs name dependentWilliam A. Kennington III1-10/+10
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>
2019-01-09reset upstream subtrees to yocto 2.6Brad Bishop1-1/+1
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>
2018-07-25Check size of the firmware image partsAlexander Filippov1-13/+43
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>
2018-07-17image_type_phosphor: refactor signatures generationLei YU1-12/+12
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>
2018-07-16Add manifest and signature for fixed flash layoutLei YU1-4/+28
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>
2018-05-22image_types_phosphor: Add UBOOT_SUFFIX defaultBrad Bishop1-0/+2
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>
2018-03-30Add image signing framework and open keysEddie James1-1/+42
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>
2018-03-30image_types_phosphor: drop overlayBrad Bishop1-3/+2
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>
2018-03-30image_types_phosphor: split make_tar_of_imagesBrad Bishop1-7/+13
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>
2018-03-13Yocto 2.3Brad Bishop1-10/+0
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
2018-03-13Convert obmc-ubi-fs to a distro featureBrad Bishop1-3/+3
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>
2018-03-02Increase default size of UBI read-write volumeAdriana Kobylak1-2/+2
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>
2017-11-16Calculate the version ID of BMC UBI volumes during build time.Saqib Khan1-20/+20
- 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>
2017-08-24BMC: Make volume names consistentAdriana Kobylak1-2/+2
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>