Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 May 2021 11:27:59 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Mark Murray <markm@freebsd.org>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: I2C/IIC working on RPI4 8GB?
Message-ID:  <1ABF0EB5-80A6-41FC-B465-B21CE5F004D3@yahoo.com>
In-Reply-To: <01634FBF-A36F-4AD3-B10F-992CEA9D3729@yahoo.com>
References:  <1C2DD11C-B1F6-4C2A-9AB0-5F1553520FF5@FreeBSD.org> <20210426161138.a8f44b6e1134f73a411be57d@bidouilliste.com> <CF4C4332-BB2F-47E9-B879-8EEA0E53E848@FreeBSD.org> <C4828BF2-E8B7-45D1-B0F8-5E72AF84D565@yahoo.com> <47A634E3-4938-4AFC-9341-E480CEBF67FB@FreeBSD.org> <20210428101945.67417ef8eba251dcbcb38078@bidouilliste.com> <ED9ABBBE-9B5A-4B51-806C-F91AABE39731@FreeBSD.org> <486E3EA3-EBAE-492E-B12E-E72E3E3E7B6A@FreeBSD.org> <A10EA46D-6FE5-4FCD-895C-5A08A974D6DB@yahoo.com> <E9098242-5ED4-401B-9D46-E11A214A0E2F@FreeBSD.org> <F38325DB-DC0E-44F8-A256-A5D6A23925D0@googlemail.com> <501CB1C0-73D4-4BEF-A1E6-1F13C02EFA42@FreeBSD.org> <D205D9F9-8A4D-433B-9AAA-8904850AF787@yahoo.com> <8CBBAE44-E736-4DEF-BA60-4D5068D25C15@yahoo.com> <B2F10870-5285-4AD2-932C-15140E7572FF@FreeBSD.org> <01634FBF-A36F-4AD3-B10F-992CEA9D3729@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-May-2, at 10:31, Mark Millard <marklmi at yahoo.com> wrote:

