as the number of Reform users grows, I think it would be nice to start collecting some of the bigger long-term issues in a more structured way than this forum allows. This is both to:
allow users who want to help find out where help is needed
provide a place to point users to who are experiencing the issue
Can you think of more issues like this which are long-term problems, they are hard to debug and we only have workarounds to manage them? If you do, either open up an issue yourself in the relevant issue tracker on source.mnt.re or list them here, so that I can submit the issue myself.
YES! This is exactly what i was looking for! There are these sort of issues which have a workaround and are now so normal that one forgets that they even exist. I opened an issue here:
I’m aware of the additional work that this needs, but it would be really cool to have all the issues listed in the first post and to add a second list for issues that have finally been resolved (including a link to information about the solution).
I would like to add issues resuming from suspend-to-RAM where the display (?) doesn’t come up, leading to a freeze. Iirc this worked for some but not others, and there were workarounds. Do you want me to look up the thread(s)?
Since my upgrade to the A311D, I believe that suspend is not supported at all with this module, so I have stopped looking into it, but I would still be very much interested in that feature.
Same with boot from eMMC from the A311D – I believe it is possible, but not yet supported by official scripts to safety reasons?
I think the respective issue trackers are a better place to collect and categorize these problems than the forum. I like to avoid duplication but if there is somebody who’d like to do the work of keeping a copy of the data in the forum up-to-date than who am I to stop them.
I think it only makes sense to open issue reports for problems that can be fixed. For example for the MNT Reform 2 with i.MX8MQ it was shown that even when running the same vanilla SD-Card image, for some users suspend works and for others it did not. I swapped my own imx8mq module (which had suspend not working) to a different motherboard and it still did not work. This suggests that the problem is the imx8mq module itself. Maybe small manufacturing errors? In any case, this is unlikely to be something that MNT or us users can fix. So instead of having an issue open (which should be actionable) I think it makes more sense to track the current status in a wiki page:
To my knowledge, the only platform where suspend was more reliable was the imx8mp in the pocket reform. This is likely something fixable but I’m sure @minute has this already near the top of their TODO list.
This as another non-actionable item because the banana pi is built in a way such that you will soft-brick the board if you happen to flash a non-working u-boot to it. If you do that, you need some extra hardware to get a working system back.
Thanks for the clarification and with that in mind I agree with your assessment.
Weirdly enough, for me the imx8mq resumed (mostly) fine for about the first year or so and then started exhibiting issues much more frequently. So I thought it must have a software root cause that got introduced with some update, but that has always been more of a hunch…
Concerning the eMMC-boot in the A311D, what hardware is needed to reflash a broken uboot? I might be tempted to give that a shot at some point…
Yes, suspend (well, actually the resume part) did not always work. There was a period where it worked more and where it worked less reliably but we didn’t change anything related to suspend in the reform-specific bits but suspect that this is just something that varies with the kernel version. For example @2disbetter for a long time stayed with the 5.12 kernel as that was very reliable. Things then got worse somewhere between 6.1 and 6.5 and I hear from @disbetter that things are better again these days with 6.6 and 6.8? But it is unclear which bits made it worse or better. It is a bit of a roulette which is unfortunate…
One way to unbrick it would be via the CM4 IO board. A cheaper way would be by using one of these:
Which also seems to be sold for 5 bugs here:
Essentially this is a modified HDMI Display Emulator dongle with the A1 pin (pin 2 of the AT24 EEPROM) connected to VCC (pin 8 of the AT24 EEPROM). The dongle is available for 3 bucks on aliexpress:
I just remembered another issue which has a workaround and is thus something which I do not even think of anymore but which can theoretically be fixed by somebody with enough knowledge and free time:
This is precisely what i want to write down. These kind of issues have workaround which normalize them to the point where one forgets they even exist. But they can be fixed.
EDIT: Another one of the same kind. It’s fixable, it is a long standing issue (since October 2023), it just needs somebody to sit down and doing the work but the issue is not bothersome enough such that somebody has done the work yet:
This existed since forever but there are workarounds, so I don’t even notice this thing anymore. But this will be something that is surprising for new users coming from normal computers.
I have thought of some more bugs; On some (most?) of the SOMs, u-boot cannot output to the built-in screen nor can it accept input from the built-in keyboard.
This has been fixed for i.mx8mq quite a while back. But both ls1028a and i.mx8mplus are still suffering from this.
Would be great if that would get fixed some time. Probably not a very realistic goal for the more obscure SOMs like the ls1028a, but for something like the rk3588 I could see someone putting in the effort.
Haha thank you @vimja! Signs of using the Reform for too long: you forget that a normal computer switches on the display very early during boot and are completely content with only Linux doing it much later:
Display support is not only nice to better debug early boot issues and access the u-boot console but also for being able to select between multiple kernels using u-boot-menu.
