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
