From nobody Wed Sep 18 09:10:06 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X7tCb2GWBz5WkRk for ; Wed, 18 Sep 2024 09:10:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X7tCZ69BKz4VPc for ; Wed, 18 Sep 2024 09:10:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2d86f71353dso4688954a91.2 for ; Wed, 18 Sep 2024 02:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1726650617; x=1727255417; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vYPUOLy0AJXaeBH9mT7/ieTuQ4iwP9PQ0YQPdHHLiis=; b=pTGk7nMbJnqQsOfNsdEm5RckzkuPEvHHeAN3yakQFq/Qyj3TG72K0ZgGzFgTh5Lo3f KKZexaRL5xO0aKMPaJzR/3RJxEuByKpWVV/s9mvVFcdQdsEdcvRvtGdA1mjHb3vpf9wq 9S9RSVmzs+5AhliXemzQTsCArW/+XuT37ZD4EmjJ5ynm+kclOUn9AX9t3PoRYsEVOy5l c/PW9zbzxcZ17rUuQVSRMbF/PUzmxQ7Nn0V0+wR462U3eUzZoTPpBnkUdpVonWsvnVz0 LXWLpmlp2CCbXAxzsd9Sip9jMtwgEbH7e+k3q+LUs0jnYyxq471i/4IEoRZHI+dORFyY jOjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726650617; x=1727255417; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vYPUOLy0AJXaeBH9mT7/ieTuQ4iwP9PQ0YQPdHHLiis=; b=qTmZbbms/aXt6lueeoyxbXEays2iofe1x58mtLiwvGF8Gl7Ye36Q2rilZRQImLNLd9 JmHvDGfSuhzMlurQb8yajEtIgw6hRfX7I0D+3Y6zVchc2RPBsxK+wYPHIXXt2DHdM8Sr /NWgVC1iHDMmn/DQsoFFmtuEVuPx2olsM8bq9+E/nCLqA75kKW6RB7DwkACA73D29vdI p85D48H8TsVlSaQySM7an64GQNDnP01rtoJQjGVrBzfb1XjAHk+pvT382JxG5kWUHnUc /7rdhyK9YmH3wHs1d1gJvAcyRmfchR5kD6Kf2tOsZRx7ppuGven1q139lDQ1xee90kCY w5KQ== X-Forwarded-Encrypted: i=1; AJvYcCVbalVtlgyQNgx76Ssoqq7tPAiXfvHibV5lcgFxWWdojGhxeDPA/ipxI4bal7qJVBFcGRAnqO44duLepA==@freebsd.org X-Gm-Message-State: AOJu0YxsiuPU5gFfAu9MFBXdAv2HsZKYYeC8kP9VKGmwGnV7cc0i59Cf bHlbeqE8jlHNZwlNDSzhgBbFyhdTpS3kQdrD6vx/EmSTX+kf3ONE5uIlJ1Ugy3JTBdSKc2QuDFF H+Ouh3JksmIMwlWN83bUiADm0AeJ6PWMTFVbDow== X-Google-Smtp-Source: AGHT+IF38T0WaDb2QPGz40jHUZ8X0A1ZW3EwVIgy13cjaS/Jw5zEAZ0vFzOvm2QH+h4Yc1NcRPyTEsBeGDeNfuVSyX0= X-Received: by 2002:a17:90b:815:b0:2d8:7572:4bc1 with SMTP id 98e67ed59e1d1-2db9ff79cfbmr24032029a91.1.1726650617350; Wed, 18 Sep 2024 02:10:17 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 References: <276f57f2-5194-cad1-d859-e49b2bce2580@pobox.com> <69E08B38-7388-46A6-8864-20074BFFF8F4@yahoo.com> <88d2cc76-f980-600e-0da4-2fa1070d76ba@pobox.com> <6b848423-bdd1-b215-889a-1f07e5064412@pobox.com> <4BEC1DC0-7528-4B4B-8FD0-254BD7BF1BD9@ketas.si.pri.ee> <8597295C-BC33-4F76-AF45-41753D3E47BA@yahoo.com> In-Reply-To: <8597295C-BC33-4F76-AF45-41753D3E47BA@yahoo.com> From: Warner Losh Date: Wed, 18 Sep 2024 10:10:06 +0100 Message-ID: Subject: Re: Beaglebone Black/Green/Blue support (volunteering) To: Mark Millard Cc: Sulev-Madis Silber , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b2f6ba0622612c1c" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4X7tCZ69BKz4VPc --000000000000b2f6ba0622612c1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 18, 2024 at 9:31=E2=80=AFAM Mark Millard wr= ote: > On Sep 17, 2024, at 23:44, Sulev-Madis Silber < > freebsd-arm-freebsd-org097@ketas.si.pri.ee> wrote: > > > i'm looking forward to replace current from 2014 in my one singular bbb > with newer one > > > > is it only because fdt? i proposed to just use own fdt like earlier but > people told sorry can't do that. to that i was like how about i supply my > own fdt then? > > > > then, why is fdt such a shitshow anyway? or it works in linux as is, or= ? > or it changes often? to my still limited knowledge that just defines a hw= , > why would it change, as hw doesn't? > > My understanding of the operating principles here: > > The FDT provides a mapping between the Linux kernel's way > of working and the hardware. When Linux changes how the > kernel works the Linux FDT tracks the redesign. The two > are not independent. In essence, the FDT is a form of > kernel data structure. Multiple distinct FDT's can > describe the exact same hardware: the hardware of itself > does not uniquely determine the FDT for that hardware. > > Some contexts have fairly stable Linux kernel designs and, > so, fairly stable FDTs; others do not. > The theory is that DTS is a stable, OS independent description of the hardware. Some hardware vendors and their maintainers really believe this. The practice, though, is that some just have it be whatever is convenient for their drivers, which they change around a lot to get better performance, or when new hardware comes out. > So, one can get evidence about some of what is being > significantly reworked over time in the Linux kernel via > the seeing the repeated FDT restructuring over the time > frame. This contrasts with other context's FDTs being > stable because there is a lack of such Linux kernel > driven changes to that FDT. > > So, when FreeBSD sees the linux FDT has changed and has to > adjust for such, it is actually tracking some consequences > of the Linux kernel rework activity that changed both the > Linux kernel and the FDT. > > At least, that is my understanding. > Close. In reality, the TI DTS are the most unstable. The rest are fairly stable and generally easy enough for us to use. > FreeBSD does not have the resources to develop and use its > own FDT's overall and simply chooses to track an upstream > source of a context's FDT(s) instead. In the case of RPi*'s, > it is not mainline Linux FDT's that are tracked --but the > FDT's are from a Linux kernel context. (I'm not sure if > RPi*'s have the only non-main-line FDT's used.) > RPi do have a bit of churn, but the problems with getting base documentation more than FDT. > > so am i correct, we throw that thing out just because it's super hard t= o > use fdt from linux? > . . . > > How difficult or messy or frequently FDT tracking is > involved varies widely across the various contexts. > It is not a uniform global property for all Linux FDTs. > > . . . > > while there, how do all the people dev for armv7? > > Many aarch64 systems can execute armv7 code and so > serve as a means of building armv7 code with armv7 > tools (armv7 jail's, armv7 chroot's, possibly even > lib32). Such is generally more reliable and less time > consuming than use of qemu for "cross-activity" many > context that try to use qemu. > > The official FreeBSD armv7 packages are built on > aarch64 systems that can execute armv7 code. This > uses armv7 poudriere jails. It works a lot better > than the historical qemu use on amd64 before these > ampere[123] aarch64 machines were available (or > were not yet used this way). > > Some folks use the likes of Windows Dev Kit 2023's > or RPi4B's or RPi5B's for such activities of their > own. (Apple M1/M2/M3/M4 do not support armv7 code > and so are not example contexts for doing these > sorts of things without qemu involved.) > Yea, the Apple M3 I have is where I run much of the armv7 code in a FreeBSD VM... Warner --000000000000b2f6ba0622612c1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 18, 2024 at 9:31=E2=80=AF= AM Mark Millard <marklmi@yahoo.com<= /a>> wrote:
O= n Sep 17, 2024, at 23:44, Sulev-Madis Silber <freebsd-arm-freebsd-o= rg097@ketas.si.pri.ee> wrote:

