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>
index | next in thread | previous in thread | raw e-mail
> Am 03.03.2021 um 09:12 schrieb Emmanuel Vadot <manu@bidouilliste.com>: > > On Tue, 2 Mar 2021 19:55:54 +0100 > > 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. > Exactly, and where’s the problem ? There never was a firmware-problem which we couldn’t fix(or identify) quickly 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 rpi-maintenance. And if I don’t order, the new maintainer , whoever , will buy one and fix issues in one- day- fashion :-) That’s what Rob, Mike, me, Mark Millard & bug-reporters did and it always worked. >> I could also offer a dtb-patch > > 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. > If you would have had applied that patch ( in release of course, regardless where it’s source-file is in the src-tree) you wouldn’t have heard of any unfixed fw-issue since then. There is no mainline Linux in that sense, instead there are companies , projects and individuals who apply patches as needed. That’s 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 we need for ourselves. That’s 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, gnu, other BSDs and so on. 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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27E93DAE-54FD-4ECA-B8FF-B5D1180D05E0>