I am a big fan, but I also find this situation and the response to be a bit disappointing.<p>I highly respect Martijn and the effort he has poured into pmOS and Pine64 and surrounding projects. Without wanting to make other important people feel left out, I consider him an absolute legend and the fact that he has felt compelled to write this blog post (and, unfortunately, to leave) is massively concerning.<p>I think it's very possible that there has been no malice here and it's all just an accident of one thing leading to another, but something has gone awry here and I think it would be nice to hear what Pine intend to do to put it right, or to know that there is such a plan at all.<p>> As for the reason why Pinebook Pro doesn’t ship with a bootloader on SPI – it isn’t caused by favoritism for a particular group of developers or disregard for good ideas, but rather something more trivial. Namerly, a functional Tow-Boot build for the Pinebook Pro wasn’t available at the time of manufacture and shipping.<p>One particular point I want to make: I'm willing to believe Pine about the above, but it's too late to hear about this <i>after</i> crucial people have been miffed. This seems to indicate that communication with the various projects has not been good. This seems like a crucial thing to improve on to prevent this recurring.<p>I don't have enough knowledge of the situation and am incapable of making any judgements as to what is really going on, but I sincerely hope that Pine will consider this situation carefully and whether something can be done to put things right again.<p>I really wish to see Pine and their hardware do well and flourish. That was never going to be easy, but it will be even less easy with the loss of people like Martijn.
This is a disappointing response. I don't have a horse in this race (besides wanting to have access to good hardware for FOSS platforms), but I do have my ear on the ground in this community, so here are my thoughts on this.<p>> [removing SPI] was based on the fact that for years SPI was largely unused on PINE64 devices.<p>People have been arguing that a u-boot firmware needs to be installed on that flash chip for years, too. Essentially <i>everyone</i> in the dev community has been pushing them to do this for essentially the entire lifetime of their product line.<p>Would you rather find, download, and flash a special-purpose, pinebook-specific image onto a microSD card, pop it in, and boot that up to install a distribution, or would you rather it supports a standard UEFI booting interface over USB, netboot, whatever else, like every other laptop can?<p>> We created a space for development talks to be held (as we always had)<p>My understanding from speaking to friends and colleagues who work with Pine64 is that these spaces are pretty toxic. Manjaro has the loudest voice and other projects don't get the respect they deserve. And I'm prepared to believe it if this flippant response quoted in Martijn's article is accurate: "people who want [an SPI chip] can just solder one on."<p>This is not the behavior that I expect from a project which claims to honor its community.<p>I'm very disappointed in this response and in PINE64 generally. I expected an apology and a promise to improve, and this isn't it. Pine, I believed in you from the start.[0] I thought you were better than this. The past few years of your behavior has disillusioned me to your project and I can no longer offer you my support.<p>[0]: <a href="https://drewdevault.com/2019/12/18/PinePhone-review.html" rel="nofollow">https://drewdevault.com/2019/12/18/PinePhone-review.html</a>
As an outsider with no insights (but owning a PineBookPro and considering a PinePhonePro), it surely looks like Manjaro is the king of the mountain - and that Martijn's blogpost is likely close to The Truth.<p>Listening and doing your own things anyways is the time-honored way of ignoring people...<p>Even as an Arch user (that hence "gets" Manjaro) that is sad :(
> The example given in the blog post supposes that the community team and Pine Store employees were firmly intent on removing SPI on the PinePhone Pro and coerced not to ship Tow-Boot.<p>I don't see where in Martijn's blog post that "coercion" was "supposed" at all. What he actually wrote:<p>> Negotiating this solution was hell. Manjaro is incentivized not to agree to this, since it cedes their sole control over the bootloader, and PINE64 listens to Manjaro before anyone else. Furthermore, PINE64 does not actually want to add SPI flash chips to their hardware. Apparently, there has been some issues with people using SPI flash as RW storage on the A64-LTS boards, which would be a support issue.<p>> After months of discussions between the community, Manjaro, and PINE64 leadership, we finally were able to convince them to ship the PinePhone Pro with an SPI flash chip with Tow-Boot installed on it.<p>He doesn't even claim that Manjaro objected <i>at all</i> to the idea of adding an SPI chip and preloading Tow-Boot on it; only that they have a possible vested interest in resisting it, and that PINE64 therefore also does for as long as it considers Manjaro the preferred OS for PinePhones.
I kinda feel like half of the message here is “We listen to our community, we just don’t always act on it.”<p>I realize that’s healthy, but the way they’re going about it makes me feel like they’re trying to weasel out of it or something.<p>I’m left with a mild feeling of disappointment and I’m not sure why.
> I may add that the decision was made among ourselves, without the input of any third parties or partners<p>Maybe this, right here, is actually a major part of the bigger problem and not exonerating like it seems to be intended<p>> The reasoning behind not including SPI on the PCB wasn’t motivated by any single project or outside source – it was based on the fact that for years SPI was largely unused on PINE64 devices.<p>So if they only talked amongst themselves, how could they have any idea of if the SPI was already being used or not?<p>> And yet, despite this, we agreed to include it on the PinePhone Pro because developers from multiple projects – postmarketOS being one of them – were adamant that it was an absolute necessity.<p>So yeah, sounds like if they had engaged earlier, a lot of unnecessary frustration and grief could have been completely avoided.<p>Unfortunately this post does not even hint at the more significant point in Martijns post, the one about the relationships between PINE64 and the community distributions.
Original post for context: <a href="https://news.ycombinator.com/item?id=32494659" rel="nofollow">https://news.ycombinator.com/item?id=32494659</a>
I think I'm on Team Pine here. I don't really understand the problem Martijn has. It seems to boil down to that they agreed to everything he wanted, just not fast enough?
As a veteran embedded engineer, I was shock to see that another variant of boot loader is being recommended.<p>I’m quite sure that the bootloop is more than fixable but have my doubts that SPI is not that option.<p>Tow-wut? Sounds something like “extoll-embrace-engulf” and Balkanization to me. Not to stand in the way, but if that fixes the low-charge/bootloop problem then so be it but it doesn’t.<p>Still have the PinePhone Classic, still works, on my anti-static pad, but it may not serve us much longer.
This seems easy enough, right? If the SPI chip is in shipped units, and tow-boot is available for it now, then it should be simple enough to ship out of the box starting with the next batch of hardware, and it should be simple enough to post official instructions for installing it from Manjaro. While that wouldn't change the past, it would fix things going forward and let Pine back their words with actions.
I get the feeling that Martijn's situation was very much death by a thousand cuts and that didn't quite get captured well by the focus on the SPI issue - which Pine64 seems to have defended reasonably well here.
I'm a bit confused by the whole bootloader situation. Locking down a bootloader on an open device seems quite bad, but what's the issue here exactly? The user can install any bootloader they want, can't they? I know the ARM bootloader system isn't anything like the PC bootloader system, but even if the bootloader is loaded from eMMC, in what way is the user impeded?<p>I would guess all the user should need to do to use their own bootloader is to pacman -R manjaro-arm-uboot and pacman -S pmos-uboot to hand over control of the bootloader image if you buy a device flashed with Manjaro, or overwrite the eMMC bootloader with one that manually tries to boot from the SD card before resuming normal boot?<p>It seems that the frustrations about Manjaro go further than just the bootloader but I don't really understand why a SPI flash chip would even be a necessity in the first place.
As a veteran embedded engineer, I was shock to see that another variant of boot loader is being recommended.<p>I’m quite sure that the bootloop is more than fixable but have my doubts that SPI is that option.<p>Tow-wut? Sounds something like “extoll-embrace-engulf” and Balkanization to me. Not to stand in the way, but if that fixes the low-charge/bootloop problem but it doesn’t.<p>Still have the PinePhone Classic, still works, on my anti-static pad, but it may not serve us much longer.
If they proved anything it was that they can’t build a phone. The world got a useless brick because politics. Whenever I read about the pinephone I somehow narrate it in the voice of Jordan Peterson