From nobody Fri Nov 10 17:12:03 2023 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 4SRlkB45jmz50CbK for ; Fri, 10 Nov 2023 17:12:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SRlk96Mzfz3dPg for ; Fri, 10 Nov 2023 17:12:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b="g11oA1Y/"; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::529) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-53db360294fso3846871a12.3 for ; Fri, 10 Nov 2023 09:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1699636336; x=1700241136; 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=CRb+EwZ9QjRa9Dwwj/RB3ODSF97lJD/vJYQlqf5DhCI=; b=g11oA1Y/UApb5UTLFpTQQb/6Q8FYfv6d/8uEaG0C+tt7kdWC/Qo7HiEMlJX00bV7Gt bEI3qH3ZcSX/dcdp4jF6f8nw4+ODxYa3Js3Ci7k+wjHbM8GcH5gNNKe42n5e5iDkbMJb iEUSDZadQLyekdhtgqDv3uN0v+GDdkPZd9/fcS1V9sF7+f/0au5+Cgg96NHwT98QWYFw D0HS50GgWfXiik/rM23c9y6xpmwOMjn5uqCu7R3Z7pEPxSzCMEwgrKdYS/1XASZeGcJx K9LpeNfQVZiP3BUeFDwHVpfdMf2A9wRAo0qNWdDcWP5xXTfRweFaYNv/5E9CAC+319xx iVEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699636336; x=1700241136; 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=CRb+EwZ9QjRa9Dwwj/RB3ODSF97lJD/vJYQlqf5DhCI=; b=X+3ufl3NgXo5mqUpu8xdvh5dSnHnFbA/hbn+XCRp5o+vaSz70Vka0UNt4o8mng4Zxk G24Iae6sWh0X2KbBHwOybpi1vC6LJDk6pCXZV3Hpu0tZZLkyN9iy5gxieK3DyxHT+Isi Hh4HvT0zc5iZ6MTx7PYZ5TDgDgzkp/sT2FsGuyPGbIws5mFXq3rqppva7HPXh1ia4LtH 27q2YYL9EPT+TpCk5ujMYeZWnm7PwQkRdOoULTnuKqbLFegdorAi2KASD1of+oRyd3Ws u8ULwMbwJSIgj0k3xIbsIpMYLNwqP1yDVI2ongyS36+96PskbyBcJ4p8BXnr6dXr5+e8 8tlQ== X-Gm-Message-State: AOJu0YzlDawhLubrSVTabOAuVVfXAGPfNr7f6frsQQ3hg4O609WXbGif kZz9diOvBp2eMhZv6/X2heqCH3q7YdpdtpEfBgGByUNuRaQL1ini X-Google-Smtp-Source: AGHT+IG3sJLk2N641NMyqJLCAff9TVuxBRXAG7l9ZkssJ4BH4avn7Gc+aNBKRIwXiV7/OJ1kMmw5e9Nujp5MWD/bgN4= X-Received: by 2002:aa7:df10:0:b0:543:fa0:b4b6 with SMTP id c16-20020aa7df10000000b005430fa0b4b6mr7629628edy.33.1699636335615; Fri, 10 Nov 2023 09:12:15 -0800 (PST) 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: <07f36861-caf4-458a-8ddc-6c73a4a09755@bunyatech.com.au> <89e45166-8d87-4050-b9f7-00469187005c@madpilot.net> <9036ce5f-f3b8-4c83-a569-aa4d86436e6b@madpilot.net> In-Reply-To: From: Warner Losh Date: Fri, 10 Nov 2023 10:12:03 -0700 Message-ID: Subject: Re: NanoBSD on Raspberry Pi3 To: Guido Falsi Cc: Brian Scott , freebsd-arm Content-Type: multipart/alternative; boundary="0000000000000834080609cf6c47" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4SRlk96Mzfz3dPg X-Spamd-Bar: -- --0000000000000834080609cf6c47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 6, 2023 at 3:08=E2=80=AFAM Guido Falsi wrote= : > On 06/11/23 11:06, Guido Falsi wrote: > > On 05/11/23 12:05, Brian Scott wrote: > >> > >> On 5/11/2023 8:13 pm, Guido Falsi wrote: > >>> Have you got some pointer to some documentation elsewhere about this > >>> so I can write an informed paragraph for the man page about this? > >> I found it a couple of years ago after a lot of searching. No idea > >> where I found it even though I normally try to keep notes. It would be > >> nice to see some doco on it. > > > > I created a code review to update loader.env(8) man page. I really did > > I obviously meant loader.efi(8) here. > Honestly, for MBR booting, the defaults are wrong. mbr + uefi is kinda niche. The rpi is the only platform we have where it's used. Other places it's possible, but with large disks everybody uses GPT when they can regardless of the size of the disk. Plus config is a little easier... All the loader*(8) man pages need a lot of work. Warner --0000000000000834080609cf6c47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 6, 2023 at 3:08=E2=80=AFA= M Guido Falsi <mad@madpilot.net&= gt; wrote:
On 06= /11/23 11:06, Guido Falsi wrote:
> On 05/11/23 12:05, Brian Scott wrote:
>>
>> On 5/11/2023 8:13 pm, Guido Falsi wrote:
>>> Have you got some pointer to some documentation elsewhere abou= t this
>>> so I can write an informed paragraph for the man page about th= is?
>> I found it a couple of years ago after a lot of searching. No idea=
>> where I found it even though I normally try to keep notes. It woul= d be
>> nice to see some doco on it.
>
> I created a code review to update loader.env(8) man page. I really did=

I obviously meant loader.efi(8) here.

H= onestly, for MBR booting, the defaults are wrong. mbr=C2=A0+ uefi is kinda = niche. The rpi is the only platform we have where it's used. Other plac= es it's possible, but with large disks everybody uses GPT when they can= regardless of the size of the disk. Plus config is a little easier...

All the loader*(8) man pages need a lot of work.
=

