masking/removing machine.bootloader()

[scruss]

I have an application for a USB keyboard device for which MicroPython would be perfect. Except: one of the user requirements is that the device never present itself as mass storage, even as a UF2 boot loader device. Is there a way to hide the machine.bootloader() function without having to rebuild the MicroPython image?

The Bootsel button isn't a problem: we can cover/hide/remove it, as necessary. My worry is that a user could interrupt the running program, (somehow) gain access to the REPL, and be able to enter the bootloader from there. One of the locations where the device would be used has a very strong IT policy against removable storage of any kind. Having one detected on a machine sounds alarms, and could cause the user to lose their job.

[robert-hh]

You did not mention the port you use. As far as I can tell, there is not 100% foolproof way of doing so. Even if you remove the bootloader method from the sources, there is still the mechanism in ROM which starts the bootloader. But a Pythonic way may be (Inspired by ESP32 Encoder):

import sys

_path = sys.path
sys.path = ()
try:
    import machine as _machine
finally:
    sys.path = _path
    del _path
    del sys


# Delegate to built-in machine module.
def __getattr__(attr):
    if attr != "bootloader":
        return getattr(_machine, attr)
    else:
        return None

If you add that or call it in boot.py, it will get active before USB is initialized.

[scruss]

Thanks - this would be for RP2040, as stated in the Category

[scruss]

If you add that or call it in boot.py, it will get active before USB is initialized.

I just found out that the rp2 _boot.py that is hard-coded into the UF2 already imports the machine library, so any user-modified boot.py can't mask bootloader(). Otherwise, I'm sure this would have worked perfectly: thanks!

I think I'm going to have to proceed with warnings in the documentation and extreme care in my code that USB code can't break out into the REPL.

[robert-hh]

Starting boot.py with del machine will remove it. But of course, a command sequence like

sys.path=()
del machine
import machine

would restore the builtin machine module. The more robust way is to create a firmware without support for bootloader().

[mungewell]

You can re-build/compile the microPython uf2 with the UART REPL enabled, then the rp2040 does not present a REPL on the USB port.

I have example in the MTC version of my 'PT-Thrifty' project:
https://github.com/mungewell/pico-timecode/releases

If you want to go a step further; I accidentally discovered if you replace the XTAL with something that is not 12MHZ then USB timing is wrong and can not be connected to the PC.... even with 'boot' mode active. You can/have to connect via the SWD pins to (re)flash FW.

The timing of the USB port can be 'corrected' within a custom microPython, so it would still work for your application.

[robert-hh]

If you want to go a step further; I accidentally discovered if you replace the XTAL with something that is not 12MHZ then USB timing is wrong and can not be connected to the PC..

The intention of @scruss was to use the RP board as USB device. Disabling USB is therefore not an option.

[mungewell]

The point I was making about the XTAL frequency was that you can sabotage the ROM bootloader, causing it not being able to work. MicroPython can be compiled with knowledge of the frequency change, so that it can work correctly...

[mungewell]

Are you 100% for the RP2040?

The RP2350 has much strong security model, though I don't know if you can disable the 'boot' mode via the e-fuses...

[scruss]

would settle for either, but developing on RP2040 as that's what I have most of and they're cheap. I wouldn't want to have a permanently-burnt version of the firmware, which using fuses might suggest. Also, can we make use of the RP2350 security model in stock MicroPython? I'd very much like to keep this code usable with standard MicroPython

[mungewell]

I have no experience working with the e-fuses.... I believe that they would/could be controlled via 'picotool' application, after the user uploads their UF2 image(s).

[robert-hh]

I just cross-checked that at RP2 the bootloader cannot be enabled with the touch1200 method. Otherwise it could not be disabled with any MP variant.

[scruss]

Thanks! touch1200 would be a real problem for users in many government organizations