Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Mar 2021 13:09:22 +0100
From:      =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>
To:        Emmanuel Vadot <manu@bidouilliste.com>, Mark Millard <marklmi@yahoo.com>, Stefan Parvu <sparvu@kronometrix.org>, freebsd-arm@freebsd.org
Subject:   Re: RPi4 Status and sysutils/rpi-firmware
Message-ID:  <27E93DAE-54FD-4ECA-B8FF-B5D1180D05E0@googlemail.com>
In-Reply-To: <20210303091239.7bc66cfda6918215278c0899@bidouilliste.com>
References:  <20210302122057.86ba62bb1daa7f922134ecd9@bidouilliste.com> <3399FAC5-6594-4AF6-B9F1-F2CFAB3E64EA@yahoo.com> <D5CFC94B-32D1-4033-9001-5414C3270409@googlemail.com> <20210303091239.7bc66cfda6918215278c0899@bidouilliste.com>

next in thread | previous in thread | raw e-mail | index | archive | help


> Am 03.03.2021 um 09:12 schrieb Emmanuel Vadot <manu@bidouilliste.com>:
>=20
> On Tue, 2 Mar 2021 19:55:54 +0100
>=20
> Even if we find a version of the firmware files that works for every
> RPI boards that all of our users have right now, we will need to =
update
> them when a new RPI boards is out. And with the Compute Module 4 being
> out and a lot more carrier board being made than for the CM3 I expect =
a
> lot more firmware updates than before.
>=20

Exactly, and where=E2=80=99s the problem ?
There never was a firmware-problem which we couldn=E2=80=99t fix(or =
identify) quickly=20
and adopt patches(or remove broken files) in :
1.: the firmware itself
2. in Rob`s & Mike`s drivers
3. in u-boot
4. for older models by eeprom-upgrade
.. same for cm4, I would be willing to order one if things go better in=20=

rpi-maintenance. And if I don=E2=80=99t order, the new maintainer , =
whoever ,=20
will buy one and fix issues in one- day- fashion :-)
That=E2=80=99s what Rob, Mike, me, Mark Millard & bug-reporters did and =
it always worked.

>> I could also offer a dtb-patch
>=20
> Your earlier proposal was to commit into base a modified DTS based on
> (I think) a decompiled version of the rpi-firmware DTB and put that in
> place of the Linux mainline DTS (which is different) in the contrib
> device-tree import tree.
> This cannot work in the long time, if you don't see a problem I'm
> soryr for you.
>=20
If you would have had applied that patch ( in release of course, =
regardless where it=E2=80=99s source-file is in the src-tree)=20
you wouldn=E2=80=99t have heard of any unfixed fw-issue since then.
There is no mainline Linux in that sense, instead there are companies ,=20=

projects and individuals who apply patches as needed.
That=E2=80=99s common practice & that patch was based on the original by =
Nicolas Saenz Julienne of Suse linux.
It triggers an xhci-reset-function in u-boot, and who was the author of =
the u-boot-patch?
Right: the man from Suse linux.
So give a shi* on any mainline... the mainline for you and us  is =
FreeBSD so we pick exactly the files/patches=20
we need for ourselves. That=E2=80=99s what your linux-mainline is doing, =
OpenBSD, EDKII does it that way and absolutely everybody else is doing =
that. You only have to know what exactly is going on in rpi-org, u-boot,=20=

gnu, other BSDs and so on.=20

You can be sure you you will love your RPI again if you give the =
port-maintenance to Crowston , Millard, Karels or whoever has the =
background knowledge and passion to track what happens in rpi-world.

 Just buy a cm4 now, you will love it :-) Ha Ha , lol

K.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27E93DAE-54FD-4ECA-B8FF-B5D1180D05E0>