Warner=C2=A0
--0000000000000834080609cf6c47-- From nobody Sun Nov 12 21:00:32 2023 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 4ST4hd1q44z51CSY for ; Sun, 12 Nov 2023 21:00:33 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ST4hc5crrz3fjB for ; Sun, 12 Nov 2023 21:00:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699822832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=NZUK0Wa3uFPyANMeU06ey0a6D9CBGtc7a3ZiSp3h9xs=; b=BIklfHJ9HJttlaIRH6+cx2mql6O2tKZHbti8+EPn5IwAxGC4w2qmGvwkaSwRgYzfA6ubQz 3qStNMC6LdIQyH/65u8pjtvOelvwaR0DpLpMKmnq9+cWX6SmWnAb4Z4ClUZHnO9Yc8ieBx T+wzIWJTJlSN6QXtsIx+oG8iPiHzvRrDvWEhTvksU065KAXAdII2xVD8PsoDkAH8dQ7at1 5w5rrp59jTr+uY3x6kRJnimWeJ08ItBOgI9DgbNFPcHkjvYWl7PsuPUUATASHJfMZUIvXP hGl3ApAwgALv11dLcLJGRAjXys6kDqvhm2eh92XEN3cEMkFHiQAt72NzupnTIQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699822832; a=rsa-sha256; cv=none; b=i+eNZSnn8GhD89w1qmuxBKonmVRw80qBqf3w7UxiCtrz+/rvTqXoYKMMK3JtCIxVbNU8bV uRWUdPPMOF3GmocFQaK+eesCCkZcy0Yu/BWZlvVFyWJCH/tfYlKQPekSJtjJOgwiP7WxCS iecI4Z5PNHhlrfEh4cxLPAmrOHLxIGeg55aR7SuNJJ9tenl/DDs6EdmqzU19zK1vIwR7sS gaxpfQ0q5YnW+D2bFSdYsVEpigt8tDYMvSXzGob+lfGRxIX172QFBidXRZvNtxdCLkM6AQ Kz0AChhIPi37k/KinALA7QdaxXyQpFajT0TrfDI+cWHRG2mnC8O74Pfb+07xEA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ST4hc4YZ9zdbg for ; Sun, 12 Nov 2023 21:00:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3ACL0Whc052439 for ; Sun, 12 Nov 2023 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3ACL0WP7052438 for freebsd-arm@FreeBSD.org; Sun, 12 Nov 2023 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202311122100.3ACL0WP7052438@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 12 Nov 2023 21:00:32 +0000 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 Content-Type: multipart/alternative; boundary="16998228325.DB908bb.49453" Content-Transfer-Encoding: 7bit --16998228325.DB908bb.49453 Date: Sun, 12 Nov 2023 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16998228325.DB908bb.49453 Date: Sun, 12 Nov 2023 21:00:32 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16998228325.DB908bb.49453-- From nobody Sun Nov 12 22:29:13 2023 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 4ST6gk1lFRz50X08 for ; Sun, 12 Nov 2023 22:29:54 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ST6gj2yKJz4RbM for ; Sun, 12 Nov 2023 22:29:53 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=JLVueoVJ; spf=pass (mx1.freebsd.org: domain of furaisanjin@gmail.com designates 2a00:1450:4864:20::12e as permitted sender) smtp.mailfrom=furaisanjin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-507cee17b00so5057405e87.2 for ; Sun, 12 Nov 2023 14:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699828191; x=1700432991; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=4gLKHS+vyJS+AtRqWJItKbMo4G1XmoNfvAahcRXMwOI=; b=JLVueoVJv/KyhkRQMt5pNfhWSEDaXYNvgZxXMLtt5Y7nBUrWAc+UPelqVGaEeR7EPF GTcRiEBsw5YEJmk9PivPkVA0Q2QLwYWpEmWWptzY8dLBdmegsCnwKeYzyb/QE+6hqA8R UpOLc23ESHmV5ek7xtN6HdQZHX72wNjPCGx3+lPc6nz7aOtzNdGFDX+eXOl8vWUXK641 yjXBBODy3LmAvt9bwjdGOChjvbdCDSDNQMzN4bPrzetcSgHU8RKbO6byz2UH0PtXWhDy 5Yd85YOEpn6MFRW+e4w6NrvPRe6wNRFxkyVkaY0CtHzXHV3zKsAoDyaBUooRFIqENJ/f Eb5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699828191; x=1700432991; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4gLKHS+vyJS+AtRqWJItKbMo4G1XmoNfvAahcRXMwOI=; b=IbGN57klDb/hwnclYrNmIvLTUk7NYC4rvyMS+AyGe5oBMKOhlXJiY4J9gRMAd9y2R8 yfv9+zVNbbyuSjZojUb7qyZnZUSBomqtUIdk1oV1MeP/g69P//OzBYsqQgrF+azOyvXY Y9UxXa0QGnxen1IQy1O9y4knlxduht92StKX8V8oB5ZdHSeFUGQZsMzPWurN6TO2SxgF f0PhzhPVUvfualWqg31S7fDEU3JTPMclu/EUjNWxWQoPtp/r3QdUbukR5xM2rrm5SSjM gQ9zuse2K29Kgn8E+RkUXlfZbW3iMAeGaBLZ28+76o7r21Y9p5fBo35WFXRKfq5sR7oh CWOQ== X-Gm-Message-State: AOJu0YzE/bbShmxyQBbYoFnoIMx0wLCZo4FGBstT/oMAjXNHBbEDr1fK r4QuZHY6YCkAiTKWkGdnlu897OBlrijFa6NjItBhTRxBi+ZAhw== X-Google-Smtp-Source: AGHT+IESlYFY9BqpjLRvYkHEAciM9FAjNfBBl7QG9D5JP4Jmdf5A8yxWU3Et8UnBm/HI4Wm1hIJW02HEUmYIG/hf7+0= X-Received: by 2002:a05:6512:48d5:b0:509:47e1:6ebe with SMTP id er21-20020a05651248d500b0050947e16ebemr3043538lfb.14.1699828190554; Sun, 12 Nov 2023 14:29:50 -0800 (PST) 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 From: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= Date: Mon, 13 Nov 2023 07:29:13 +0900 Message-ID: Subject: Conflict DS1307 and MAX77620 To: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000007a2dbc0609fc1797" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12e:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4ST6gj2yKJz4RbM X-Spamd-Bar: --- --0000000000007a2dbc0609fc1797 Content-Type: text/plain; charset="UTF-8" Hello all. I found that a similar discussion was done almost 2 years ago. https://lists.freebsd.org/archives/freebsd-arm/2021-November/000600.html I'm using the official FreeBSD 13.2 release. uname -a FreeBSD macavity 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64 freebsd-version -kru 13.2-RELEASE-p4 13.2-RELEASE-p4 13.2-RELEASE-p5 I created overlay dtb files for i2c and ds1307, and loaded them at boot. FreeBSD detected ds1360 as MAX77620 like below. Nov 12 16:17:18 localhost kernel: rtc1: at addr 0xd0 on iicbus0 Nov 12 16:17:18 localhost kernel: rtc1: registered as a time-of-day clock, resolution 1.000000s My SBC just has Allwinner H5 and nothing like tegra210. I created a custom kernel to remove tegra210. The custom kernel is fine and can detect ds1307 correctly. Nov 13 06:21:52 localhost kernel: ds13070: at addr 0xd0 on iicbus0 Nov 13 06:21:52 localhost kernel: ds13070: registered as a time-of-day clock, resolution 1.000000s Is there any way to disable max77620 without creating a custom kernel? Best regards, furaisanjin --0000000000007a2dbc0609fc1797 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all.

I found that a si= milar discussion was done almost 2 years ago.


I'm using the official FreeBSD 13.2 re= lease.

uname -a
FreeBSD macavity 13.2-RELEASE-p= 4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64
freebsd-version -kru
13.2-REL= EASE-p4
13.2-RELEASE-p4
13.2-RELEASE-p5

I cr= eated overlay dtb files for i2c and ds1307, and loaded them at boot. FreeBS= D detected ds1360 as MAX77620 like below.

Nov 12 1= 6:17:18 localhost kernel: rtc1: <MAX77620 RTC> at addr 0xd0 on iicbus= 0
Nov 12 16:17:18 localhost kernel: rtc1: registered as a time-of-day cl= ock, resolution 1.000000s

My SBC just has=20 Allwinner H5 and nothing like tegra210. I created a custom kernel to remov= e tegra210. The custom kernel is fine and can detect ds1307 correctly.

Nov 13 06:21:52 localhost kernel: ds13070: <Dallas DS130= 7> at addr 0xd0 on iicbus0
Nov 13 06:21:52 localhost kernel: ds1= 3070: registered as a time-of-day clock, resolution 1.000000s
Is there any way to disable max77620 without creating a custom = kernel?

Best regards,
furaisanjin
<= div>



