dual-image: Add reset-cs0-aspeed to reset the CS

When BMC is running on the secondary flash, and the primary flash is
updated, the BMC needs to reboot to the primary flash.

On aspeed, this is done

dual-image: Add reset-cs0-aspeed to reset the CS

When BMC is running on the secondary flash, and the primary flash is
updated, the BMC needs to reboot to the primary flash.

On aspeed, this is done by clearing the wdt2 state register bit, and
could be implemented by writing non-zero to
/sys/class/watchdog/watchdog1/access_cs0.
But it has a side effect that the CS will be swapped back to normal,
which means the running rootfs will be swapped to the primary flash.
So this needs to be done after the rootfs is umounted.

Add reset-cs0-aspeed to insert a line in `/run/initramfs/shutdown`
to write non-zero to /sys/class/watchdog/watchdog1/access_cs0.

Tested: Verify that the BMC is reboot to the primary flash after
flashing in the secondary image.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I4c988017ed45131318625f349a84500e1831e171

show more ...

dual-image: remount alt partitions during update

When the BMC is to updating the alt image, it needs to stop the sync
manager, umount the rofs/rwfs-alt partitions before the flashing,
mount them aft

dual-image: remount alt partitions during update

When the BMC is to updating the alt image, it needs to stop the sync
manager, umount the rofs/rwfs-alt partitions before the flashing,
mount them after it's done, and restart the sync manager.

Otherwise the mount point of rofs/rwfs-alt will get error because the
content is updated.

Tested: Verify the rofs/rwfs-alt are umounted during the alt flashing,
and are mounted again after the flashing is done, and the sync
manager is restarted.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I21e2bd8e0616cf529b9b4e5245d5da1ea4dfb51e

show more ...

dual-image: Implement BMC update when running on secondary

Implement the BMC code update when it's running on the secondary image.
It will update the alt flash by obmc-flash-bmc-alt@.service and
wai

dual-image: Implement BMC update when running on secondary

Implement the BMC code update when it's running on the secondary image.
It will update the alt flash by obmc-flash-bmc-alt@.service and
wait for the completion.
After the update is done, it needs reboot to take effect.

Note if the BMC is running on the secondary, it requires a following
commit to reset the CS to make the SoC to boot from the primary flash.

This commit only flashes the alt image when it's running on the
secondary image, there will be future commits to support other cases,
e.g. flashing both images.

Tested: Verify the code update process is successful and it flashes the
whole primary chip when the BMC is running on the secondary
chip.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: Ifa849e55c28f17b46d7f999ff43a7ad7e73f2ea1

show more ...

dual-image: Remove the functional check on delete

The code was checking if the version is functional and report error on
delete a version.
It worked OK because there will not be a case to upload a s

dual-image: Remove the functional check on delete

The code was checking if the version is functional and report error on
delete a version.
It worked OK because there will not be a case to upload a same version.

For the dual image case, it is possible to upload a version that has
the same version as either primary or secondary flash, so the check will
prevent deleting the version that is uploaded if it has the same
version.

The check is actually not necessary because the versions it manages are
always uploaded and thus are always OK to remove.

Tested: Verify it is possible to delete a version that is uploaded and
has the same version string as the running image.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I429eb34d18a7372b71463723fcaadbc7fd879164

show more ...

dual-image: Sync files before sync-manager starts

The sync-manager only sync files when it's changed/deleted, but does not
sync when it's untouched.
If the service starts and there is no change, the

dual-image: Sync files before sync-manager starts

The sync-manager only sync files when it's changed/deleted, but does not
sync when it's untouched.
If the service starts and there is no change, the files will not be
synced.

Mount the rwfs-alt and add a script to sync the files before the
sync-manager starts, so that they are always synced when the
sync-manager is running.

Tested: Verify the files are synced before the sync-manager starts.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I5613738b7b490201c556a175425b48aebae1505b

show more ...

dual-image: Add alt-rwfs-dir config

Add alt-rwfs-dir in meson config to specify the alt-rwfs dir, and set to
ALT_RWFS in config.h

Then sync-manager will sync files to expected directory for the
sec

