OT: SBBR Broadcom etc [New Subject]
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 <pete@akeo.ie
> > <mailto:pete@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
>
>
Reply to: