Moderation note: I removed a rude post that contained swearing, personal attacks and was causing bad vibes here. I also set the person on “Ignore” as I have zero tolerance for such behavior.
As the person conflated moderation with censoring, and to show that I don’t have an issue with criticism per se, I will repeat a summary of their criticisms here, in a more objective manner, and some responses:
- MNT Reform was released with flaws/bugs.
That is true, and normal for most products. We are transparent about it and we have worked and are working on improving the product.
- MNT Reform misses its goal of being an “open source” device, as there is a piece of closed-source firmware that has to be loaded into the DDR PHYs embedded MCU on startup for training.
MNT Reform is still open hardware according to the OSHWA’s definition of open hardware; namely, the hardware design sources are available in a format editable by the public. The Boundary Devices i.MX8M SOM is a standard component that can be bought off Mouser.
Also, there are no binary drivers/blobs running on the CPU, which was a major goal and motivated the choice of i.MX8MQ in the first place; namely, open source GPU drivers (etnaviv), good documentation and mainline support compared to other options.
The FSF RYF program does not tolerate a firmware blob like the DDR PHYs because of the way their rules are structured. I will not argue about the rules, because if that’s a mental model that works for them and people who buy hardware according to RYF, that’s fine. I personally have a different model.
Moreover, LS1028A is around the corner, which you can theoretically combine with a framebuffer card to get to a blob free system if this is your major pain point.
- MNT Reform System Image is badly engineered because building the image requires a chroot for some steps.
I don’t really get the problem with this, sorry. Chroots and containers are just normal features of modern operating systems. Also, noone has to build their own image, one can just download it from our CI server.
- Debug output should go on screen, not a UART.
While this is an inconvenience, most people will never need to use this sort of debugging; and most embedded engineers are fine with using a UART. I would still be very happy about someone finishing bluerise’s work to bring the display to life in u-boot (one could, for example, port the pretty minimal code from 9front).
- There is no battery cutoff switch.
That is correct, but the newly released battery boards have MOSFETs that disconnect the batteries should they fall below a safe voltage, so it is no longer necessary to remove the batteries for storage.