dual-image: Add alt-rwfs-dir config

Add alt-rwfs-dir in meson config to specify the alt-rwfs dir, and set to
ALT_RWFS in config.h

Then sync-manager will sync files to expected directory for the
secondary flash.

Tested: Verify the /etc/hostname is synced to
/run/media/rwfs-alt/cow/etc/hostname when it is changed.
Note: the sync-manager only sync files when it's updated.
Ideally it should sync files once before the service starts to
make sure the files are always in sync.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I4aee549d339d17529d17e1ec2d9f100ec6b36f07

show more ...

dual-image: Set priority for primary and secondary flash

Set priority to 0 for primary and 1 for secondary, whatever the BMC is
running on which flash.
This is done by checking the running slot and

dual-image: Set priority for primary and secondary flash

Set priority to 0 for primary and 1 for secondary, whatever the BMC is
running on which flash.
This is done by checking the running slot and the functional state,
where:
* If the image is functional and the running slot is 0, it's primary;
* If the image is not function and the running slot is 1, it's primary;
* Other cases, it's secondary.

Tested: Verify the above behavior when BMC is running in primary flash
and in secondary flash.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: Ifee67377c15f7f92772ccde34d8abffb986c5f1f

show more ...

dual-image: Detect the running image slot

Add detect-slot-aspeed to detect which slot it is running on, and
assign the member variable, which will be used in future commits.

Tested:
* In normal

dual-image: Detect the running image slot

Add detect-slot-aspeed to detect which slot it is running on, and
assign the member variable, which will be used in future commits.

Tested:
* In normal case, verify the primary slot is 0 and secondary slot
is 1.
* Manually assign value 1 in /run/media/slot, and verify the slot
number is reversed.
* Manually trigger wdt2 timeout and verify in secondary flash that
the slot number is correct, that the running slot is 1 and the
other slot is 0.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I69edb1961b4c4bb79e7897c38b9ce8dded42f829

show more ...

dual-image: Do not erase image if os-release is not found

The code will erase an image if the os-release is not found.
For dual image, the secondary flash may be empty or contains invalid
data, e.g.

dual-image: Do not erase image if os-release is not found

The code will erase an image if the os-release is not found.
For dual image, the secondary flash may be empty or contains invalid
data, e.g. in factory or lab, so it should just ignore such case instead
of erasing the image.

Without the change, when it tries to erase the image, it crashes in
erase() because the version ID is not available and the code was
accessing the invalidated iterator.

Tested: Verify the crash is fixed in QEMU when the secondary image is
empty.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I7a1a8da15c31045fc7d51416f6ba0875349067d2

show more ...

dual-image: Always create os-release symlink

Create os-release symlink in processBMCImage() so that the functional
image is always available.

Without this change, processBMCImage() will find the al

dual-image: Always create os-release symlink

Create os-release symlink in processBMCImage() so that the functional
image is always available.

Without this change, processBMCImage() will find the alt image first, and
skip checking the os-release file in the running image. This results in
the missing DBus object for the running image.

Tested: Verify the two objects are created for BMC running and alt
images.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I07e9df4ad07ede36b13a8f447618b569ec446b86

show more ...

dual-image: Mount alt dirs

To support dual image in static layout, it needs to mount secondary's
rofs/rwfs.

Update obmc-flash-bmc tool to support mounting 'alt-xxx' directories in
/run/media/alt-xx

dual-image: Mount alt dirs

To support dual image in static layout, it needs to mount secondary's
rofs/rwfs.

Update obmc-flash-bmc tool to support mounting 'alt-xxx' directories in
/run/media/alt-xxx, and try to mount the alt-rofs, alt-rwfs before
xyz.openbmc_project.Software.BMC.Updater.service starts.

The ExecStart command is prepended with `-` so that it does not matter
if the mount fails, because the alt chip may be empty or contain invalid
data.

Tested: Verify the obmc-flash-bmc-static-mount-alt.service starts before
xyz.openbmc_project.Software.BMC.Updater.service, and verify it
mounts alt-rofs for dual image systems.
The alt-rwfs will be mounted by the needed service in future
commits.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I2133a99d5324a1008c3508154f865ae54a716219