> i'm looking forward to replace current from 2014 in my one singula= r bbb with newer one
>
> is it only because fdt? i proposed to just use own fdt like earlier bu= t people told sorry can't do that. to that i was like how about i suppl= y my own fdt then?
>
> then, why is fdt such a shitshow anyway? or it works in linux as is, o= r? or it changes often? to my still limited knowledge that just defines a h= w, why would it change, as hw doesn't?

My understanding of the operating principles here:

The FDT provides a mapping between the Linux kernel's way
of working and the hardware. When Linux changes how the
kernel works the Linux FDT tracks the redesign. The two
are not independent. In essence, the FDT is a form of
kernel data structure. Multiple distinct FDT's can
describe the exact same hardware: the hardware of itself
does not uniquely determine the FDT for that hardware.

Some contexts have fairly stable Linux kernel designs and,
so, fairly stable FDTs; others do not.

= The theory is that DTS is a stable, OS independent description of the hardw= are. Some hardware vendors and their maintainers really believe this.
=
The practice, though, is that some just have it be whatever is conveni= ent for their drivers, which they change around a lot to get better perform= ance, or when new hardware comes out.
=C2=A0
So, one can get evidence about some of what is being
significantly reworked over time in the Linux kernel via
the seeing the repeated FDT restructuring over the time
frame. This contrasts with other context's FDTs being
stable because there is a lack of such Linux kernel
driven changes to that FDT.

