From nobody Wed Sep 18 09:06:14 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 4X7t783Pq2z5WjsQ for ; Wed, 18 Sep 2024 09:06:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 4X7t775DNWz4TkN for ; Wed, 18 Sep 2024 09:06:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1fc47abc040so52091895ad.0 for ; Wed, 18 Sep 2024 02:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1726650386; x=1727255186; 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=q+tL/X/CQZvvizK/F95AX6XlIRHx75/CrYLNvTM7Flg=; b=PUJr3bx+LQGq4dBKYiNq6kvvvHoSnlJvTJ5r9GXzuU7WWrYAufepwg56tHu0nMi2en UBlHha1aPlM9/7v2mLo3Tau/3NrWjPV3sf0tG6S5qL+Jeo1nwHFPNyE+uSah7asJ9+sz J9YDmyQphMktDB7++bdIy2on4vjH3AaiqvVjgesEL6vb7m4afV0KZvz+AjsqjHc98z2j Dju6PVWKeUkDcd7BdGBpgA/gXNwYNWc5mHjglS0mLI6FOevucXM9X/m+kfcXveWeXKLR zevZLwxutA/91twIzHgMCZp4P18FmvQ9VsJ0A9x+cXsupjnfP4JgZDh5k9Z+9cnCNczv 41VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726650386; x=1727255186; 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=q+tL/X/CQZvvizK/F95AX6XlIRHx75/CrYLNvTM7Flg=; b=gME30XgTKotNoXH8rRCXS6nudlCM/e2qjL6BaIycvbDREiemdGG+uobZ+heFnf/aO4 LvAguEwpTB3I0vd7bzWrLlc1MRPXC3Teq0j7NGKcOffXOkIxEZPSJLop3+HUdlw3Mq3H iIrEnjZuuj0wTVXY7hCGotLfKQKlZUnO0kMPM9kvtX4QS1FCmSWZkCS7MPFhiaHUqT0w Dq4ryxR9EKbp0I3dS6jXsDDWxdRcUfhEzDRTXD2B3tPzJeNEKGnI2/CmimT0K1dTNOF6 1jgePvQRStRr0DFDKcnCT9MuTT/J1Ha1zIQ5ztSoHVVaWQp6HW86Aypiz1mVEmSlppbw BK+A== X-Gm-Message-State: AOJu0YxU2oWKuHVoOhHkvdbmSc5xe1wio6cT8hvL97H2mpXrZCGJuRvn 1IdeM63hc8fGdwBOtdykkJa83eHJ5ML/zZI2NLC4zXUfHxzO9abbgNwjDP2a/z7Ed1k07ShwMR6 vztfnXqvHh4ry75+EBxuSFM1cLxzEmH0omNjzeORlCHJMHvK4nSg= X-Google-Smtp-Source: AGHT+IH8ey2Vs9VKKIG6mj+1ebFYmJAHcv423q1ykiBMk7svZhoTPAxHLihrGX1aRuUhlE1BR9vszgd2rzndxvqSjhA= X-Received: by 2002:a17:90a:8814:b0:2d8:94d6:3499 with SMTP id 98e67ed59e1d1-2dba0068106mr21687367a91.37.1726650385962; Wed, 18 Sep 2024 02:06:25 -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> In-Reply-To: <4BEC1DC0-7528-4B4B-8FD0-254BD7BF1BD9@ketas.si.pri.ee> From: Warner Losh Date: Wed, 18 Sep 2024 10:06:14 +0100 Message-ID: Subject: Re: Beaglebone Black/Green/Blue support (volunteering) To: Sulev-Madis Silber Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e840ff0622611e7d" 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: 4X7t775DNWz4TkN --000000000000e840ff0622611e7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 18, 2024 at 7:44=E2=80=AFAM 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? > Yes. It's only because of the FDT, as far as we know. > 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? > The problem is TI. They maintain the Linux port. Rather than having a stable machine description in the DTS, like the theory states, they are constantly tweaking things so that the old code won't work on the new DTS. Since in Linux, they also update the drivers at the same time and people know the kernel and the DTB is a matched set, it all mostly works out. > so am i correct, we throw that thing out just because it's super hard to > use fdt from linux? > I wouldn't put it that way, but yes. All the other sub-ports on Linux have a basically stable DTB, so we're able to use them w/o problems and only the occasional tweak. Plus, the BBB has been not the primary focus of the developers doing the actual work for a long time, so it's gotten rather far behind. The changes usually aren't that horrible, but sometimes the whole driver model changes and then it's hard. Keeping the old dts around is also hard to maintain since everything else is just imported from Linux. > whole armv7 32bit is bit weird too. looks like it's hanging on the edge o= f > trash can, along with whole 32bit, just to be waiting for to be pushed in= . > yet there are armv7 hw being sold. maybe even made still, can't be all no= s. > like allwinner h3 > There's a lot of FreeBSD use of the 32-bit arm still. But the world is moving to 64-bit systems, and there's already features that we have in 64-bit land we don't have in 32-bit land (EFI runtime, for example). There's also people wanting to do things that will only work on 64-bit kernels, so there's some tension with the 32-bit world in the developer community. Plus the 32-bit use seems to be more using it than developing new things, so very few bug fixes or enhancements to the 32-bit code come in (relative to the 64-bit stuff). > i can understand the issues with 32bit but where's like good working 64bi= t > alternative. out of small hw, only raspberry pi? out of big hw, only arm > servers? > > i have h618 hw here, along with 13.* patches i obtained from forum, > waiting for some tests. maybe someone else has interest in tiny recent ar= m > hw on fbsd > You might make sure Zach has them. > while there, how do all the people dev for armv7? i use system qemu, but > that fails with any new current now. basically old current and old qemu > builds ports. old qemu and new current doesn't boot. new qemu and new > current doesn't boot. new qemu and old current doesn't build half a ports= . > to be honest, old qemu and old qemu needs multiple tries to build some to= o, > funnily. i suspect mixes issues with qemu, fbsd and clang combination her= e. > not to mention that qemu is over 2000 times slower than c2d machine on so= me > tasks. yes, really, 2000 > I've done two or three different things. First, for me armv7 boots with machine type virt in qemu as recently as 9.0 when I fixed problems with virtio-net that caused unaligned access. I do limit what I do in qemu-system-arm since it's good for testing things, but bad at high loads. So no network stress testing, nor package building in it. I also build with bsd-user mode emulation, but that has some problems (I've been slowly working through them, but could use some help). It's quite a bit faster, and works well enough for many things. There's an issue with rust and go, IIRC, that I think is fixed in newer versions. We need to update the port since it's using a 6-year-old fork now (I've updated it to the latest, and several people have contributed improvements, so fingers crossed. I also have a very fast arm64 machine that I run most builds on in a armv7 jail. It works almost as well as native hardware, and is very fast. I have seen a couple of weird edge cases posted where it doesn't work, but I've not hit them personally. I use it also for A/B testing to see if a build hang I see in bsd-user is reproducible on real hardware. > if embedded fbsd goes away, that would be a sad story. i'm actually > curious about using fbsd professionally. i know some others do too, but > can't figure out what hw should i choose where it actually stays supporte= d? > maybe i should wait for more standardized, less fragile arm platforms in > the future? or maybe embedded is fragile by design? i currently look for = hw > similar in performance of h3 but there could be others too, bit more > powerful, maybe with video out, etc > > sad really, and all that existing hw seems to be supported by like single > person in fbsd. if anything happens, that hw is gone too somehow > > god i wish it would be as easy as with big machines. i386 is going but > that might be less of an issue (but i'm sure it's used too). as amd64, ev= en > old, is everywhere > > so any opinions with this arm situation? > > or whole embedded that is. fbsd contains lot of non server things. or > maybe they are server now. like wifi, bt, video. i wish it to stay > > unsure, i can't magically come up with bunch of usera and bunch of devs s= o > things stay healthy and i can also take and give advantage of this > > it's also super hard to maintain own code locally, etc. and embedded hw > tends to really like to stay. for over 10 years easily. i've seen many > embedded platforms appearing in fbsd and then quickly going out. while bi= g > hw stays for, i mean, i've been using fbsd since v4.6, not that long, som= e > hw has been in for entire this time > > unsure what's other option here? use nbsd, use linux? god, some hw has > better support on obsd. sad > > seems like fair bit of armv7 users are still there and i bet they also > look for 64bit extended support hw too. so how to get devs here too? i be= t > there are humans in this planet that are happy to dev for arm on fbsd > enough for it to work well > One reason I've tried to encourage Zach (and others that want to contribute) is that we do have a need to replace the 32-bit arm developers that have retired, passed away, or moved on to other things with newer developers. I'm hoping that even a few will make it better, and that will spur others to contribute since it's less of a lift to get things working, and it's psychologically easier to contribute when you know someone is likely to pick them up. Warner --000000000000e840ff0622611e7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 18, 2024 at 7:44=E2=80=AF= AM Sulev-Madis Silber <freebsd-arm-freebsd-org097@ketas.si.pri.ee> wrote:
<= /div>
i'm looking forw= ard 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 peo= ple told sorry can't do that. to that i was like how about i supply my = own fdt then?

Yes. It's only becaus= e of the FDT, as far as we know.
=C2=A0
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, wh= y would it change, as hw doesn't?

T= he problem is TI. They maintain the Linux port. Rather than having a stable= machine description in the DTS, like the theory states, they are constantl= y tweaking things so that the old code won't work on the new DTS. Since= in Linux, they also update the drivers at the same time and people know th= e kernel and the DTB is a matched set, it all mostly works out.
= =C2=A0
so am i correct, we throw that thing out just because it's super hard t= o use fdt from linux?

I wouldn't pu= t it that way, but yes. All the other sub-ports on Linux have a basically s= table DTB, so we're able to use them w/o problems and only the occasion= al tweak. Plus, the BBB has been not the primary focus of the developers do= ing the actual work for a long time, so it's gotten rather far behind. = The changes usually aren't that horrible, but sometimes the whole drive= r model changes and then it's hard. Keeping the old dts around is also = hard to maintain since everything else is just imported from Linux.
=C2=A0
whole armv7 32bit is bit weird too. looks like it's hanging on the edge= of trash can, along with whole 32bit, just to be waiting for to be pushed = in. yet there are armv7 hw being sold. maybe even made still, can't be = all nos. like allwinner h3

There's = a lot of FreeBSD use of the 32-bit arm still. But the world is moving to 64= -bit systems, and there's already features that we have in 64-bit land = we don't have in 32-bit land (EFI runtime, for example). There's al= so people wanting to do things that will only work on 64-bit kernels, so th= ere's some tension with the 32-bit world in the developer community. Pl= us the 32-bit use seems to be more using it than developing new things, so = very few bug fixes or enhancements to the 32-bit code come in (relative to = the 64-bit stuff).
=C2=A0
i can understand the issues with 32bit but where's like good working 64= bit alternative. out of small hw, only raspberry pi? out of big hw, only ar= m servers?