show more ...

item_updater: Fix crash in updateUbootEnvVars()

In 25773a7 there is a change in updateUbootEnvVars() to use
versions.find(versionId)->second->path() as the flashId to update.

However, the function

item_updater: Fix crash in updateUbootEnvVars()

In 25773a7 there is a change in updateUbootEnvVars() to use
versions.find(versionId)->second->path() as the flashId to update.

However, the function may be called with an invalid versionId, e.g. if
the BMC has only one activation for static layout, resetUbootEnvVars()
will not find a valid `lowestPriorityVersion`, and it will pass an empty
string to `updateUbootEnvVars()`.

Fix the issue by adding a check and return if there is no such version
found.

Tested: Verify the BMC code update for static layout with one flash is
OK.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I4bf8240fefca3ae919024a61e45cfe3d29ed01e7

show more ...

updater: Add activations after versions

When the interfaces added signal is created, it contains all the
interfaces on that path. That means that when the activations map is
created, there's a inter

updater: Add activations after versions

When the interfaces added signal is created, it contains all the
interfaces on that path. That means that when the activations map is
created, there's a interfaces added signal with the Activation property
in it. Then if versions is added after that, the interfaces added signal
will list the new properties such as ExtendedVersion, plus the existing
ones like Activation. This causes bmcweb to create 2 tasks for the
update Redfish call because it watches for the Activation property in
the interfaces added signal.

By adding versions first to d-bus, the Version properties are exposed to
d-bus first, then adding activations triggers interfaces added with the
Version properties plus the new Activation ones, so the Activation
property only appears once.

By coincidence, processBMCImage() inserts versions first, then
activations. It was likely not done on purpose but works out and there's
no need to change it there.

Tested: Verified Activation only showed up once in interfaces added with
busctl monitor and verified only one task
(GET https://$bmc/redfish/v1/TaskService/Tasks/) was created when
calling the UpdateService Redfish API.

Change-Id: I3a9e0c109b19ad7ad8d8041404b899a988e14368
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

ItemUpdater::erase() : Fixed double delete

In some cases, when the erase function is called, it attempts
to erase an image that is no longer present on the bmc. This
results in the following error "

ItemUpdater::erase() : Fixed double delete

In some cases, when the erase function is called, it attempts
to erase an image that is no longer present on the bmc. This
results in the following error "Error deleting image (/xyz/
openbmc_project/software/xxxxxxxx) from image manager: sd_bus_call
noreply: org.freedesktop.DBus.Error.UnknownObject: Unknown object
'/xyz/openbmc_project/software/xxxxxxxx'". This function should
only be attempting to erase images that exist.

Tested:
Case 1: When activating a new image and the process calls the
erase function on its own
Case 2: When calling delete from the BMC command line
Case 3: When calling delete all from the BMC command line

All of the above cases did not throw the aforementioned error

Signed-off-by: Zami Seck <zimzam17@gmail.com>
Change-Id: I66f8734bcaf8cf31f2b009e53c20d59ee26fd5ad

show more ...

Support uploading same image for multiple times

The code was unable to upload the same image for multiple times because
it has the same version ID.

Add a salt when generating the version ID so that

Support uploading same image for multiple times

The code was unable to upload the same image for multiple times because
it has the same version ID.

Add a salt when generating the version ID so that we could get different
version IDs for the same image, and thus it is possible to upload the
images for multiple times. Use a random generator with the time as seed
to ensure uniqueness.

When the image updater starts up, use the mount directory name or
functional suffix as seeds to make the version ids unique.

The version ID is then necessary in the version object because the Delete
interface needs it when the version object is to be deleted.

With this change, it is possible to upload and update the same image for
multiple times, and systems with dual BMC chips could have the same image
as well.

Tested: Upload a same image for multiple times and verify all the
uploads are OK and getting different DBus objects;
Verify it is OK to delete the uploaded images by deleting the
DBus objects.
Verify the code update works on all layouts and that the flash
id (Path property) was set.

