Community issue: Tivoization needs to be resolved

[GravisZro]

⚠️ Community issue

📝 Description

The Tivoization (inability to run unsigned code) of the Mudita Pure has become a significant community issue as it's been nearly half a year and there is still no word of when or even if it will be possible to load customized firmware. Being unable to load a custom firmware is by far the biggest issue for anyone interested in an open source phone. If you cannot run your own firmware then the source code is useless because you can neither customize nor debug your own phone. It's fundamentally undermining the raison d'être of having an open source product.

On a personal level, I have significant reception issues but it's impossible to identify the cause (so that that I may open an proper issue) because I cannot interact with the modem module to see if the displayed reception is correct or if the modem is functioning properly. I know the Pure was not intended to be development platform but creating impassible roadblocks for developers is most likely causing more problems than it's preventing.

📝 Describe the solution you'd like

A development mode similar to how Android works that allows your to run unsigned firmware. It doesn't matter if the bootloader starts displaying a huge disclaimer telling you not to report bugs, being able to run custom software is essential to anything claiming to be open source.

📝 Describe alternatives you've considered

A signed firmware that acted as a second-stage bootloader that let you boot another firmware would work.

[pholat]

The problem lies with the lack of tooling for users to use to run their own software, not with deliberate actions to forbid users from doing so. Hopefully, we will meet the day users will be able to fully change their software in MuditaOS. Thanks for rising this issue, we are raising it on regular basis - but the voice from the community might actually help to emphasize the problem.

[GravisZro]

The problem lies with the lack of tooling for users to use to run their own software not with deliberate actions to forbid users from doing so.

I presume you are speaking about the "Service Desktop" update function. Update via route is unsuitable for development because if the newly written firmware doesn't run the same lacks the same update functionality (or it's broken, crashes, etc.) then you can no longer update the firmware. This is only suited for end-user firmware updates.

To enable community-based development, the ability to update the firmware must be in the bootloader. Anything short of this will discourage development. Here's a description of a bootloader that would promote development:

Holding a specific key combination upon boot (while connected via powered USB) will cause the bootloader to activate a "development boot mode" on every boot (that is connected via powered USB) until disabled.

Development Boot Mode

• The bootloader should display an image confirming it's in development boot mode.
• If the right red button is pressed then the device reboots unconditionally.
• A rudimentary USB CDC serial port will be present (should have an identifier to indicate development boot mode)

Development Boot Mode serial port behavior

• Accepted commands:
  • write image to Device storage (transferred from PC)
  • read image from Device storage (transfer to PC)
  • load image to Device RAM (transferred from PC)
  • load image to Device RAM from Device storage
  • execute image in Device RAM
  • present Device as mass storage device
  • disable development boot mode
  • reboot Device
• Return command status upon completion

Development Boot Mode serial port implementation

• Serial communication should be extremely simple: commands are a single byte.
• Host to phone transfers commands data then it is followed by a transmission_t struct.
• Return status as one byte.
  • If byte the value is SP_FILE_BYTE (special byte value indicating file transmission) then it is followed by a transmission_t struct.
  • Success value is 0x00.
  • Other values should be assigned to specific errors.

The transmission_t struct.

  struct transmission_t
  {
    uint32_t crc32; 
    uint32_t data_size;
    uint8_t data[DATA_SIZE]; // DATA_SIZE is the value of transmission_t::data_size
  }

• The CRC algorithm should be CRC-32 as used by the cksum utility (it's quite simple and standard).
• All values are transferred in network byte order (big endian).

A bootloader based development mode like this would be robust enough to instill confidence that loading a bad firmware image isn't going to be the end of their device. Furthermore, the interface is simple enough that the interface utility could be a shell script, powershell script, or a simple C program. It's my understanding that the bootloader already contains much of what would be required to implement this interface.

[pholat]

@GravisZro It doesn't matter if it's a bootloader or updater. The latter is ready, verifies software md5 which is much better than crc, and does backup for you - so that in case of emergency you would be able to roll back your changes. For your convenience, you can see it as a secondary bootloader (it's not) specialized for handling the upload of data. So this is on the technical part, on the business part - there was a decision made that access to the bootloader (of primary bootloader for your convenience of thought) is not given to the users.

If you would want to change the software - the updater should easily suffice. Especially since there were plans to open source it. If you require better access to the platform, I suppose you should attach a debugger probe to it. We are using JLink for day to day software verification, but it shouldn't be very hard to attach any probe supported via pyopencd and upload & debug the software for nearly free - the problem is - we do not provide information about the debug socket - but if you would like to follow that route I would gladly ask for it's pinout.

[GravisZro]

and does backup for you - so that in case of emergency you would be able to roll back your changes

I'm a very curious about how it's rollback ability works. If I've uploaded a badly broken firmware via the updater and it doesn't even boot then how does the rollback function work? I can only figure it must be part of the bootloader functionality.

it shouldn't be very hard to attach any probe supported via pyopencd and upload & debug the software for nearly free - the problem is - we do not provide information about the debug socket - but if you would like to follow that route I would gladly ask for it's pinout.

You mean the eight connection pads by the Data Matrix code under the battery are JTAG? I had assumed these were merely for a programming jig. I would very much like the pinout information though just knowing it's a JTAG interface is enough to spur me to find out on my own if need be. This is great news! Now to make an interface PCB. :)

[kkleczkowski]

@GravisZro You have to enable bootloader and select factory reset option. To enable bootloader turn on the phone with confirmation button pressed ( central joystick button ). Detailed instruction: https://github.com/mudita/MuditaOS/blob/master/doc/running_on_phone.md