--0000000000007a2dbc0609fc1797-- From nobody Mon Nov 13 11:24:16 2023 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 4STRsq0BMPz51D0T for ; Mon, 13 Nov 2023 11:24:47 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:580d:ae98:0:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4STRsp28qTz4P5Y for ; Mon, 13 Nov 2023 11:24:45 +0000 (UTC) (envelope-from darius@dons.net.au) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple ([IPv6:2403:580d:ae98:0:ec76:82c1:7587:e045]) (authenticated bits=0) by midget.dons.net.au (8.17.2/8.17.1) with ESMTPSA id 3ADBOQXO010541 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Nov 2023 21:54:26 +1030 (ACDT) (envelope-from darius@dons.net.au) X-Authentication-Warning: midget.dons.net.au: Host [IPv6:2403:580d:ae98:0:ec76:82c1:7587:e045] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: Conflict DS1307 and MAX77620 From: "Daniel O'Connor" In-Reply-To: Date: Mon, 13 Nov 2023 21:54:16 +1030 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?B?6aKo5L6G5pWj5Lq6?= X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Spam-Status: No, score=0.40 X-Rspamd-Action: no action X-Rspamd-Server: midget.dons.net.au 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:4764, ipnet:2403:5800::/27, country:AU] X-Rspamd-Queue-Id: 4STRsp28qTz4P5Y > On 13 Nov 2023, at 08:59, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA = wrote: > I found that a similar discussion was done almost 2 years ago. >=20 > = https://lists.freebsd.org/archives/freebsd-arm/2021-November/000600.html >=20 > I'm using the official FreeBSD 13.2 release. >=20 > uname -a > FreeBSD macavity 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64 > freebsd-version -kru > 13.2-RELEASE-p4 > 13.2-RELEASE-p4 > 13.2-RELEASE-p5 >=20 > I created overlay dtb files for i2c and ds1307, and loaded them at = boot. FreeBSD detected ds1360 as MAX77620 like below. >=20 > Nov 12 16:17:18 localhost kernel: rtc1: at addr 0xd0 on = iicbus0 > Nov 12 16:17:18 localhost kernel: rtc1: registered as a time-of-day = clock, resolution 1.000000s >=20 > My SBC just has Allwinner H5 and nothing like tegra210. I created a = custom kernel to remove tegra210. The custom kernel is fine and can = detect ds1307 correctly. >=20 > Nov 13 06:21:52 localhost kernel: ds13070: at addr = 0xd0 on iicbus0 > Nov 13 06:21:52 localhost kernel: ds13070: registered as a time-of-day = clock, resolution 1.000000s >=20 > Is there any way to disable max77620 without creating a custom kernel? I think the way the time is accessed is compatible - or at least I have = the same confusion (on an RPi4 hat) but the time keeping works fine. That said it would be nice to fix - are you able to try the suggested = change by Ian? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Mon Nov 13 11:40:27 2023 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 4STSDD2dQsz51GYY for ; Mon, 13 Nov 2023 11:40:44 +0000 (UTC) (envelope-from bT.dviprj1f30=sal1xodabuv8=z45c5kjj6y@em790814.fubar.geek.nz) Received: from e2i209.smtp2go.com (e2i209.smtp2go.com [103.2.140.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4STSDD0sbZz4Qyx for ; Mon, 13 Nov 2023 11:40:43 +0000 (UTC) (envelope-from bT.dviprj1f30=sal1xodabuv8=z45c5kjj6y@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1699876543; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=8iwwOsQIka3LAuAlVBxFICP7+vsYgLPr9KVB6w4NtS8=; b=kqv9ipvx wYQSZDIB9K+n7IdNm1jQArhQW9BtVTwcs3hiZi3RH6UatE3SB2F7ZswrmN3CipPF4Wj9mZlmD8cmd Mx5zQQhXd2s/DvNdosP9k3iaCGSDFyVciqg79g0qslK60RytyDOD3YBrDiWHmz0zI9QY2t8Qa513y nEfDrWAcdcZFlB928h5hY+u5tbb9pd1GTdurC+TKD2z/p6IRvQ7XTUdsSbTH3ub6wdwhoGpJCD8OG /WHqRz3ZZU7ii11SqZud60CqSwWi89lcPL8/6WTirts9wfz8woIRA1uOGMDqnfQJ00VyMuESsitXf p6xnzKXTnH9XvmMbBcoG/hJ0uw==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1699875643; h=from : subject : to : message-id : date; bh=8iwwOsQIka3LAuAlVBxFICP7+vsYgLPr9KVB6w4NtS8=; b=XPqzQFXe/1ADv8GnhgRmHUsUKB3itTtB5L3HZS8il9Qq89VFnD2DDXV5n/LRggbkVHd4j f5j4z1lNjkJUqBz5Ra3M0na1AeVEw7p9O/z4aidGjUn7yaAVkaG61Dg+FRmZ/By3K3TIrwH tSO8jP7bTYEioodXhwARbI+GAyEKzgjEMgjVwcEvOg47j+oS03kUEDCG2QonpI+kpDCKkOG XZLcboKRAY4f7ZD9GyELGC1ndtHh5o8qqqylJ1OLaYmHbJJ5zuYaS/3zzLvmeTUnVrtyeG3 D6DJ2fSyh6TzIs41GKs1Nzsj2WJty+3V9UvGaMHmPGFfKFInys7s1OC0JsSg== Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1r2VJ1-Y8PLIT-BW; Mon, 13 Nov 2023 11:40:39 +0000 Received: from [10.99.243.232] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96.1-S2G) (envelope-from ) id 1r2VJ1-9ERV4n-0M; Mon, 13 Nov 2023 11:40:39 +0000 Received: from smtpclient.apple (cpc91210-cmbg18-2-0-cust37.5-4.cable.virginm.net [81.102.44.38]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 5E0BA25AFB; Mon, 13 Nov 2023 11:40:38 +0000 (UTC) From: Andrew Turner Message-Id: <44B013F8-F710-4CD7-82ED-71B413186346@fubar.geek.nz> Content-Type: multipart/alternative; boundary="Apple-Mail=_4FEDE1AA-E3FC-44B9-BFC6-C47133011EF4" 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 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: Conflict DS1307 and MAX77620 Date: Mon, 13 Nov 2023 11:40:27 +0000 In-Reply-To: Cc: FreeBSD ARM List To: =?utf-8?B?6aKo5L6G5pWj5Lq6?= References: X-Mailer: Apple Mail (2.3774.100.2.1.4) X-Smtpcorp-Track: 1r2VJ19ERV4n0u.lts2bhop4WUvH Feedback-ID: 790814m:790814amQcrys:790814s6u9U-FwW8 X-Report-Abuse: Please forward a copy of this message, including all headers, to 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:23352, ipnet:103.2.140.0/22, country:US] X-Rspamd-Queue-Id: 4STSDD0sbZz4Qyx --Apple-Mail=_4FEDE1AA-E3FC-44B9-BFC6-C47133011EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Nov 2023, at 22:29, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA = wrote: >=20 > Hello all. >=20 > I found that a similar discussion was done almost 2 years ago. >=20 > = https://lists.freebsd.org/archives/freebsd-arm/2021-November/000600.html >=20 > I'm using the official FreeBSD 13.2 release. >=20 > uname -a > FreeBSD macavity 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64 > freebsd-version -kru > 13.2-RELEASE-p4 > 13.2-RELEASE-p4 > 13.2-RELEASE-p5 >=20 > I created overlay dtb files for i2c and ds1307, and loaded them at = boot. FreeBSD detected ds1360 as MAX77620 like below. >=20 > Nov 12 16:17:18 localhost kernel: rtc1: at addr 0xd0 on = iicbus0 > Nov 12 16:17:18 localhost kernel: rtc1: registered as a time-of-day = clock, resolution 1.000000s >=20 > My SBC just has Allwinner H5 and nothing like tegra210. I created a = custom kernel to remove tegra210. The custom kernel is fine and can = detect ds1307 correctly. >=20 > Nov 13 06:21:52 localhost kernel: ds13070: at addr = 0xd0 on iicbus0 > Nov 13 06:21:52 localhost kernel: ds13070: registered as a time-of-day = clock, resolution 1.000000s >=20 > Is there any way to disable max77620 without creating a custom kernel? It looks like this might have been fixed in = https://cgit.freebsd.org/src/commit/?id=3Da534b50e245d8, however this = wasn=E2=80=99t MFCd to the stable/13 branch. You could try = cherry-picking that patch, or test with 14-RELEASE when it=E2=80=99s = released to see if it helps. Andrew --Apple-Mail=_4FEDE1AA-E3FC-44B9-BFC6-C47133011EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Nov = 2023, at 22:29, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA = <furaisanjin@gmail.com> wrote:

Hello = all.

I found that a similar discussion was done = almost 2 years ago.


I'm using the official FreeBSD 13.2 = release.

uname -a
FreeBSD macavity = 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64
freebsd-version = -kru
13.2-RELEASE-p4
13.2-RELEASE-p4
13.2-RELEASE-p5
I created overlay dtb files for i2c and ds1307, and loaded = them at boot. FreeBSD detected ds1360 as MAX77620 like = below.

Nov 12 16:17:18 localhost kernel: rtc1: = <MAX77620 RTC> at addr 0xd0 on iicbus0
Nov 12 16:17:18 = localhost kernel: rtc1: registered as a time-of-day clock, resolution = 1.000000s

My SBC just has=20 Allwinner H5 and nothing like tegra210. I created a custom kernel to = remove tegra210. The custom kernel is fine and can detect ds1307 = correctly.

Nov 13 06:21:52 localhost kernel: = ds13070: <Dallas DS1307> at addr 0xd0 on iicbus0
Nov 13 = 06:21:52 localhost kernel: ds13070: registered as a time-of-day clock, = resolution 1.000000s

Is there any way to = disable max77620 without creating a custom = kernel?

It looks like this = might have been fixed = in https://cgit.freebsd.org/src/commit/?id=3Da534b50e245d8, however = this wasn=E2=80=99t MFCd to the stable/13 branch. You could try = cherry-picking that patch, or test with 14-RELEASE when it=E2=80=99s = released to see if it = helps.

Andrew