- static
root@romulus:~# busctl --no-pager introspect \
xyz.openbmc_project.Software.BMC.Updater \
/xyz/openbmc_project/software/79139bc0
...
.Path property s "9e3b868e"

root@romulus:~# ls -l /run/media/rofs-9e3b868e-functional/etc/
lrwxrwxrwx 1 root root 15 Jan 22 20:11 os-release ->
/etc/os-release

- ubi
root@witherspoon:~# busctl --no-pager introspect \
xyz.openbmc_project.Software.BMC.Updater \
/xyz/openbmc_project/software/151bc3d8
...
.Path property s "cfb85943"

root@witherspoon:~# df
/dev/ubiblock0_0 18816 18816 0 100% /media/rofs-cfb85943-functional
/dev/ubiblock4_0 18816 18816 0 100% /media/rofs-26085328

root@witherspoon:~# cat /var/lib/phosphor-bmc-code-mgmt/cfb85943/priority
{
"priority": 0
}

- mmc
root@p10bmc:~# busctl --no-pager introspect \
xyz.openbmc_project.Software.BMC.Updater \
/xyz/openbmc_project/software/cb5f99e2
...
.Path property s "b"

root@p10bmc:~# df
/dev/mmcblk0p5 202095 153782 33107 82% /media/rofs-b-functional

root@p10bmc:~# cat /var/lib/phosphor-bmc-code-mgmt/b/priority
{
"priority": 0
}

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Change-Id: I76842de4d5b7c5175acc43ed7c57e0deb4057be5

show more ...

Determine functional versions from mount directory

In order to support the same version on the primary and backup flash
locations, the version string is not enough to determine which version
is func

Determine functional versions from mount directory

In order to support the same version on the primary and backup flash
locations, the version string is not enough to determine which version
is functional. Therefore add a functional suffix to the mount directory
of the functional and use that to set the Version as functional.

Tested: The mount directories indicate which version is functional,
associations look correct.

- static:
root@romulus:~# ls -l /run/media/rofs-79139bc0-functional/etc/
lrwxrwxrwx 1 root root 15 Jan 22 20:11 os-release ->
/etc/os-release

root@romulus:~# busctl call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/software/functional org.freedesktop.DBus.Properties
Get ss xyz.openbmc_project.Association endpoints
v as 1 "/xyz/openbmc_project/software/79139bc0"

- ubi
root@witherspoon:~# df
/dev/ubiblock0_0 18816 18816 0 100% /media/rofs-cfb85943-functional
/dev/ubiblock4_0 18816 18816 0 100% /media/rofs-26085328

- mmc:
Verified functional association is correct, the rofs directories are
still unmounted after the bmc updater starts.

Change-Id: I8114a86b36ca1c6b1634b01fcce3cef0a2369eca
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

Use flash id to write image to flash

Update the item updater helper functions to take the flash id instead of
the version id since flash id is the name of the volumes/partitions.

The flash id was b

Use flash id to write image to flash

Update the item updater helper functions to take the flash id instead of
the version id since flash id is the name of the volumes/partitions.

The flash id was being persisted for the mmc layout with the name of
"partlabel". This is not needed anymore since the flash id is now being
passed by the service files.

The write functions/service files still use the version id to know where
the image files are located in /tmp/. They then set the value of flash
id (Path property) which is then used by the other functions such as
Delete and setting the u-boot environment variables.

Tested: Code update and Delete functions work on ubi and mmc.

Change-Id: I87c5b8ae2e24af30256dc3b436859835f14cda05
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

serialize: Use flash id instead of version id

Update the serialize functions to take the flash id instead of the
version id since version id can be different every time the BMC boots up
once support

serialize: Use flash id instead of version id

Update the serialize functions to take the flash id instead of the
version id since version id can be different every time the BMC boots up
once support for uploading the same version is added.

For the erase() function, if the flash id cannot be determined, it won't
be able to clean up the serialize directory since it doesn't know the
name for it, but this should be a rare scenario since the flash id (Path
property) is set when the BMC boots up.

Tested: The serialize directory name remains the same for ubi (version
id), and it changes to "a" or "b" for mmc. The priority of the versions
are found and restored upon reboot.

