Gecko Bootloader can be upgraded either via UART or via Bluetooth as described here:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/04/26/upgrading_gecko_boot-IfFz

The following article discusses the special case when you want to upgrade your Gecko Bootloader via Bluetooth with an image that has different slot configuration than the previous Gecko Bootloader you used on your device.

To upgrade the bootloader with a new slot configuration is problematic, because the upgrade image is uploaded by the old bootloader to the old slot address, but after the bootloader upgrade the new bootloader tries to bootload the apploader image from the new address – this will definitely fail.

The following workaround can be used to solve this issue:

Suppose you want to upgrade from bootloader A, that has Slot0 address A, to bootloader B, that has Slot0 address B.

1. you have a bootloader with Slot0 address A in your device. This will upload the upgrade image to address A.
2. first you have to upgrade to a temporary multislot bootloader with Slot0 address B and Slot1 address A. This can bootload from address A but will upload the next upgrade image to address B.
3. finally you have to upgrade to the single slot bootloader with Slot0 address B, as originally intended. This can bootload from address B.

How to configure the temporary multislot bootloader:

1. create a new bootloader project. Use Bluetooth in-place OTA DFU Bootloader or Internal/External storage bootloader, as you normally do.
2. define the customer version string to N+1, where N is the version number of the original bootloader. You can do this by defining BOOTLOADER_VERSION_MAIN_CUSTOMER on the Other tab in the AppBuilder.
3. On the Storage tab define the slots. Define Slot0 to the new address (with the new slot size), and Slot1 to the old address (with the old slot size).
4. The multislot configuration needs a bootload info table that takes 8kB. It has to be defined somewhere outside of Slots and outside of the bootloader and apploader area. Go to Plugins page, select Common Storage, and define the Start address for bootload info to e.g. 8kB before the Slot with lower address. Make sure that the start address is aligned with the 2kB flash page size!
5. press Generate to generate your project
6. there is one more change needed. The bootload info table should be normally initialized by the app. This table tells which slots should be bootloaded in which order. Since there is no valid application image, however, after the bootloader upgrade, the bootloader code has to be modified:

• -find storage-common/btl_storage.c in your project.
• -right click on it and select „Copy Linked File into Project”. This will copy btl_storage.c and btl_storage.h into the project from the SDK.
• -in storage-common_inc/btl_storage.h change to following line

  #include "bootloadinfo/btl_storage_bootloadinfo.h"

to

  #include "plugin/storage/bootloadinfo/btl_storage_bootloadinfo.h"

• -in storage-common/btl_storage.c change the following lines

  ret = storage_getBootloadList(slotIds, BTL_STORAGE_BOOTLOAD_LIST_LENGTH);
  if (ret != BOOTLOADER_OK) {
    BTL_DEBUG_PRINTLN("BI err");
    return ret;
  }

to

  ret = storage_getBootloadList(slotIds, BTL_STORAGE_BOOTLOAD_LIST_LENGTH);
  if (ret != BOOTLOADER_OK) {
    BTL_DEBUG_PRINTLN("BI err");
    slotIds[0] = 0;
    slotIds[1] = 1;
  }

This will ensure, that the bootloader will try to bootload from Slot0 and then from Slot1.

7. build your project, and upgrade to this bootloader as normally, before upgrading to the final bootloader.

The final bootloader can be configured as normally, but make sure that its version number is N+2.