= --Apple-Mail=_4FEDE1AA-E3FC-44B9-BFC6-C47133011EF4-- From nobody Mon Nov 13 12:18:21 2023 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 4STT4P6mVbz50Pfc for ; Mon, 13 Nov 2023 12:19:01 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4STT4P4kV1z4WVC for ; Mon, 13 Nov 2023 12:19:01 +0000 (UTC) (envelope-from furaisanjin@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5441305cbd1so6733028a12.2 for ; Mon, 13 Nov 2023 04:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699877939; x=1700482739; 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=7/SGgoARbo+1bT24kEUZnaK6A4tht47N2UZDE5COnBg=; b=RYVf9WYPm3mz1UlLHgOS+gLp4yrxADR008WccOi56gNdfCBcG+sWYYBRiW9sYBBwLQ 4U9v6HJz1eBq/7SMd7EupoMgoh7KuHv3qZrx1h4JFrquh1w1bi7zxx9leeJkjm8WbcKY 674YR9yWDHOLavyleKROrtlNfAAjm4n6sbb7ZZIWuYp+kVsZsUbCZezu+2Oo6VnwsQzZ 86tjA17PtrGZ+Z/ZHrNO+I9kl9wP55h0s3+h3L8rtgYQx154RzW9iX3yfJgFvYv8DRnH P0dFhCqEGcg7+NlhCRUJoYQUgUi7CjA+JHMj/O9TCIwp1mHgntmyEJ0LvLx2dFE1/mKO b3ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699877939; x=1700482739; 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=7/SGgoARbo+1bT24kEUZnaK6A4tht47N2UZDE5COnBg=; b=g2bkdDYfWA7I9L8GJIJ9AvLEry09GeEuDqsr6ufvOcVjNP1sfeaMdPbVs3eFl9Zq38 FLzA1sRFNozMGxXgl9AAvlItdCrIpTAdVrfPb6u38fm3mVc5Dhnilc3DwqRMic7o0nEY 7qnUmT80QHd9AEMwtYHUaAD29US7oxkTybXOLNlNIO+PK/tJzjL/6Ax5QsWzmulIOfrv MSFGMvSYXm1GxVS+/NKXPFaDbfhZg7fFhhLgqoyU2FQF0z5fuiy82xJ9RScII7FdtdVu v0ycKRoUPeC1RhOrdeWJbfj2FeoHaZuiB3Tas/DhltyenM02T2jQJChhJWkjetGOJV8q l+KA== X-Gm-Message-State: AOJu0Ywk8gYd38E8cMxcciHVh3tqhraWGscVUeOWYIW01sHnl4hml1Kk +TnDm8A4T51bO2sq3BIFmIKc5ppgb/8nvHtEqYE+KuTZ+r5myA== X-Google-Smtp-Source: AGHT+IG/PVc49i8+EdlTnbWicwv/a2ZAK3HOKK4XcU5Ay/rhvxwnYO/IRzjhjEQSus0HHKI9Ym2t8tKP1mlVDJvycoY= X-Received: by 2002:aa7:d84a:0:b0:53e:4762:9373 with SMTP id f10-20020aa7d84a000000b0053e47629373mr4068092eds.18.1699877939107; Mon, 13 Nov 2023 04:18:59 -0800 (PST) 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: <44B013F8-F710-4CD7-82ED-71B413186346@fubar.geek.nz> In-Reply-To: <44B013F8-F710-4CD7-82ED-71B413186346@fubar.geek.nz> From: =?UTF-8?B?6aKo5L6G5pWj5Lq6?= Date: Mon, 13 Nov 2023 21:18:21 +0900 Message-ID: Subject: Re: Conflict DS1307 and MAX77620 To: Andrew Turner Cc: FreeBSD ARM List Content-Type: multipart/alternative; boundary="000000000000b8dbeb060a07ac53" 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4STT4P4kV1z4WVC --000000000000b8dbeb060a07ac53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all. Thank you for the comments. I tried 14,0-RC4 and it worked as expected. I will switch to 14.0 once it is released. Best regards, furaisanjin 2023=E5=B9=B411=E6=9C=8813=E6=97=A5(=E6=9C=88) 20:40 Andrew Turner : > > On 12 Nov 2023, at 22:29, =E9=A2=A8=E4=BE=86=E6=95=A3=E4=BA=BA wrote: > > Hello all. > > I found that a similar discussion was done almost 2 years ago. > > https://lists.freebsd.org/archives/freebsd-arm/2021-November/000600.html > > I'm using the official FreeBSD 13.2 release. > > uname -a > FreeBSD macavity 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64 > freebsd-version -kru > 13.2-RELEASE-p4 > 13.2-RELEASE-p4 > 13.2-RELEASE-p5 > > I created overlay dtb files for i2c and ds1307, and loaded them at boot. > FreeBSD detected ds1360 as MAX77620 like below. > > Nov 12 16:17:18 localhost kernel: rtc1: at addr 0xd0 on > iicbus0 > Nov 12 16:17:18 localhost kernel: rtc1: registered as a time-of-day clock= , > resolution 1.000000s > > My SBC just has Allwinner H5 and nothing like tegra210. I created a custo= m > kernel to remove tegra210. The custom kernel is fine and can detect ds130= 7 > correctly. > > Nov 13 06:21:52 localhost kernel: ds13070: at addr 0xd0 o= n > iicbus0 > Nov 13 06:21:52 localhost kernel: ds13070: registered as a time-of-day > clock, resolution 1.000000s > > Is there any way to disable max77620 without creating a custom kernel? > > > It looks like this might have been fixed in > https://cgit.freebsd.org/src/commit/?id=3Da534b50e245d8, however this > wasn=E2=80=99t MFCd to the stable/13 branch. You could try cherry-picking= that > patch, or test with 14-RELEASE when it=E2=80=99s released to see if it he= lps. > > Andrew > > --000000000000b8dbeb060a07ac53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all.

Thank you for the= comments. I tried 14,0-RC4 and it worked as expected. I will switch to 14.= 0 once it is released.

Best regards,
fur= aisanjin

2023=E5=B9=B411=E6=9C=8813=E6=97=A5(=E6=9C=88) 20:40 Andr= ew Turner <andrew@fubar.geek.nz<= /a>>:

Hello all.

I found that a similar di= scussion was done almost 2 years ago.


I'm using the official FreeB= SD 13.2 release.

uname -a
FreeBSD macavity 13.2= -RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC arm64
freebsd-version -kru13.2-RELEASE-p4
13.2-RELEASE-p4
13.2-RELEASE-p5

I created overlay dtb files for i2c and ds1307, and loaded them at bo= ot. FreeBSD detected ds1360 as MAX77620 like below.

Nov 12 16:17:18 localhost kernel: rtc1: <MAX77620 RTC> at addr 0xd0= on iicbus0
Nov 12 16:17:18 localhost kernel: rtc1: registered as a time= -of-day clock, resolution 1.000000s

My SBC just ha= s=20 Allwinner H5 and nothing like tegra210. I created a custom kernel to remov= e tegra210. The custom kernel is fine and can detect ds1307 correctly.

Nov 13 06:21:52 localhost kernel: ds13070: <Dallas DS130= 7> at addr 0xd0 on iicbus0
Nov 13 06:21:52 localhost kernel: ds1= 3070: registered as a time-of-day clock, resolution 1.000000s
Is there any way to disable max77620 without creating a custom = kernel?

It looks like this mig= ht have been fixed in=C2=A0https://cgit.freebsd.org/src/commit/?= id=3Da534b50e245d8, however this wasn=E2=80=99t MFCd to the stable/13 b= ranch. You could try cherry-picking that patch, or test with 14-RELEASE whe= n it=E2=80=99s released to see if it helps.

Andrew=

--000000000000b8dbeb060a07ac53-- From nobody Mon Nov 13 15:40:36 2023 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 4STYYC3snLz518yQ for ; Mon, 13 Nov 2023 15:40:47 +0000 (UTC) (envelope-from titus@edc.ro) Received: from eatlas.ro (eatlas.ro [86.126.82.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "eatlas.ro", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4STYYB2qJxz3Xbj for ; Mon, 13 Nov 2023 15:40:46 +0000 (UTC) (envelope-from titus@edc.ro) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=edc.ro header.s=mail header.b=ysS7DXsR; spf=pass (mx1.freebsd.org: domain of titus@edc.ro designates 86.126.82.18 as permitted sender) smtp.mailfrom=titus@edc.ro; dmarc=none Received: from mail.edc.ro ([10.1.4.62]) by eatlas.ro (8.16.1/8.16.1) with ESMTPS id 3ADFebOO058068 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Mon, 13 Nov 2023 17:40:37 +0200 (EET) (envelope-from titus@edc.ro) Received: from tituss-imac.eatlas.local (eatlas.ro [86.126.82.18]) (authenticated bits=0) by mail.edc.ro (8.16.1/8.16.1) with ESMTPSA id 3ADFeZo7091464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 13 Nov 2023 17:40:36 +0200 (EET) (envelope-from titus@edc.ro) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=edc.ro; s=mail; t=1699890036; bh=j0Jd/o2FUkjbmifkV7HHCt5OxJwRyX7Td/C7Al1bBCs=; h=From:Subject:Date:To; b=ysS7DXsRotFUAlpGH3fbC9VpYtT83JKM9Kcmnb480eQJkxD/21OSQIdM/IbSfjfOF 8mbIUA3+ROvXJd60YFfryUQBC6XOYOREZ9+XWZTzfxFl+zqsYrfW/KxiNQpeq4H9i3 So/1u8k8xfq9CCTnWf1RS/jbf5aP00Dpmn2n+6UM= From: titus Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: eqos(4) throughput Message-Id: <0FA5C2FB-B336-4DFA-AD32-05C414DDB6F7@edc.ro> Date: Mon, 13 Nov 2023 17:40:36 +0200 To: freebsd-arm X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns.edc.ro X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:86.126.82.18/32]; R_DKIM_ALLOW(-0.20)[edc.ro:s=mail]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[edc.ro:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8708, ipnet:86.120.0.0/13, country:RO]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[edc.ro]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4STYYB2qJxz3Xbj X-Spamd-Bar: -- i have this problem with eqos(4) on a rk3566 board (orangepi 3b) when there is enough RX traffic the TX sinks packets (not all the = packets are transmitted) this causes a max tcp uplink throughput of about 300mb/s testing udp tx only will get to 900mbs+ testing with iperf -c -u -b 700m -d will show 25-30% of the tx packets lost the 25-30 percent can be decreased slightly if i fiddle with dtb = ethernet tx_delay but 19% is the best i could get can somebody running 14+ on an rk356x board test this on box1=20 (server) iperf -s -u on box2 rk356x (client) iperf -c -b 700m -u -d and check the packets lost by client send stream ? the problem is the same on an official sbc image (debian) thank you= From nobody Mon Nov 13 19:27:05 2023 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 4STfZZ6kTgz50Rch for ; Mon, 13 Nov 2023 19:27:18 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4STfZZ51xhz4f0B for ; Mon, 13 Nov 2023 19:27:18 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4083f613275so39921765e9.2 for ; Mon, 13 Nov 2023 11:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699903636; x=1700508436; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=d0xxHUOev9FQ9zumC2yP1Wqg6NUGLMl+f9QYnGwkw3I=; b=N4iPYFbM1fkO/sZIXgP4Nb0YWIBpBLfmQBRODQCPKY4xvsMpMj1NCCeKrAxJC9bTbC MG/kjSGWJMMdsxnX0wnyWpavL4qKrFHNaPg44vOEF4B62vxh9gRgtI0ZSAIyJ9G3oy/I K6CBVUQP1RN1yPq/WW7mj13NSYHddA8y4HQLcXnDh6WZrMes/lyr0ntcMx4Mr8lrgZGp N26+zKkM0aI1QpSL/5PcJM2FJKmsrPY96B1lahwZz0D6oXYPXhVYWBZAcL06gDbT+Pki bdYme/w5jtBoYxY3EWlqWOjngJvpYxyJ+AxM17kTwa7angG+14oxqMLSXH+Qis9Gvigg U2oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699903636; x=1700508436; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d0xxHUOev9FQ9zumC2yP1Wqg6NUGLMl+f9QYnGwkw3I=; b=MHI0xXwyZpM6XtQ3P5FNrsWRH1H1CO+CfwPdE7g6EPZSDyT+GOy1d1lqeQtRVr4QdK Y/lKfqvvMllPPQf3oHzc603F5RBNWRWTXF4W74kuRbC1EVJXUk4K2JqC+clgNCPr9ayL F0RY4KUNfDkyMllcQBAEJeYmC4zVHVTuEV99Yc9Tk/4IKuDJwLD5pdd1DToV7snKV6AQ wj9fz9VbNd+F3PUylF+J1UAdE3uLt/hAC6oIdvt6ClsVtY21SBp70vjMAqAzHgUghaHq 6Viz6kphB6qT1uB9vw4daDrvkgJLxci2ifhGOKf2KjtftGr9fL83mQ+hK20YVpuNkLNE tshQ== X-Gm-Message-State: AOJu0YzNu0sYl/O8Y13sgbRwkiPNzqJKQk5oJtZrO4oc2bN94exz/qPO PjHPXhEy4M+Dp4LCvDF+UlAFtaQbERQ= X-Google-Smtp-Source: AGHT+IGh51UkPXUzmleykNZvsDb90kzJ+hAQeJXpnq4faT/dPlReXhpWKv2hfy4Wl2IneD3qxkxXSQ== X-Received: by 2002:a05:600c:1991:b0:405:3e9a:f1e3 with SMTP id t17-20020a05600c199100b004053e9af1e3mr6206821wmq.11.1699903635926; Mon, 13 Nov 2023 11:27:15 -0800 (PST) Received: from smtpclient.apple ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id dl3-20020a0560000b8300b0032f79e55eb8sm6036262wrb.16.2023.11.13.11.27.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2023 11:27:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: eqos(4) throughput From: =?utf-8?Q?S=C3=B8ren_Schmidt?= In-Reply-To: <0FA5C2FB-B336-4DFA-AD32-05C414DDB6F7@edc.ro> Date: Mon, 13 Nov 2023 20:27:05 +0100 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <5C1C084D-00A2-4FF3-9A14-34017DC9A4EE@gmail.com> References: <0FA5C2FB-B336-4DFA-AD32-05C414DDB6F7@edc.ro> To: titus X-Mailer: Apple Mail (2.3731.700.6) 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:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Queue-Id: 4STfZZ51xhz4f0B On 13 Nov 2023, at 16.40, titus wrote: > i have this problem with eqos(4) on a rk3566 board (orangepi 3b) > when there is enough RX traffic the TX sinks packets (not all the = packets are transmitted) > this causes a max tcp uplink throughput of about 300mb/s > testing udp tx only will get to 900mbs+ > testing with iperf -c -u -b 700m -d > will show 25-30% of the tx packets lost > the 25-30 percent can be decreased slightly if i fiddle with dtb = ethernet tx_delay but 19% is the best i could get >=20 > can somebody running 14+ on an rk356x board test this > on box1=20 > (server) iperf -s -u > on box2 rk356x (client) > iperf -c -b 700m -u -d > and check the packets lost by client send stream ? I can confirm this on the boards I have access to here, quartz64, = Nanopi5, firefly station m2/p2. around 400mbit bandwitdth and 16% loss, thats running CPU at 2.2Ghz. If I set 400Mhz CPU clock I get 375mbit and 0.6% loss, thats odd at = least. Anyhow the eqos driver is far from perfect, its single queue only etc, = so there is possibly much to be gained. -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time"= From nobody Mon Nov 13 21:22:23 2023 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 4STj7M4nf4z50jmZ for ; Mon, 13 Nov 2023 21:22:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4STj7M391Dz3Nfb for ; Mon, 13 Nov 2023 21:22:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699910543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0nxexq09WxQ+sdJrn/KTVH7W0r4svBOIe6ctIpr7z0g=; b=VFsUL4/9t8U8JSBlDHEU/6oARpp9C8XXCvu1/Pth3OKBIo/Ii+HxGVVWQ+7PwR8QHjDRc/ wlsE01ubr6smJ8nT697JQH6GeCBECPBO+WjDTaMewYTNBsjBiakAnXU6W353BeJrtLaDP2 uajzpzAMaxa34lcAs9SKleygAkjialv8Nj2LEWS8L8FF7eOmTbv0DMYabsxO44YAeQTJGx aRCNsG6jNXltcQk10gnbUxNNu4SVWQ/PTq0C1Rh/OGSjWkBntnkzSjY47OfZlICv6UhyeT qozLW6oRt1mVrz7aKlSnRIjS1pzh1OM9GOyhj9ABHIFlHGXPxKamiNqj74GJ8A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699910543; a=rsa-sha256; cv=none; b=L1AHmWl0msKExvxhwlY4D27RRGJJMA9/5p5096AkhbPL9HkkxmVA2yiHVQUBnHL44CsvoF CZLzIAhMZrGdoutvNQDlK0HLYDm0b6OgdOUVmo59GR74KodLDOPSkYXzkZsPMUOeeJDCUn 969tBMgyod2FxsHvmBPiVcl14+Jihmz30K4jwEAgQ29hK66tFmB2bFl8jIrLjAzdxVH+xG CDcf1tBJyeMw6u4Js3m5W3F0CYnaOb6UvGxkLPrby/Fh+2D+KI75IsFfo9bibWuezpWDIB YlSkgSO7PYoErZx7qolTLMfj6phzvjlPWV6yAJ9eFJMkbVxoFWGZ0tHq+4WsGA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4STj7M2FMlz6Ly for ; Mon, 13 Nov 2023 21:22:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3ADLMNAL098073 for ; Mon, 13 Nov 2023 21:22:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3ADLMNSL098072 for freebsd-arm@FreeBSD.org; Mon, 13 Nov 2023 21:22:23 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 275065] FreeBSD 14 images for armv7 doesn't boot on beaglebone black Date: Mon, 13 Nov 2023 21:22:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275065 Bug ID: 275065 Summary: FreeBSD 14 images for armv7 doesn't boot on beaglebone black Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: rodrigo@FreeBSD.org Hi, The FreeBSD 14 images (armv7 GENERIC RC2, RC3 or RC4) doesn't boot in a beaglebone black. See bellow the console output. At the end of the sequence, the board reset and restart the kernel loading. The 13.2 image looks fine. Loading kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x71ad54 text=3D0x196750 data=3D0xa= f3cc data=3D0x0+0x1e4000 0x4+0xa1ff0+0x4+0x112ee2- Loading configured modules... can't find '/boot/entropy' /boot/kernel/umodem.ko text=3D0x1540 text=3D0xea0 data=3D0x238 0x4+0xe50+0x= 4+0xa6c loading required module 'ucom' /boot/kernel/ucom.ko text=3D0x19f8 text=3D0x2d18 data=3D0x4cc+0x838 0x4+0x1480+0x4+0xbcf can't find '/etc/hostid' Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x87ee4000. Kernel entry at 0x97000200... Kernel args: (null) U-Boot SPL 2022.04-ge0d31da5 (Aug 04 2023 - 18:48:26 +0000) Trying to boot from MMC2 U-Boot 2022.04-ge0d31da5 (Aug 04 2023 - 18:48:26 +0000) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB Reset Source: watchdog reset has occurred. Reset Source: Power-on reset has occurred. RTC 32KCLK Source: External. Core: 150 devices, 14 uclasses, devicetree: separate WDT: Started wdt@44e35000 with servicing (60s timeout) MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from EXT4... ** Unable to use mmc 0:1 for loading the env ** Board: BeagleBone Black not set. Validating first E-fuse MAC BeagleBone Black: BeagleBone Cape EEPROM: no EEPROM at address: 0x54 BeagleBone Cape EEPROM: no EEPROM at address: 0x55 BeagleBone Cape EEPROM: no EEPROM at address: 0x56 BeagleBone Cape EEPROM: no EEPROM at address: 0x57 Net: eth2: ethernet@4a100000, eth3: usb_ether Press SPACE to abort autoboot in 0 seconds board_name=3D[A335BNLT] ... board_rev=3D[00C0] ... switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 Couldn't find partition 0:2 0x82000000 Can't set block device Couldn't find partition 0:2 0x82000000 Can't set block device switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... 98558 bytes read in 10 ms (9.4 MiB/s) Scanning disk mmc@48060000.blk... Scanning disk mmc@481d8000.blk... Found 5 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootarm.efi 852268 bytes read in 58 ms (14 MiB/s) Booting /efi\boot\bootarm.efi Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm EFI loader, Revision 1.1 Command line arguments: l Image base: 0x9ce40000 EFI version: 2.90 EFI Firmware: Das U-Boot (rev 8226.1024) Console: efi,comconsole (0) Load Path: /efi\boot\bootarm.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x800,= 0x19000) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x800,= 0x19000) Setting currdev to disk0p1: Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x1980= 0,0x9e6800) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local / --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Nov 15 01:05:50 2023 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 4SVQ334Lq6z51KhH for ; Wed, 15 Nov 2023 01:06:07 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Received: from mailgate.us (mailgate.us [185.72.246.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4SVQ316dvJz4KtM for ; Wed, 15 Nov 2023 01:06:05 +0000 (UTC) (envelope-from stanislav.silnicki@mailgate.us) Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailgate.us header.s=mail header.b=AoybMpcF; spf=pass (mx1.freebsd.org: domain of stanislav.silnicki@mailgate.us designates 185.72.246.236 as permitted sender) smtp.mailfrom=stanislav.silnicki@mailgate.us; dmarc=none Received: from localhost (api.telegram.org [192.168.2.1]) by mailgate.us (Postfix) with ESMTPSA id 1F1CC9C9AE for ; Wed, 15 Nov 2023 04:05:56 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailgate.us; s=mail; t=1700010358; bh=ZDq35LSTfwoo8ssHxkp1Sv07f4DDOgPx46eOug3M7FU=; h=From:Subject:To:References:Date; b=AoybMpcFRrm2WjkUBjROI1QKO9caLs3LWLVJ7sTABpefxPYqfuFdmJ41Ym+J6xVVq /wp+76a2xsBZgTQzkw7PJmEQ1H/DUaEYaf5k/wAbZUe4QrNlF/YFCpjd3b0bc+4HDI LRBftBwPZoifCWoWzXIXwUvRLGFVbxlXwq8LZstg= Content-Type: multipart/alternative; boundary="----sinikael-?=_1-17000103510760.4220450064604129" From: Stanislav Silnicki Subject: Re: STM32MP157 X-Type: reply To: "freebsd-arm" User-Agent: Desktop Message-Id: <0926803a4f0a.17799edcfe428@mailgate.us> References: <4d6bf0126f4fb.c24cc5f2fa47c@mailgate.us> <00cab7929791c.8af55c0bd1d5f@mailgate.us> <5d65957f4c04a4bec7ae6ef5469b149c@ohdata.se> <0dab0fc75864.77e1118ea80bb@mailgate.us> <5aa7e3eff95c.2102a80bb1a3b@mailgate.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Nov 2023 01:05:50 +0000 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 X-Spamd-Result: default: False [1.49 / 15.00]; URI_COUNT_ODD(1.00)[25]; R_DKIM_REJECT(1.00)[mailgate.us:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.93)[0.930]; SUBJ_ALL_CAPS(0.75)[10]; R_SPF_ALLOW(-0.20)[+ip4:185.72.246.236/32]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:47447, ipnet:185.72.246.0/24, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[mailgate.us:-]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[mailgate.us]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4SVQ316dvJz4KtM X-Spamd-Bar: + ------sinikael-?=_1-17000103510760.4220450064604129 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: 7bit STM32MP15x port current progress: ... it took some time to solder down the probe and establish conveniences with remote kernel debug... So far, I need to understand, whither or not I face an expected behavior? It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14) destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0.... here is a dump of my debug session around that code: 508 cp15_prrr_set(prrr); (kgdb) i f Stack level 0, frame at 0xc0784598: pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c called by frame at 0xc07847e0 source language c. Arglist at 0xc0784590, args: Locals at 0xc0784590, Previous frame's sp is 0xc0784598 Saved registers: r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594 (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 509 cp15_nmrr_set(nmrr); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) n stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled 512 tlb_flush_all_local(); (kgdb) x 0xc0784594 0xc0784594: 0xc055254c (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled _CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147 147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */ (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340 340 dsb(); (kgdb) x 0xc0784594 0xc0784594: 0x00000000 (kgdb) si stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41 stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41 target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600001f3 pc: 0x0000060e MMU: disabled, D-Cache: disabled, I-Cache: enabled pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) si Polling target stm32mp15x.cm4 failed, trying to reexamine Failed to read memory at 0xe000ed00 Examination failed, GDB will be halted. Polling again in 100ms Program stopped. pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513 513 } (kgdb) The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor. I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice. Any? Stan Stanislav Silnicki wrote: my current progress of STM32MP1xx port attempt: Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported. Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with this line: https://github.com/freebsd/freebsd-src/blob/501bdf3001190686bf55d9d333cb533858c2cf2f/sys/arm/arm/locore-v6.S#L371 control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else: /* prepare to use LED @ GPIOA 13*/ ldr r0, =0x50002014 ldr r1, =0xFFFFDFFF ldr r2, [r0] and r2, r1, r2 /* Enable caches. */ mrc CP15_SCTLR(r7) orr r7, #CPU_CONTROL_DC_ENABLE orr r7, #CPU_CONTROL_IC_ENABLE orr r7, #CPU_CONTROL_BPRD_ENABLE mcr CP15_SCTLR(r7) DSB /* turn on GPIO LED */ str r2, [r0] Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below... I thought it was due to security access control from TF-A, but it behaves the same w/o. Any clues or expertise from other platforms are highly appreciated. Stan Stanislav Silnicki wrote: Hello, I need an advice on the intial addresses layout when booting the kernel. As I understand, ubldr is the proper way to boot the kernel. What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact? The u-boot loads ubldr this way in my current setup: // FreeBSD version of environment env_set("baudrate", "115200"); env_set("console", "ttyS0,115200"); env_set("stderr", "serial"); env_set("stdin", "serial"); env_set("stdout", "serial"); env_set("autostart", "yes"); env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1 env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf"); then ubldr leads the kernel from mmc and passes it the control: Loading kernel... /boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98| Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' Using DTB compiled into kernel. Kernel entry at 0xc0400200... Kernel args: (null) Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow. So, just need to understand what is best option to load ubldr to? Will it affect further routines? Stan Stanislav Silnicki wrote: OK, I got the idea! As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix. My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky). https://www.karo-electronics.com/fileadmin/download/Datasheets/QSMP-QSBASE1-Evalkit.pdf The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than ; ; ;try to post PR's in those repos... Not sure, anyway. So far I'm struggling with uart and early_printf... I'm mixing this activity with my current occupation, so I don't expect rapid progress. Thank you for clarifications! I'll try to do my best! Stan Oskar Holmlund wrote: Hi Stanislav, Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port. You should always keep one terminal up n running % man 9 style :) https://wiki.freebsd.org/Phabricator will give you some information. Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people. Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff. Start with small changes and you will get feedback. From there the experience will grow and you will get into it all. Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either. Probably because the STM32MP15 is the first(?) application SoC from ST? 1) hum? Do you need that for the reviews? It should be in SRC 2) Target branch is probably main. 3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board. For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process. //Oskar 2023-10-28 14:25 skrev Stanislav Silnicki: Hi Oskar! > can you point me some guidelines to help myself to fit development process? I'm sure, there is mature dev. culture around FBSD and I'd be happy to make my contribution coherently from the beginning. > So far I'm done with setup of my account at reviews (keys, 2FA, etc.) > As I understand, there is no considerable progress with STM32, although I have noticed, there are some DTS imported into the project. > > Indeed, several major questions: 1. repo url? 2. tagret branch for patches for stm32 hw? 3. is it possible to target custom board from our project, or I have to ensure support for all dev. boards, provided by STM? > Thank you,Stan > Oskar Holmlund wrote: >> 2023-10-27 22:33 skrev Stanislav Silnicki: >>> Hello! I'm porting onto the subject hardware. So far the progress is modest, while the system boots (without console although...) One of major issues is hardcoded value inside locore-v6.S. Here is my relevant post: >> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 [1] What is the best way to proceed? Patch, vendor kernel build, something else? Stan > Links: ------ >> [1] > > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438 >> Hi Stan, >> Upload your patch to reviews.freebsd.org >> Love to see your other patches for the STM32MP15x. kquote> > //Oskar ------sinikael-?=_1-17000103510760.4220450064604129 Content-Type: text/html; format=flowed Content-Transfer-Encoding: 7bit
STM32MP15x port current progress:

... it took some time to solder down the probe and establish conveniences with remote kernel debug...

So far, I need to understand, whither or not I face an expected behavior?

It looks like tlb_flush_all_local() (https://github.com/freebsd/freebsd-src/blob/525ecfdad597980ea4cd59238e24c8530dbcd31d/sys/arm/arm/pmap-v6.c#L512C14-L512C14)
destroys stack memory, where return address is stored, so when stored lr is poped into pc, it is 0x0....

here is a dump of my debug session around that code:

508 cp15_prrr_set(prrr);
(kgdb) i f
Stack level 0, frame at 0xc0784598:
 pc = 0xc0557b44 in pmap_set_tex (/usr/src/sys/arm/arm/pmap-v6.c:508); saved pc = 0xc055254c
 called by frame at 0xc07847e0
 source language c.
 Arglist at 0xc0784590, args: 
 Locals at 0xc0784590, Previous frame's sp is 0xc0784598
 Saved registers:
  r4 at 0xc0784580, r5 at 0xc0784584, r6 at 0xc0784588, r10 at 0xc078458c, r11 at 0xc0784590, lr at 0xc0784594
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
509 cp15_nmrr_set(nmrr);
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) n
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
512 tlb_flush_all_local();
(kgdb) x 0xc0784594
0xc0784594: 0xc055254c
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
_CP15_TLBIALL () at /usr/src/sys/arm/include/cpu-v6.h:147
147 _WF0(_CP15_TLBIALL, CP15_TLBIALL) /* Invalidate entire unified TLB */
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
tlb_flush_all_local () at /usr/src/sys/arm/include/cpu-v6.h:340
340 dsb();
(kgdb) x 0xc0784594
0xc0784594: 0x00000000
(kgdb) si
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu1 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600001f3 pc: 0x0000060e
MMU: disabled, D-Cache: disabled, I-Cache: enabled
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) si
Polling target stm32mp15x.cm4 failed, trying to reexamine
Failed to read memory at 0xe000ed00
Examination failed, GDB will be halted. Polling again in 100ms