Change-Id: Ic2bd39caadbf7147e30200be8c4080f2b030c17a
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

updater: Introduce the concept of flash id

There is a desire to be able to upload and update the same image to the
BMC. This would require to generate different version ids for each, not
tied to the

updater: Introduce the concept of flash id

There is a desire to be able to upload and update the same image to the
BMC. This would require to generate different version ids for each, not
tied to the version string. In order to correlate a version with the
persistent data on flash, introduce the concept of flash id.

Flash id is the name or id of the flash location where the image was
flashed, it could be a volume name, partition name, mtd device name,
etc.

Use the updater version Path property for the flash id value. A d-bus
property is needed so that obmc-flash-bmc can save the value once it
determines the location to flash the new image. The version Path
property is empty when the BMC boots up, and it's set to the image path
in /tmp/ when an image is uploaded. This change will set the Path
property to the location where the image resides when the BMC boots up,
and it'll update the Path property from /tmp/ to the location on flash
for an uploaded image once that image was successfully written to flash.

The ubi volume names are based on the uploaded version id, keep this the
same for simplicity, the flash id would then be the version id of the
uploaded image (which would eventually be a random number). The mmc
partitions are named rofs-a/rofs-b, so the flash id would be "a" or "b".

Tested: Verified the Path property was set to the version id on ubi and
to "a" or "b" on mmc.

Change-Id: I11ccdb829c3c5204a58f24f3383db0045d8687ea
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>

show more ...

cleanup: Fix warnings found by cppcheck

Fix various warnings found by cppcheck.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I4db2319f5890d7aa73c8f418f610a6cba338ce24

meson: Fix deprecated meson warnings

Fix the warnings related to deprecated meson functions:

WARNING: Project targeting '>= 0.57.0' but tried to use feature deprecated since '0.56.0': Dependency.ge

meson: Fix deprecated meson warnings

Fix the warnings related to deprecated meson functions:

WARNING: Project targeting '>= 0.57.0' but tried to use feature deprecated since '0.56.0': Dependency.get_pkgconfig_variable. use Dependency.get_variable(pkgconfig : ...) instead
WARNING: Project targeting '>= 0.57.0' but tried to use feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.

Tested: Verify that there are no such warnings in local CI.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: I1388aaa12161d020d06657e507ddef78cb116ffe

show more ...

Add GeorgeLiu as the Reviewer

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I3a0cafb448f3d34273b066b1017a823a204cc9ea

usb: Add service and rules files

Trigger the USB code update via udev rules. Once a USB flash drive is
plugged into the BMC, an sda1 device is created, starting the USB
service file. Use SYSTEMD_WAN

usb: Add service and rules files

Trigger the USB code update via udev rules. Once a USB flash drive is
plugged into the BMC, an sda1 device is created, starting the USB
service file. Use SYSTEMD_WANTS since this service is long running.

Use BindsTo and After dev-sdX in the service file so that it
automatically stops when then USB drive is unplugged. Also add a
dependency to start after the Version service, which creates the
/tmp/images directory to copy the image to, and after the Updater
service, which handles the update.

Every time a USB drive is plugged, Linux creates a device sda1, sdb1,
sdc1, etc. Add rules for only the first 2 plug attempts, in case the
user made a mistake with the first USB drive as that seems sufficient.
If the second attempt does not work, the user would need to reboot the
BMC to retry.

Tested:
- Inserted USB key and verified the code update started and finished
successfully:
Dec 03 19:29:44 p10bmc kernel: sda: sda1
Dec 03 19:29:44 p10bmc kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk
Dec 03 19:29:44 p10bmc systemd[1]: Created slice Slice /system/usb-code-update.
Dec 03 19:29:44 p10bmc systemd[1]: Started FW Code Update via USB sda1.
Dec 03 19:29:50 p10bmc phosphor-version-software-manager[544]:
Untaring /tmp/images/obmc-phosphor-image-rainier.ext4.mmc.tar to
/tmp/images/imageM6FtSg
...
Dec 03 19:30:42 p10bmc phosphor-image-updater[470]: BMC activation
has ended - BMC reboots are re-enabled.