So, when FreeBSD sees the linux FDT has changed and has to
adjust for such, it is actually tracking some consequences
of the Linux kernel rework activity that changed both the
Linux kernel and the FDT.

At least, that is my understanding.

Clo= se. In reality, the TI DTS are the most unstable. The rest are fairly stabl= e and generally easy enough for us to use.
=C2=A0
FreeBSD does not have the resources to develop and use its
own FDT's overall and simply chooses to track an upstream
source of a context's FDT(s) instead. In the case of RPi*'s,
it is not mainline Linux FDT's that are tracked --but the
FDT's are from a Linux kernel context. (I'm not sure if
RPi*'s have the only non-main-line FDT's used.)

RPi do have a bit of churn, but the problems with getting = base documentation more than FDT.
=C2=A0
> so am i correct, we throw that thing out just because it's super h= ard to use fdt from linux?
. . .

How difficult or messy or frequently FDT tracking is
involved varies widely across the various contexts.
It is not a uniform global property for all Linux FDTs.

. . .
> while there, how do all the people dev for armv7?

Many aarch64 systems can execute armv7 code and so
serve as a means of building armv7 code with armv7
tools (armv7 jail's, armv7 chroot's, possibly even
lib32). Such is generally more reliable and less time
consuming than use of qemu for "cross-activity" many
context that try to use qemu.

The official FreeBSD armv7 packages are built on
aarch64 systems that can execute armv7 code. This
uses armv7 poudriere jails. It works a lot better
than the historical qemu use on amd64 before these
ampere[123] aarch64 machines were available (or
were not yet used this way).

Some folks use the likes of Windows Dev Kit 2023's
or RPi4B's or RPi5B's for such activities of their
own. (Apple M1/M2/M3/M4 do not support armv7 code
and so are not example contexts for doing these
sorts of things without qemu involved.)

Yea, the Apple M3 I have is where I run much of the armv7 code in a FreeBS= D VM...

Warner=C2=A0
--000000000000b2f6ba0622612c1c--