Program stopped.
pmap_set_tex () at /usr/src/sys/arm/arm/pmap-v6.c:513
513 }
(kgdb) 

The address, referenced from error message (0xe000ed00) is mapped by STM's address space to "DDR extension (CA7 only) or Debug" with debug assigned to Cortex-M4 coprocessor.

I'm not sure, that it is an unexpected behav. (it is my first attempt to port to armv7), so need an advice.
Any?

Stan


Stanislav Silnicki wrote:

my current progress of STM32MP1xx port attempt:

Basically, both options to boot ubldr and then kernel in SPL & TF-A modes of u-boot are supported.

Initially, when I stated from TF-A options (security supervision from arm's trusted firmware os) I stuck with 

control does not seem to reach beyond that point. I tried to enable the led with this assembly, which works anywhere else:

    /* prepare to use LED @ GPIOA 13*/
    ldr r0, =0x50002014
    ldr r1, =0xFFFFDFFF
    ldr r2, [r0]
    and r2, r1, r2

/* Enable caches. */
mrc CP15_SCTLR(r7)
orr r7, #CPU_CONTROL_DC_ENABLE
orr r7, #CPU_CONTROL_IC_ENABLE
orr r7, #CPU_CONTROL_BPRD_ENABLE
mcr CP15_SCTLR(r7)
DSB

    /* turn on GPIO LED */
    str r2, [r0]

Control passes if I disable data cache ORing instruction, but then hangs on setting of new TTB couple lines below...

I thought it was due to security access control from TF-A, but it behaves the same w/o.

Any clues or expertise from other platforms are highly appreciated.

Stan

Stanislav Silnicki wrote:

Hello, I need an advice on the intial addresses layout when booting the kernel.

As I understand, ubldr is the proper way to boot the kernel.
What is the correct address to load it, given that I wand to keep default KERNVIRTADDR (=0xc0000000) intact?

The u-boot loads ubldr this way in my current setup:

  // FreeBSD version of environment
  env_set("baudrate", "115200");
  env_set("console", "ttyS0,115200");
  env_set("stderr", "serial");
  env_set("stdin", "serial");
  env_set("stdout", "serial");
  env_set("autostart", "yes");
  env_set("loaderdev", "mmc 1"); // fbsd's ubldr treats our second mmc at index 1
  env_set("bootcmd", "fatload mmc 2 0xc0000000 ubldr && bootelf");

then ubldr leads the kernel from mmc and passes it the control:

Loading kernel...
/boot/kernel/kernel text=0x1b4 text=0x5b8530 text=0x17d91c data=0xa4a60 data=0x0+0x20c000 0x4+0x88810+0x4+0xe9d98|
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'
Using DTB compiled into kernel.
Kernel entry at 0xc0400200...
Kernel args: (null)

Then I could correctly pass the init of MMU and get into translated mode only with setting KERNVIRTADDR = 0xc4000000. It looks like kernel and loader clash somehow.

So, just need to understand what is best option to load ubldr to? Will it affect further routines?

Stan


Stanislav Silnicki wrote:


OK, I got the idea!

As I realize, there is a minor bug in dtc, which affects compilation of stm's originated DTBs. I think it is best to make a PR into https://github.com/davidchisnall/dtc, which I'm discussing with repo owner already. Please tell me, that I need to post PR into FBSD source tree if it is a shorter way for my fix.

My current setup is based upon QBASE1 from Karo-Electronics, but there is no goal to support/debug all peripherals, only a subset, including USB, I2C, SDMMC, DSI (and GPU, if lucky).

The vendor (Karo) supports only their Yocto based Linux distro. I spent some time to prepare TF-A & Uboot, capable with booting from SD card (that is more robust approach, as I think). STM does not promote/support non-secure boot approach with SPL, they insist to use TF-A or OPTEE, so it is pretty cumbersome path, I had to pass. I think, it will be easier for me to prepare some sort of README to support customization of uboot for STM's port and dig it somewhere in SRC rather than  ; ; ; ;try to post PR's in those repos... Not sure, anyway.

So far I'm struggling with uart and early_printf...

I'm mixing this activity with my current occupation, so I don't expect rapid progress.

Thank you for clarifications! I'll try to do my best!

Stan

Oskar Holmlund wrote:


Hi Stanislav,

Please resend your message and CC the arm mailing list. It might be interesting for someone in the future ( https://lists.freebsd.org/archives/freebsd-arm/ ) otherwise they all think you stopped working on the STM32 port.

You should always keep one terminal up n running % man 9 style :)
https://wiki.freebsd.org/Phabricator will give you some information.
Its good if you get to know the people active in the ARM area, just keep an eye on the mailinglist and you will notice some names. If you have the opportunity to join any of the conference (eurobsdcon.org, asiabsdcon.org, bsdcan.org) to get to know even more people.
Join the IRC, for example on efnet #bsdmips is a good channel for ARM stuff.

Start with small changes and you will get feedback. From there the experience will grow and you will get into it all.

Correct, the device-tree import is from the Linux kernel and there is no prior work for the STM32MP15 SoCs. I cant find anything about the STM32MP15x in Net or OpenBSD either.
Probably because the STM32MP15 is the first(?) application SoC from ST?


1) hum? Do you need that for the reviews? It should be in SRC
2) Target branch is probably main.
3) It depends, if your custom board is opensource and availble around the globe through mouser/farnell/.. I dont see any problem. Otherwise pick the board from ST that you used as a reference when you developed the custom board.
For example in my day job we have a custom board built around the octavosystems OSD3358 that can be found in pocketbeagle/beaglebone black wifi. So the code thats goes into the FreeBSD project are all tested on the beaglebone boards. The stuff we need for our custom board like the device tree is keept as local patches in our inhouse build process.

