A Rant About Pine, Other Distros, & Still Trying to Get Fedora Booting From eMMC.
12-06-2021, 04:08 AM
I'm sorry you ran into these issues and feel this way, and I can understand your frustration.
I'd like to offer some explanations and perspectives on the matter. Practically all software work being done for PINE devices is either volunteer work, or time-limited contract work (that may be funded by people other than PINE, I don't know who hires Collabora to work on Rockchip stuff). This means that eventually, the onus of supporting these devices falls onto the community. There is no person hired full-time at PINE64 to work on software because this would be a losing proposition; there's such a wide selection of different OS projects that providing continued software support for them all would be both impossible from a human resources and an organisation perspective.
What you can do when you found an issue in a software image for a PINE64 device is to report it to the project that's behind the software image. If they are keen on fixing the issue, they can even contact PINE64 directly if they need help with acquiring hardware; PINE has in the past sent out devices to volunteers so they could support specific distributions.
In your specific case, the bootloader not showing video output is likely related to the u-boot config; the bootloader needs a video output driver to be able to display something before the kernel starts, and this is controlled by a build-time config option. It's common that these get forgotten, as the people deciding on the distribution's bootloader build configs may not always be knowledgeable enough about the devices or have one to test it with. If the kernel doesn't print text to the screen, that's a bit more worrisome and points towards a module not getting loaded when it should.
As for eMMC, there's currently a problem with u-boot 2021.10. on ROCKPro64 specifically when it comes to eMMC booting. I believe Fedora have a patch for this applied, but I'm unsure about it. Either way, the fix has been posted to the u-boot mailing list, and is awaiting review. People are working on it. I am not entirely certain this specific issue is what you're running into (as Fedora already patched it on their side from what I've heard), but I thought it's worth mentioning.
As for debugging boot-up and such, video output is never the right answer. Get a 3.3V 1.5mbauds capable UART adapter such as the Woodpecker from the PINE store ($1.99), or any other such devices. They can be had for cheap almost anywhere. With UART, you get debug output regardless of whether something manages to initialise and use a very complex video output driver; it's just a text based interface as old as computers themselves.
I'd also like to disagree with
In my experience, this isn't true. There may be regressions in newer kernels, but people will fix them if told about it. The whole point of making sure your device runs mainline Linux and mainline u-boot is that it isn't just left by the wayside; you get to enjoy newer kernels for years to come.
As an example, I recently found and reported a regression in lima that was caused by the 5.16 kernel. Lima is the driver used by older ARM GPUs, such as the one found in the ROCK64. The problem was fixed within a day after I ran my git bisect on the kernel, before the regression ever made it into a release.
It's important to both understand how to pinpoint issues precisely and how to test proposed fixes; this allows people without the hardware (in my case, an AMD employee) to come up with a fix and verify that it works. I know this can be hard for people not familiar with all the components of the system, but usually we can help out debugging things like these in the PINE64 chats, where many knowledgeable people reside. They're a bit more real-time and laser-focused than the forums usually are.
In conclusion:
I'd like to offer some explanations and perspectives on the matter. Practically all software work being done for PINE devices is either volunteer work, or time-limited contract work (that may be funded by people other than PINE, I don't know who hires Collabora to work on Rockchip stuff). This means that eventually, the onus of supporting these devices falls onto the community. There is no person hired full-time at PINE64 to work on software because this would be a losing proposition; there's such a wide selection of different OS projects that providing continued software support for them all would be both impossible from a human resources and an organisation perspective.
What you can do when you found an issue in a software image for a PINE64 device is to report it to the project that's behind the software image. If they are keen on fixing the issue, they can even contact PINE64 directly if they need help with acquiring hardware; PINE has in the past sent out devices to volunteers so they could support specific distributions.
In your specific case, the bootloader not showing video output is likely related to the u-boot config; the bootloader needs a video output driver to be able to display something before the kernel starts, and this is controlled by a build-time config option. It's common that these get forgotten, as the people deciding on the distribution's bootloader build configs may not always be knowledgeable enough about the devices or have one to test it with. If the kernel doesn't print text to the screen, that's a bit more worrisome and points towards a module not getting loaded when it should.
As for eMMC, there's currently a problem with u-boot 2021.10. on ROCKPro64 specifically when it comes to eMMC booting. I believe Fedora have a patch for this applied, but I'm unsure about it. Either way, the fix has been posted to the u-boot mailing list, and is awaiting review. People are working on it. I am not entirely certain this specific issue is what you're running into (as Fedora already patched it on their side from what I've heard), but I thought it's worth mentioning.
As for debugging boot-up and such, video output is never the right answer. Get a 3.3V 1.5mbauds capable UART adapter such as the Woodpecker from the PINE store ($1.99), or any other such devices. They can be had for cheap almost anywhere. With UART, you get debug output regardless of whether something manages to initialise and use a very complex video output driver; it's just a text based interface as old as computers themselves.
I'd also like to disagree with
Quote:My only thoughts on the matter is as a new board appears from Pine an older one gets abandoned.
In my experience, this isn't true. There may be regressions in newer kernels, but people will fix them if told about it. The whole point of making sure your device runs mainline Linux and mainline u-boot is that it isn't just left by the wayside; you get to enjoy newer kernels for years to come.
As an example, I recently found and reported a regression in lima that was caused by the 5.16 kernel. Lima is the driver used by older ARM GPUs, such as the one found in the ROCK64. The problem was fixed within a day after I ran my git bisect on the kernel, before the regression ever made it into a release.
It's important to both understand how to pinpoint issues precisely and how to test proposed fixes; this allows people without the hardware (in my case, an AMD employee) to come up with a fix and verify that it works. I know this can be hard for people not familiar with all the components of the system, but usually we can help out debugging things like these in the PINE64 chats, where many knowledgeable people reside. They're a bit more real-time and laser-focused than the forums usually are.
In conclusion:
- I get it, I can see how this is frustrating, I've had to deal with it myself as well.
- Get a UART adapter.
- Ask in the PINE64 chats for help debugging issues; we're the most likely to have the same devices and can quickly look into it if need be. The forums are mostly where people go to complain about their PinePhone orders or whatever.
- Communication is key; if a problem is never reported to the responsible component, it'll likely never get fixed. This is a small user base, so it's possible you're the first to run into something.
- Maintainers of those components can always reach out to the PINE64 community and PINE64 themselves if they need help improving a certain aspect of their software.
Occasional Linux Kernel Contributor, Avid Wiki Updater, Ask Me About Quartz64
Open Hardware Quartz64 Model A TOSLink Adapter
Pi-bus GPIO Extender For ROCKPro64 And Quartz64 Model A
Plebian GNU/Linux