i have h618 hw here, along with 13.* patches i obtained from forum, waiting= for some tests. maybe someone else has interest in tiny recent arm hw on f= bsd

You might make sure Zach has them.<= /div>
=C2=A0
while there, how do all the people dev for armv7? i use system qemu, but th= at fails with any new current now. basically old current and old qemu build= s ports. old qemu and new current doesn't boot. new qemu and new curren= t doesn't boot. new qemu and old current doesn't build half a ports= . to be honest, old qemu and old qemu needs multiple tries to build some to= o, funnily. i suspect mixes issues with qemu, fbsd and clang combination he= re. not to mention that qemu is over 2000 times slower than c2d machine on = some tasks. yes, really, 2000

I've = done two or three different things. First, for me armv7 boots with machine = type virt in qemu as recently as 9.0 when I fixed problems with virtio-net = that caused unaligned access. I do limit what I do in qemu-system-arm since= it's good for testing things, but bad at high loads. So no network str= ess testing, nor package building in it.

I also bu= ild with bsd-user mode emulation, but that has some problems (I've been= slowly working through them, but could use some help). It's quite a bi= t faster, and works well enough for many things. There's an issue with = rust and go, IIRC, that I think is fixed in newer versions. We need to upda= te the port since it's using a 6-year-old fork now (I've updated it= to the latest, and several people have contributed improvements, so finger= s crossed.

I also have a very fast arm64 machine t= hat I run most builds on in a armv7 jail. It works almost as well as native= hardware, and is very fast. I have seen a couple of weird edge cases poste= d where it doesn't work, but I've not hit them personally. I use it= also for A/B testing to see if a build hang I see in bsd-user is reproduci= ble on real hardware.
=C2=A0
if embedded fbsd goes away, that would be a sad story. i'm actually cur= ious about using fbsd professionally. i know some others do too, but can= 9;t figure out what hw should i choose where it actually stays supported? m= aybe i should wait for more standardized, less fragile arm platforms in the= future? or maybe embedded is fragile by design? i currently look for hw si= milar in performance of h3 but there could be others too, bit more powerful= , maybe with video out, etc

sad really, and all that existing hw seems to be supported by like single p= erson in fbsd. if anything happens, that hw is gone too somehow

god i wish it would be as easy as with big machines. i386 is going but that= might be less of an issue (but i'm sure it's used too). as amd64, = even old, is everywhere

so any opinions with this arm situation?

or whole embedded that is. fbsd contains lot of non server things. or maybe= they are server now. like wifi, bt, video. i wish it to stay

unsure, i can't magically come up with bunch of usera and bunch of devs= so things stay healthy and i can also take and give advantage of this

it's also super hard to maintain own code locally, etc. and embedded hw= tends to really like to stay. for over 10 years easily. i've seen many= embedded platforms appearing in fbsd and then quickly going out. while big= hw stays for, i mean, i've been using fbsd since v4.6, not that long, = some hw has been in for entire this time

unsure what's other option here? use nbsd, use linux? god, some hw has = better support on obsd. sad

seems like fair bit of armv7 users are still there and i bet they also look= for 64bit extended support hw too. so how to get devs here too? i bet ther= e are humans in this planet that are happy to dev for arm on fbsd enough fo= r it to work well

One reason I've t= ried to encourage Zach (and others that want to contribute) is that we do h= ave a need to replace the 32-bit arm developers that have retired, passed a= way, or moved on to other things with newer developers. I'm hoping that= even a few will make it better, and that will spur others to contribute si= nce it's less of a lift to get things working, and it's psychologic= ally easier to contribute when you know someone is likely to pick them up.<= /div>

Warner
--000000000000e840ff0622611e7d--