- Removed USB key and verified usb sda1 service stopped:
Dec 03 20:30:52 p10bmc systemd[1]: usb-code-update@sda1.service:
Deactivated successfully.
Dec 03 20:30:52 p10bmc systemd[1]: Stopped FW Code Update via USB sda1.

- Reinserted USB key and verified code update started with device sdb1:
Dec 03 20:31:05 p10bmc kernel: sdb: sdb1
Dec 03 20:31:05 p10bmc kernel: sd 1:0:0:0: [sdb] Attached SCSI removable disk
Dec 03 20:31:05 p10bmc systemd[1]: Started FW Code Update via USB sdb1.
Dec 03 20:31:11 p10bmc phosphor-version-software-manager[541]:
Untaring /tmp/images/obmc-phosphor-image-rainier.ext4.mmc.tar to
/tmp/images/imagey2OFWQ

- Removed USB key and verified usb sdb1 service stopped:
Dec 03 20:32:38 p10bmc systemd[1]: usb-code-update@sdb1.service:
Deactivated successfully.
Dec 03 20:32:38 p10bmc systemd[1]: Stopped FW Code Update via USB sdb1.

- Rebooted BMC with the USB drive inserted and verified the code update
started when the BMC booted after the software services started, and
the usb code update finished by the time the BMC reached Ready state:
[ OK ] Started OpenBMC Software Update Manager.
[ OK ] Started Phosphor Version Software Manager.
[ OK ] Started FW Code Update via USB sda1.

- Verified the usb service exited on error and a code update can be
restarted:
root@p10bmc:~# systemctl status usb-code-update@sda1
● usb-code-update@sda1.service - FW Code Update via USB sda1
Loaded: loaded (/lib/systemd/system/usb-code-update@.service; static)
Active: active (exited) since Fri 2021-12-03 21:26:19 UTC; 2min 31s ago
Process: 523 ExecStart=/usr/bin/phosphor-usb-code-update --device
sda1 (code=exited, status=0/SUCCESS)
Main PID: 523 (code=exited, status=0/SUCCESS)
Dec 03 21:26:19 p10bmc systemd[1]: Started FW Code Update via USB sda1.
Dec 03 21:26:19 p10bmc phosphor-usb-code-update[523]: Error when
copying /run/media/usb/sda1/obmc-phosphor-image-rainier.ext4.mmc.tar to
/tmp/images: filesystem error: cannot copy file: No …r.ext4.mmc.tar]
Dec 03 21:26:19 p10bmc phosphor-usb-code-update[523]: Failed to FW
Update via USB, usbPath:/run/media/usb/sda1

Signed-off-by: George Liu <liuxiwei@inspur.com>
Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Change-Id: I733f1b0f217f4fdd2f99cc6e8bbd602085da407d

show more ...

usb: Update the RequestedActivation property

Subscribe to the add software interface, when an update is detected,
call back the updateActivation method and verify whether it needs
to be updated. If

usb: Update the RequestedActivation property

Subscribe to the add software interface, when an update is detected,
call back the updateActivation method and verify whether it needs
to be updated. If necessary:
1. Set ApplyTime to OnReset to prevent the bmc from restarting
immediately after the update.
2. Change the RequestedActivation attribute value and start to update
the image bmc.

Tested: Manually start the phopshor-usb-manager daemon, and saw that
the bmc upgrade file(*.tar) has been copied to /tmp/images and
the update has been triggered, and bmc has not been restarted
immediately.

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: Ic650e34f8ec61d3c826332d28275db90f9ef348e

show more ...

usb: Add utility for D-Bus

Putting all D-Bus related operation to the utils file.

Tested: Call the set/getProperty functions locally and successfully
set/get the corresponding attribute value.

Sig

usb: Add utility for D-Bus

Putting all D-Bus related operation to the utils file.

Tested: Call the set/getProperty functions locally and successfully
set/get the corresponding attribute value.

Signed-off-by: George Liu <liuxiwei@inspur.com>
Change-Id: I0e0c33fd6ec5db3a47babaf417b0c708709e580b

show more ...