Consultation on Customizing the RP2350 BOOTSEL Mass Storage Mode

Hi everyone, We are developing a commercial product based on the RP2350 (Raspberry Pi Pico 2 W), and have encountered a question regarding customization of the BOOTSEL flashing mode. We are reaching out to the community for advice on the optimal solution. **Background** When the chip enters the native USB flashing mode via the BOOTSEL button, it is recognized as a mass storage volume labeled RP2350, which contains two fixed files by default: 1. INFO_UF2.TXT: Contains factory information including the chip model, bootloader version, and other Raspberry Pi official details. 2. index.htm: A file that automatically redirects to the official Raspberry Pi documentation page. **Core Requirements** For our commercial product, we need to customize the content of this flashing mode, specifically: 1. Customize the volume label to replace the factory RP2350 identifier. 2. Replace the content of INFO_UF2.TXT with our company's product introduction, firmware version notes, flashing instructions, and other custom information. 3. Replace the redirect target of index.htm with our company's official product website or technical support portal, or replace the file entirely with a custom document containing flashing operation specifications and usage precautions. **Current Identified Approach** The only feasible implementation path we have identified so far is a two-stage architecture with a custom secondary bootloader + user application: On power-up, the chip first runs our self-developed secondary bootloader, which can be triggered via a custom key combination to enter a self-developed USB MSC UF2 flashing mode, enabling full customization of the volume label and internal files. **Questions for the Community** 1. Beyond the custom secondary bootloader approach, is there a more native, lightweight implementation? For example, can we achieve the above customizations by modifying the factory BOOTROM configuration, or building a customized version of the official bootloader? 2. If the secondary bootloader is the only viable approach, are there any mature, production-proven open-source implementations in the community that we can reference? 3. Will customizing the volume label and internal files of the flashing mode impact the compatibility and stability of UF2 firmware flashing? Are there any common pitfalls we should avoid? Thank you in advance for your insights, solutions, and shared experience!