> On 2021-May-2, at 03:14, Mark Murray <markm at freebsd.org> wrote:
>=20
>>=20
>> On 2 May 2021, at 03:58, Mark Millard <marklmi@yahoo.com> wrote:
>>>=20
>>> [I was given a code hint that I've not investigated yet.]
>>>=20
>>> But going in a different direction, based on my default
>>> context on the local FreeBSD RPI4B 8 GiByte:
>>=20
>> ... and a whole lot more really helpful diagnosis over several =
emails.
>>=20
>> Thank you VERY much! it will take me a while to digest this, but =
digest it I will.
>>=20
>> Ultimately, it would be good for a "make buildworld; make =
installworld" on an RPi to install the in-source FDT, and for it to be =
correct, such that it doesn't take some trickier port modification to =
have a working FDT. This is worth taking on as a project, but I won't =
get to it very soon.
>>=20
>=20
> Linux and the foundation do not even agree about various .dtb names
> (or content). And some linux distributions targeting the RPi*'s
> use the foundation's .dtb files in preference to the linux mainline
> ones.
>=20
> For example, fedora uses the foundation's files (same names
> as FreeBSD ends up with). Fedora 34:
>=20
> # ls -ld /boot/efi/*.dtb
> -rwx------. 1 root root 26745 Feb 23 07:35 =
/boot/efi/bcm2709-rpi-2-b.dtb
> -rwx------. 1 root root 26894 Feb 23 07:35 =
/boot/efi/bcm2710-rpi-2-b.dtb
> -rwx------. 1 root root 28392 Feb 23 07:35 =
/boot/efi/bcm2710-rpi-3-b.dtb
> -rwx------. 1 root root 29011 Feb 23 07:35 =
/boot/efi/bcm2710-rpi-3-b-plus.dtb
> -rwx------. 1 root root 26890 Feb 23 07:35 =
/boot/efi/bcm2710-rpi-cm3.dtb
> -rwx------. 1 root root 49198 Apr  9 07:11 =
/boot/efi/bcm2711-rpi-400.dtb
> -rwx------. 1 root root 49218 Mar 24 08:12 =
/boot/efi/bcm2711-rpi-4-b.dtb
> -rwx------. 1 root root 49892 Apr  9 07:11 =
/boot/efi/bcm2711-rpi-cm4.dtb
>=20
> By contrast, ubuntu uses the linux .dtb's. Note the bcm2837*.dtb
> names in ubuntu 21.04 (instead of bcm2709*.dtb and bcm2710*.dtb like
> naming):
>=20
> # ls -ld /boot/firmware/*.dtb
> -rwxr-xr-x 1 root root 26914 Apr 22 21:21 =
/boot/firmware/bcm2710-rpi-2-b.dtb
> -rwxr-xr-x 1 root root 29031 Apr 22 21:21 =
/boot/firmware/bcm2710-rpi-3-b-plus.dtb
> -rwxr-xr-x 1 root root 28412 Apr 22 21:21 =
/boot/firmware/bcm2710-rpi-3-b.dtb
> -rwxr-xr-x 1 root root 26910 Apr 22 21:21 =
/boot/firmware/bcm2710-rpi-cm3.dtb
> -rwxr-xr-x 1 root root 49254 Apr 22 21:21 =
/boot/firmware/bcm2711-rpi-4-b.dtb
> -rwxr-xr-x 1 root root 48910 Apr 22 21:21 =
/boot/firmware/bcm2711-rpi-400.dtb
> -rwxr-xr-x 1 root root 49318 Apr 22 21:21 =
/boot/firmware/bcm2711-rpi-cm4.dtb
> -rwxr-xr-x 1 root root 20140 Apr 22 21:21 =
/boot/firmware/bcm2837-rpi-3-a-plus.dtb
> -rwxr-xr-x 1 root root 21009 Apr 22 21:21 =
/boot/firmware/bcm2837-rpi-3-b-plus.dtb
> -rwxr-xr-x 1 root root 20545 Apr 22 21:21 =
/boot/firmware/bcm2837-rpi-3-b.dtb
> -rwxr-xr-x 1 root root 19872 Apr 22 21:21 =
/boot/firmware/bcm2837-rpi-cm3-io3.dtb
> -rwxr-xr-x 1 root root  1559 Apr  3 06:16 =
/boot/firmware/overlay_map.dtb
>=20
> The RPiFirmware has special config.txt support for using upstream
> kernels that expect the linux naming and content. For example:
>=20
> QUOTE
> upstream_kernel
>=20
> If upstream_kernel=3D1 is used, the firmware sets os_prefix to =
"upstream/", unless it has been explicitly set to something else, but =
like other os_prefixvalues it will be ignored if the required kernel and =
.dtb file can't be found when using the prefix.
>=20
> The firmware will also prefer upstream Linux names for DTBs =
(bcm2837-rpi-3-b.dtb instead of bcm2710-rpi-3-b.dtb, for example). If =
the upstream file isn't found the firmware will load the downstream =
variant instead and automatically apply the "upstream" overlay to make =
some adjustments. Note that this process happens after the os_prefix has =
been finalised.
> ENDQUOTE
>=20
> See =
https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md=

> for os_prefix and overlay_prefix information as well.
>=20
> =46rom what I can tell, it appears that the linux .dtb's are less =
tested
> by being less used, so possibly having more problems, not fewer. And
> FreeBSD itself would have to have its kernel updated to deal with the
> differences (or to support both ways). It is not just a build =
environment
> change if I understand right.
>=20

There is another implication: the RPi firmware loaded and uses
the .dtb files and also makes dynamic adjustments to provide
what it does to U-Boot, which in turn can do more adjsutments
for what it provides to the FreeBSD loader.

Having the kernel use different .dtb built from other sources
without having the RPi firmware and U-Boot also use the same
.dtb is asking for mismatches and other troubles.

Thus any .dtb generated and used needs to be tested for the
earlier stages handling the alternate .dtb's. Compatibility
would not be a local-to-FreeBSD concern overall.

It is not obvious to me that alternate .dtb files make things
simpler for knowing what will work vs. not.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1ABF0EB5-80A6-41FC-B465-B21CE5F004D3>