//Oskar

2023-10-28 14:25 skrev Stanislav Silnicki:

Hi Oskar!
> can you point me some guidelines to help myself to fit development
process? I'm sure, there is mature dev. culture around FBSD and I'd be
happy to make my contribution coherently from the beginning.
> So far I'm done with setup of my account at reviews (keys, 2FA, etc.)
> As I understand, there is no considerable progress with STM32,
although I have noticed, there are some DTS imported into the project.
> > Indeed, several major questions:
1. repo url?
2. tagret branch for patches for stm32 hw?
3. is it possible to target custom board from our project, or I have
to ensure support for all dev. boards, provided by STM?
> Thank you,Stan
> Oskar Holmlund wrote:
>> 2023-10-27 22:33 skrev Stanislav Silnicki:

quote class="gmail_quote" type="cite" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> Hello!


I'm porting onto the subject hardware. So far the progress is
modest,
while the system boots (without console although...)
One of major issues is hardcoded value inside locore-v6.S. Here
is my
relevant post:
>> > https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
[1]
What is the best way to proceed? Patch, vendor kernel build,
something
else?
Stan



> Links:

------
>> [1] >
> https://community.st.com/t5/stm32-mpus-embedded-software/freebsd-port-for-mp157c/td-p/601438
>> Hi Stan,
>> Upload your patch to reviews.freebsd.org
>> Love to see your other patches for the STM32MP15x.

