Please continue this discussion under a different Subject. It has nothing to do with my original question.
Thanks! Rick On Sat, Feb 20, 2021, at 4:18 AM, Pete Batard wrote: > Hi Luke, > > On 2021.02.20 04:16, Luke Kenneth Casson Leighton wrote: > > > > > > On Friday, February 19, 2021, Pete Batard <p...@akeo.ie > > <mailto:p...@akeo.ie>> wrote: > > > > > Why, when it is absolutely possible to achieve it, as was > > demonstrated on a cheap platform like the Pi (that actually comes with > > horrible quirks to be able to accomplish so, especially in terms of xHCI > > support), should end users have to juggle with heteroclitic means of > > configuring their system for OS installation? > > > > because the product, designed by Broadcom, is not in the slightest bit > > targetted at end-users, and Broadcom do not give a flying f*** about > > such a tiny market of only 1 million a year in sales. their profit > > margins are too small to bother with us. > > I appreciate that you feel the desire to express your candid opinion. > > But I am afraid you are shoehorning the topic in order to be able to do > so as this was never a discussion about specific SoC manufacturers. > > This section was a discussion about how we used *whatever* ARM64 SoC > platform we saw as fitting (on account of it being cheap and widespread, > and nothing else) to demonstrate that SBBR is not just for vendors who > design server platforms and have a significant amount of resources. > > > Broadcom's Minimum Order Quantity for these processors, which are > > designed for mass-volume IPTV, Set Top Box and other multimedia > > computing appliances, is 5 million units and above. > > Irrelevant. > > > Normally Broadcom would provide the full software stack for the customer > > placing 5, 10, 50, 100 million orders for a complete solution. That > > customer *does not care* about the software boot process or some xHCI > > incompatibility. > > > > Have people forgotten already that the only reason the original PI > > exists is because Eben Upton was an employee who, having access to > > normally NDA'd documentation, worked on the PCB in his spare time? This > > was the only exception to Broadcom's normal MOQ rules, they could not > > exactly tell him to stop when he told them it was for educational > > purposes, could they? > > Still irrelevant. > > > please understand: the manufacturers of these SoCs consider you, all > > Free Software idiots (including me) to be an absolute nuisance. > > Yes. We know. > > But, and here's the kicker that you appear to ignore in order to go on > this tangent, we have demonstrated that one can *still* provide an SBBR > UEFI implementation for platforms where vendors are less than cooperative. > > And this is kind of the point: If we could achieve it for a platform > where we got little cooperation (for the record, even if it's in their > interest, I wouldn't say that the Raspberry Pi Foundation are exactly > onboard with the SBBR effort, which may have to do with it having been > developed externally), then it means it should also be achievable for > others. > > The point is: It is possible to get SBBR even from relatively > uncooperative vendors. > > And the fact that Broadcom are, per your description, one of the less > friendly manufacturers when it comes to Open Source software helps bring > the point home. > > But please understand, we could also have picked the manufacturer that's > friendliest for FLOSS, and it wouldn't have made much of a difference. > > With the goal of demonstrating that you can pick this or that ARM64 SoC > based platform out there, and produce an SBBR-compliant UEFI firmware > for it, the choice or what platform was picked becomes largely > irrelevant and out of scope for this topic (except for the fact that it > coincided with the platform OP plans to use). > > > i showed the manufacturers of my laptop the linux kernel boot process at > > Computex, they told me it looked like i was spying on their product! > > > > we are "lapping at the heels" of these massive Corporations. we are > > nothing to them. > > I don't know who that "we" is, but if your idea is that the people who > are interested in showcasing SBBR went with a Broadcom-based platform, > with some desire to help their business, you are missing the mark. > > Again, we, as developers of this specific SBBR showcase, couldn't have > cared less about the SoC manufacturer (as long as we could obtain a > minimum level of information to allow for development, as, obviously, > "we" can't do miracles for a fully closed platform) and could have > picked the Librest SoC implementation just as well, if it made a good > showcase. > > But then, and that is part of the point, had we done just that, we > probably would have faced some pushback of "Well, your SBBR > implementation only works because the SoC manufacturer was open and > cooperative. But that's never going to work in the real world of > Broadcom, Qualcomm and Whoever-com..." > > In a sense, using the SoC from a corporation that looks down on Open > Source efforts is a boon, because it demonstrates that, as much as we > would like the SBBR effort to come from cooperative platform and SoC > designers themselves (and the established goal of producing an SBBR > compliant for the Pi 4 is precisely to show that this is easier to > accomplish than platform manufacturers may think), the community can > also bypass them if that's what's needed, in the same manner as the > community got together to ensure that Linux can be installed on > platforms where the manufacturers only cared about non Free/Libre OSes. > > > when we can place orders for a million processors, *then* they will > > listen to what you and I want, Pete. > > No. > > When we showcase what's achievable, and demonstrate that the cost of > achieving it might be a lot less than a company's estimate, as well (and > that is the most crucial point) that it can be greatly beneficial for > the end users of the platform (because this is something that, as > cynical as one can be on that topic, *might* ultimately translate to > profit), then they *may* listen to what *some* people want, which is to > make the means of installing and running OSes on ARM64 a lot more > user-friendly than it is now. > > > sorry if any of the reality check above shocks you. > > You are assuming a lot here. And I'm afraid that you are assuming very > very wrong. > > > personally i got > > absolutely sick of the ongoing callous pathological exploitation of our > > collective expertise, many years ago, > > I believe this is what you should have started with, because it then > makes your desire to go on this largely irrelevant tangent a lot clearer. > > > and started a new SoC initiative. > > it's entirely Libre. [and offtopic for the debian-arm list, so please > > if you would like to discuss that, contact me direct or on freenode > > #libre-soc]. > > And that is great. > > I can only wish you all success with it, and also that you will be > considering developing or helping people who want to develop an SBBR > compliant firmware, as (to come back to the actual topic since, once > again, *this* is the only goal we are interested in here) it should make > life easier for end users who are trying to install Libre operating > systems onto it. > > Regards, > > /Pete > >