kquote>

>> //Oskar
------sinikael-?=_1-17000103510760.4220450064604129-- From nobody Thu Nov 16 11:33:05 2023 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 4SWHw12bBtz50Xhb for ; Thu, 16 Nov 2023 11:33:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SWHw10jnVz4RWd for ; Thu, 16 Nov 2023 11:33:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700134385; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j6uT1x/dmN1JDDo8ppk5/FcXmHEhj947qPDClYnjAxQ=; b=s4xvIW967hH5kanN+/+fOK9Cb0ra59p8Q61QoVtC3HAnSpWJfPXeu3TnKtKy5q17URR+7A 1gRZ3fq65Y4ylNt1VS/ZbUaAWj2ifQBPX7pObOpCovXW0DljXu/zOowMvxvStPiJNXo6MA G5PL9ONbZuCTvANI7HMhhfVME7j74HRPzLkxwCiZVv4S5GB7ik5WFyKXH4jxaTouhVN0dg kYc6vgtFAaoFOazKFxIBwh8Kc0FIHS79O1C+h8SFyMslTa+wc9kAJdTei1HKKIXPrYfu6e Cjv5msw85OiNqE9K3yfFJCxHvQxI0GHwv3GLubQ3IzDWpVq2BOuHJvjy1cQ2HQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700134385; a=rsa-sha256; cv=none; b=QtEUm5rgXifcrHm2PgYtzhHn+L3pP9eDaCYM4Hh+6h7UnfTsAKaFBlI7rcFOrSkfVWcphe G+xZm22mWLxdclaurnTm9vWzz8w+8G7zyj5WN4sCZF6qUMEfxQSOfbGAtlR8Zu5b/7F3h/ OU3Ov1P+5T1DHDpIy/YAsi4VsAv7rfkZrHAhbOPTSvcU3g6SND88+CSt9Nx93FXKCtvbIH XSIbyV31WSW2gGsT70N5dNIb8TWifHem6k2gNEowU2IR/72DcDPAaJmjVgl7TbCKW+0HG9 90QGUrNkcSlQwCMFn73wHSUh8mf6PgZB2xye4zNzPWGMz3GNVZXZJyn7Kp/hIg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SWHw06tGjzyGD for ; Thu, 16 Nov 2023 11:33:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3AGBX4fU061702 for ; Thu, 16 Nov 2023 11:33:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3AGBX4Xo061701 for freebsd-arm@FreeBSD.org; Thu, 16 Nov 2023 11:33:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 248490] RPi4: gpioled witness warnings and a LOR (exclusive sleep mutex LED mtx) Date: Thu, 16 Nov 2023 11:33:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gbe@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248490 Gordon Bergling changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Nov 16 11:33:46 2023 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 4SWHwp2cS9z50Xg3 for ; Thu, 16 Nov 2023 11:33:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SWHwp19YFz4Rv7 for ; Thu, 16 Nov 2023 11:33:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700134426; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UnNbE8cjMU30ADHErcRKokRy04ctD6e4FqybOAC4xp8=; b=YLiSVlH1a0g8l04lCOPRRyIv6tA558OIVIqtPlckdn4Ya5AgbcK2mp3w27YbLdU7qLlepK Fop8wqOAbwzDRcFi0jcprlNK6KlA3V+fxAiY5Pb9J8P2WI5jmRO7gvj6wSqoOYCcHtQ+wT 8Kx7dOGmPO83TC8b3u5SeTXotCETeT4zAXG0WnoORgxTn3lUKJRrzizT23G8uBmhFFVMu6 ZcAVLDZ1qKYno2kRtP8KrNpNwmSKs2J3Zf9uGaI7OI+aptY3zV747fcsYFf8Vw0XXh0Dwf lpjLSc6lUYto7DqT23LBVN9umk+eUPfQb1unTCWSLmpskR4NSmCduPxkrgxROQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700134426; a=rsa-sha256; cv=none; b=KxswGVKEl/60PqulRXUcU4GeCZ1SNRyHtt4hMeWcd/pbxaEkx2aZ2KCCXhu7vIWQV/lzb/ 4BoujWSEDSap1EYeCmcNxgDLaDPSmDPV3mitUdJn31/jsD74S9YUv7atYNpzcknIB1tjO+ s9Y8edZ3NHZPYry2LtTn6c8i+cYtDotNqpYAzkmoi3LZlBw6vAHQAbJmz57Smin18k6Gx4 WIpY3Qh4CxTAU29p6W7zCH874Pqaewc7aH4Al8nhbYdRByWNj0suKsN277VW52PG6NB6mz ERGgosY1afDoAH2q3A9h3BRNYEmlhXOoRaO/tkusRCWqUctCQv978sYKNw3aWg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SWHwp0DQ7zy6C for ; Thu, 16 Nov 2023 11:33:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3AGBXjNb061847 for ; Thu, 16 Nov 2023 11:33:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3AGBXjwZ061846 for freebsd-arm@FreeBSD.org; Thu, 16 Nov 2023 11:33:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 254755] arm64: USB keyboard is detected to late, so a single user mode isn't possible Date: Thu, 16 Nov 2023 11:33:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: gbe@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254755 Gordon Bergling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |Overcome By Events --=20 You are receiving this mail because: You are the assignee for the bug.=