From owner-freebsd-arm@freebsd.org Sun Jun 14 00:30:45 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C4D29346CC2 for ; Sun, 14 Jun 2020 00:30:45 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49kwNh2TQNz4fsF for ; Sun, 14 Jun 2020 00:30:43 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Sun, 14 Jun 2020 00:30:34 +0000 To: =?utf-8?Q?Klaus_K=C3=BCchemann?= From: Robert Crowston Cc: "freebsd-arm@freebsd.org" Reply-To: Robert Crowston Subject: Re: Report: FreeBSD on Rpi4 8 GB model Message-ID: In-Reply-To: <65649C30-79B7-4001-ABBF-71E2C8F52B06@googlemail.com> References: <65649C30-79B7-4001-ABBF-71E2C8F52B06@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49kwNh2TQNz4fsF X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.48 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-0.38)[-0.382]; FREEMAIL_TO(0.00)[googlemail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.18:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.015]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.980]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.18:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 00:30:45 -0000 A fix for the XHCI firmware loading is here: https://reviews.freebsd.org/D2= 5261 (It requires working PCI-E, which is in progress, here: https://reviews.fre= ebsd.org/D25068) A fix for the change to the phy-mode on the genet driver is here: https://r= eviews.freebsd.org/D25251 -- RHC. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, 10 June 2020 14:37, Klaus K=C3=BCchemann wrote: > > > > Am 10.06.2020 um 01:16 schrieb Robert Crowston via freebsd-arm freebsd-= arm@freebsd.org: > > I figured out how to start the xhci driver. > > The snag is, it seems the message to the VC to reinstall the xhci firmw= are has to be delivered after the bridge memory window is configured on the= controller by the pci_pci bridge, and before the xhci controller is starte= d. > > That kind of ordering is not straightforward to arrange, as far as I ca= n see: I cannot hack the message onto the end of the pcie attach function, = since we need the bridge child to have attached, but not the xhci grandchil= d. > > I think the best way then is to create a shim driver for the xhci contr= oller whose probe() is designed only to succeed on the Rpi4. The shim's att= ach() will instruct the VC to load the xhci firmware, and then defer to the= generic xhci_pci_attach(). All other methods will be inherited from the xh= ci_pci driver. > > Another idea is to put the logic directly in the xhci_pci.c file, but I= think creating a dependency out to the Rpi4 mailbox API from the generic X= HCI framework is quite a hack. > > Anyone have any thoughts? > > Since your driver is dedicated RPi4_ONLY your shim-if_bcm_thing sounds lo= gical. > Especially when we consider that you think that this is the best way, > because nobody knows more about your driver than you :-) From owner-freebsd-arm@freebsd.org Tue Jun 16 21:38:45 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 37770335C7C for ; Tue, 16 Jun 2020 21:38:45 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49mhQr29Wmz3XQt for ; Tue, 16 Jun 2020 21:38:44 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Tue, 16 Jun 2020 21:38:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1592343521; bh=EfFBEDArkGWxNcPAQMLnuUHAJ+R31tHhx0uZlUAIkzg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=vJfqTWbMtzho0uy5hSQX8iPfv1NI/q/lGaNQHLhqBOSq8wNdjHRhLFqDkhxa/uRsj R61jMo2ioZtgpQAFlkO3oxJEcAumNnFA/PI4WMyF54sW1t1MDENWsuSHN/UtRXhNep oJWeTe9GQMUTUt5ImPT0Lk+4CW2aX/G7wrPqYKTA= To: Dan Kotowski From: Dan Kotowski Cc: "greg@unrelenting.technology" , freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49mhQr29Wmz3XQt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=vJfqTWbM; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.52 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.982]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.46)[-0.458]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.134:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 21:38:45 -0000 > AHCI is looking better and better! > I'm going to do a little bit of poking at that > SATA HDD just to see how stable it really is. Well, it's definitely stable enough for lab use, that's a bonus. I caused m= yself a few headaches by doing stupid things that caused a series of panics= , but all are easily attributed to human errata... Oddly the i2c bus is gone - any ideas what we changed that caused it to dis= appear? https://gist.github.com/agrajag9/03d9f2f52084ef0ae1e64cbba190e062 If I'm reading the DSDT correctly, then it should be hanging right off acpi= 0. We can even see it in an older dmesg.boot: i2c0: iomem 0x2000000-0x200f= fff irq 7 on acpi0 But now, nothing... Aside - since the builtin netifs are basically useless for us, any suggesti= ons on USB wifi dongles? I tried a few from my parts piles, but all of them= were unstable Realtek trash. I know Atheros chips are usually a good bet i= n Linux land - does that hold true in FreeBSD as well? From owner-freebsd-arm@freebsd.org Tue Jun 16 21:57:45 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1A9383366D6 for ; Tue, 16 Jun 2020 21:57:45 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49mhrl5h3tz3YQf for ; Tue, 16 Jun 2020 21:57:43 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Tue, 16 Jun 2020 21:57:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1592344656; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1mhnubiVUQScGsFuZHVsqYbdg/da9VeeamWAJ+PnuDk=; b=EF95hVl93bG9E+d41OTe4aJ6QmIC+yGRKopcrBm/lBRo+uavbe4StqZKMWC0kxF3YsL/XW XhKUjDBchw5T8181UDBphh367CMlK/gfK6CFJ5xVCyaQLx7foo+rI0fRtOJ7z248eh2c0L 14kg/4FnmcsX11Ii+R6cRS+okrPvy0Q= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Dan Kotowski CC: freebsd-arm Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X In-Reply-To: References: <32d1c173d986884efb9b28932c0ead52@unrelenting.technology> <5e1b4bfe845e62bbcd8b827fa37f2b98@unrelenting.technology> <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49mhrl5h3tz3YQf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=EF95hVl9; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.62 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.67)[-0.667]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[91.121.223.63:from]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 21:57:45 -0000 On June 16, 2020 9:38:34 PM UTC, Dan Kotowski wrote: >> AHCI is looking better and better! >> I'm going to do a little bit of poking at that >> SATA HDD just to see how stable it really is=2E > >Well, it's definitely stable enough for lab use, that's a bonus=2E I caus= ed myself a few headaches by doing stupid things that caused a series of pa= nics, but all are easily attributed to human errata=2E=2E=2E > >Oddly the i2c bus is gone - any ideas what we changed that caused it to d= isappear? > >https://gist=2Egithub=2Ecom/agrajag9/03d9f2f52084ef0ae1e64cbba190e062 > >If I'm reading the DSDT correctly, then it should be hanging right off ac= pi0=2E We can even see it in an older dmesg=2Eboot: > >i2c0: iomem 0x2000000-0x20= 0ffff irq 7 on acpi0 > >But now, nothing=2E=2E=2E Probably because I deleted that i2c acpi attachment at some point, because= it didn't seem to actually work=2E=20 >Aside - since the builtin netifs are basically useless for us, any sugges= tions on USB wifi dongles? I tried a few from my parts piles, but all of th= em were unstable Realtek trash=2E I know Atheros chips are usually a good b= et in Linux land - does that hold true in FreeBSD as well? Not sure how common Atheros is on USB=2E=2E Ralink is fine I think? Actual= ly Realtek wifi shouldn't be unusable too=2E=2E For USB Ethernet though, I recommend the "Nintendo Switch compatible" ASIX= chips (axge)=2E By the way, did you get any different firmware builds in the meantime? Tha= t don't have everything suspiciously routed to the SMMU in IORT=2E=2E From owner-freebsd-arm@freebsd.org Wed Jun 17 04:34:47 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD58F3424FF; Wed, 17 Jun 2020 04:34:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49msft5mw5z4GNd; Wed, 17 Jun 2020 04:34:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 05H4Yhxx070899 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 16 Jun 2020 21:34:43 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 05H4YhQ0070898; Tue, 16 Jun 2020 21:34:43 -0700 (PDT) (envelope-from fbsd) Date: Tue, 16 Jun 2020 21:34:42 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: freebsd-ports@freebsd.org, bob prohaska Subject: Which u-boot for rpi3? u-boot-rpi3-32 or the old one? Message-ID: <20200617043442.GA70470@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 49msft5mw5z4GNd X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [3.70 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.42)[0.425]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.09)[-0.085]; NEURAL_SPAM_LONG(0.46)[0.460]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 04:34:47 -0000 Just noticed there are now two u-boot ports for the RPi3, one called u-boot-rpi3-32 and (the presumably original) u-boot-rpi3. The descriptions are equally bland, what's the difference? The goal is to boot a recent snapshot of -current from USB using a Pi3b (no +). Now it's suffering from cpu_reset failed. Thanks for reading, apologies if it's a dumb question... bob prohaska From owner-freebsd-arm@freebsd.org Wed Jun 17 04:59:30 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD2B3342E8B for ; Wed, 17 Jun 2020 04:59:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-15.consmr.mail.bf2.yahoo.com (sonic313-15.consmr.mail.bf2.yahoo.com [74.6.133.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49mtCP6c9dz4HG7 for ; Wed, 17 Jun 2020 04:59:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: r5LKds0VM1nolgtsoaAP9xN8gXRKm5_j5038MVZOSN2E6B1hrmbDzxa_Acwi8sr truZg8S36fjnUv4tb9wHNx6s5lbVj_pR.pT985Xa_TnAmmtKm73ogApIVyerCfneLtIAcjbEYEDb 30MQW.oNLGg.cL5Bg8eeQE.y_g0h9V0ed1NRmcyvemGmnviZnF9XUIeZd1xTqexqazl6Gan.VfYx YNSJpGaTQ7CO5JpDPqX8qRdQBk6CJ2CwPM8SCM7ODqjo0SYGPxDMdHMsV5X4MUyxeoBw5NtTnOn_ JeQXL73fL9kRkJDxhzHUITtiFpWRumSXj8StsO1NXasUrIllVsu7zX._vw8goKl7dfUhRUI8svOj pc3YaxEqkStwP7p8mpol1wnZ.rJY_NXN.eilUIexzBIu8AKqYy0r7KkUzTq1waEohb.lT5wwVuJQ OfqvrTPKs6cvzibW4tyrxLmRBLHxdcuDlAfGUV27oi_zJ_6goKtPgT8VijZddKyME0cqfSi3R5Jm jO7NFyGgQ.zt1v_SsMe6GeNK_O0ypIlYQzPI7JRK2pKN9UQncZVAlyCVf6g5hzunTusQFBwR0r_X jrmOwTHXWdcD9Rn_lKYmtjsOAZts2H0Rj3Qf5GSrsQQdkIqG5CqbV8Xp7KAwtlzP5Oq0dfvn3rrg I4ONXeAQbAWQN.sOm4ATSY4R0bwlht6H9OjphB3P3nWKd_vzIdR58gkLazri8PryleAhB2bWGXm3 fwS0Lwe.W5tAIImmOtSadJrqzJEHylsfYmqk71B9ZLgMvMfv_9M0ORtMRc9nXnrPqoFYTWvRcOSN Dl.1ZIgxx2COy_Vw5ybYBhQbcjwSq.2YzDukKjY1Ew38KyUgcbLmCNPVLJSnl9XasUXEBJPFSQvI VmlUv2cTdWhW2ubitg4OzYECYcFI9xVdeB0biLfBo64EgWrhBBB3aULirR2TgPbZ3cqgKP39vt3A vdKAHdrKREAvKQ14jbeQSiyKrCRV6PPuKsEI75hRBRlKFuleOonmLhF3.TFBRpc.KHdQq.mjLJ_A llUBQcrPJcoEnBhVbk.RVBLrBfJt2wIsu.W7TEojpxEsjY6JGN4BvFMaiPJmaKA8l9qvz8J.zwtD mkqpjhE7CWKIIHqOC1qyphm.lPUsLnFNUXIXbYC_XYdRuTwevBezdNKPC_hs65T69TV7wYipSMwI tgpFL6GaNomUwHAuG31VuTD_PGOngFYed8fHWNUu.BvEs6Zz3OckvjLL5oncz6vejSFfe4HKAzss cpmeDS0YkkQuIOxRc6JmB4h0UdJxpWDQwUg05e3u8bqJiDmNRGqj44NtKk26QFqL7o6RmI.iyZkx 4UYs0NMHZ46Mv5ypAErpemtPnRVbMil3nKRPm2PC0QGnOTB06w3Ng7QnEQ2VJg.74GBdlasEYjOr ghZGtDNTUwsVjSfLwKsKEmw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Jun 2020 04:59:29 +0000 Received: by smtp430.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ba261cf552c3262b27e6ef0677d52176; Wed, 17 Jun 2020 04:59:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Which u-boot for rpi3? u-boot-rpi3-32 or the old one? From: Mark Millard In-Reply-To: <20200617043442.GA70470@www.zefox.net> Date: Tue, 16 Jun 2020 21:59:24 -0700 Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20200617043442.GA70470@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49mtCP6c9dz4HG7 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.21 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.88)[-0.880]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.846]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.99)[-0.989]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.6.133.125:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.133.125:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 04:59:30 -0000 On 2020-Jun-16, at 21:34, bob prohaska wrote: > Just noticed there are now two u-boot ports for the RPi3, one > called u-boot-rpi3-32 and (the presumably original) u-boot-rpi3. > > The descriptions are equally bland, what's the difference? > The goal is to boot a recent snapshot of -current from USB > using a Pi3b (no +). Now it's suffering from cpu_reset failed. Looking, the check in history for sysutils/u-boot-rpi3-32 reports for the creation of sysutils/u-boot-rpi3-32 : Revision 536829 - Directory Listing Added Fri May 29 01:27:16 2020 UTC (2 weeks, 5 days ago) by brd Add sysutils/u-boot-rpi3-32 to build a 32-bit version of u-boot This is useful for using the camera hardware, as misc/raspberrypi-userland does not support aarch64. Approved by: imp, manu Differential Revision: https://reviews.freebsd.org/D21603 So: A) sysutils/u-boot-rpi3 is for use with aarch64 FreeBSD B) sysutils/u-boot-rpi3-32 is for use with armv7 FreeBSD === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jun 17 05:21:51 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B0F7C343473; Wed, 17 Jun 2020 05:21:51 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49mtjB3cCbz4JXm; Wed, 17 Jun 2020 05:21:50 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 05H5Lrjp070982 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 16 Jun 2020 22:21:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 05H5LrUI070981; Tue, 16 Jun 2020 22:21:53 -0700 (PDT) (envelope-from fbsd) Date: Tue, 16 Jun 2020 22:21:52 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Which u-boot for rpi3? u-boot-rpi3-32 or the old one? Message-ID: <20200617052152.GB70470@www.zefox.net> References: <20200617043442.GA70470@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 49mtjB3cCbz4JXm X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [4.37 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.09)[0.092]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.70)[0.697]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.68)[0.680]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 05:21:51 -0000 On Tue, Jun 16, 2020 at 09:59:24PM -0700, Mark Millard wrote: > > > On 2020-Jun-16, at 21:34, bob prohaska wrote: > > > Just noticed there are now two u-boot ports for the RPi3, one > > called u-boot-rpi3-32 and (the presumably original) u-boot-rpi3. > > > > The descriptions are equally bland, what's the difference? > > The goal is to boot a recent snapshot of -current from USB > > using a Pi3b (no +). Now it's suffering from cpu_reset failed. > > Looking, the check in history for sysutils/u-boot-rpi3-32 Could you write a few words about how one checks such history? There doesn't seem to be anything in /usr/ports/UPDATING. > reports for the creation of sysutils/u-boot-rpi3-32 : > > Revision 536829 - Directory Listing > Added Fri May 29 01:27:16 2020 UTC (2 weeks, 5 days ago) by brd > Add sysutils/u-boot-rpi3-32 to build a 32-bit version of u-boot > > This is useful for using the camera hardware, as > misc/raspberrypi-userland does not support aarch64. > > Approved by: imp, manu > Differential Revision: > https://reviews.freebsd.org/D21603 > > > So: > > A) sysutils/u-boot-rpi3 is for use with aarch64 FreeBSD > B) sysutils/u-boot-rpi3-32 is for use with armv7 FreeBSD > > Mine is case A, but Case B is a little puzzling; will armv7 run on a Pi3 ? I thought arm64 was mandatory. Thanks for reading and the speedy reply! bob prohaska From owner-freebsd-arm@freebsd.org Wed Jun 17 06:32:09 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1CEF3450AC for ; Wed, 17 Jun 2020 06:32:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-56.consmr.mail.bf2.yahoo.com (sonic304-56.consmr.mail.bf2.yahoo.com [74.6.128.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49mwGJ5dK9z4Mff for ; Wed, 17 Jun 2020 06:32:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YEeUmNQVM1n7Q605l99FRDT90BOm9_PyD8CrKRA3WlXeh0GpyJMj3DfyEY0q36P YIT8zEo1hkVYnTEbAEngF4W0Ww_0laOP7PTy8Uh4AEsssuqaIV5WNwmnaqbrokSMRIs2GxckSmmX tRaZ0ayygrfrqPcWBHbReLpCCxMnhkUFXxLIscpmsN0LtZDyRj5iY2UQ0HdtNgYTzcDgu_lRXqr3 0XHOu2Z1Q_IohZx.cW6_7_IaMZwje2JzKALjwEmwuf_fdU7F_01ni4fivHNXhKGR3bJXx2qQVX.7 atpoqw1ed9vv9YPl3Z9SWYYSVU78DzPrdnI3eG3dT8FXZhdTBdaBylDHHobgo8nbvOqlgkNgUZPc JezENTgkO6KYyQ3R6Iy11Pwd6RDISK_B2LRQ.fkf0WuWgr6jnsY2EpoeybQiZkT7s5HEY13_x_oL ww7TlUimq_Sb5ANEOgVESS9x3D_ihOGKR0pq042_.nK6Nn1iNR_j4rAo7oI7UpSWksgm8Eb2sDuz qPDhDKwk_Hqg_9R2N7oddQKkAK7c.WeX1yFSdNcC9fpUSS9RZLJjCEB9kqE8BDlmzrwul.6qjMvr Rp8TzZMcu1CCK.jDJp8kj_QkWu6P74ZKUXrzjNeVVaUXcd0QYrNO9el_rIxNHSO4ezyn_mUBYHed 2_3w4mH7cnYfuwmTQQXCkSl.rnsqO8yHP1QbA59XKECTVtm3V89l3ZJOTgyrreI95cGlW0eviqrW _AonZuShKh8msTw0q7tP4gQw7jFQJVvISVQcXJIU3ACT0k.A0jrIhzqo0T3z4f2ItwhR4B0NjZGl bW4udMKqavoNZoKTLQWFBIFRtl4nx11Pu.i0PGba6_jNJ4RVo4ZD9MCYsDiEBuG44y9pIl3b.D2c _XVU87jurS5Syk3Pli.wwDTbmAkdIikNeqMRuf4J7thXkuxZsCqXD1AeM5sY28Z1opi6CWP3QIHX mXGmlu5kdQ1yhS8uAjM_wosySCANPtWD5FTqcDO3m3cZMBC9jfXDcC53qwRu3U1InptZfiur4O1K NmGvGRpvlGrHzM5tChwX4D2TlF5Pf9863a_h3soOhC7Grztn16lPlKxfM4eim8BMaAL0XvAzJ3Tg mizCG5VMyZP4Jq4TQsibH5uCqrIXX10lLFnNMv4GJ4_P0M5zazp7ERI9.V2JTdUUlaqPiVK8YMJe .Xqg5DnqSMvtVYAYdMBErIuM7JCvwVv6AEo0fsRntuJvNIln9ubib7kBZnA8yclKZgX4leWbS9Ws 81LDsninOYVpoYuxCImoPc7li0TlzgBcsPBTEN6cY7TfIpw1VtNTlkIgEGFR74XDqgLaJqOBYRE. 8XcfCb8vpizpX.kva6VLAgZYaJZ0n_7penKUl.bCa2IWxTedBr9NXeQiYXGH2h4at409FmbiRlOI GGD2WGr7v1j6wp.L0GGOMWoD7_ZmYoaSJJAVStIzWlyESX8nxAzBkxp4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Jun 2020 06:32:07 +0000 Received: by smtp415.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9b0ece1a8f9c2f9ba5eb44f9cabbfefa; Wed, 17 Jun 2020 06:32:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Which u-boot for rpi3? u-boot-rpi3-32 or the old one? From: Mark Millard In-Reply-To: <20200617052152.GB70470@www.zefox.net> Date: Tue, 16 Jun 2020 23:32:03 -0700 Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200617043442.GA70470@www.zefox.net> <20200617052152.GB70470@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49mwGJ5dK9z4Mff X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.67 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.33)[-1.332]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.846]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.99)[-0.991]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.6.128.31:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.128.31:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 06:32:09 -0000 On 2020-Jun-16, at 22:21, bob prohaska wrote: > On Tue, Jun 16, 2020 at 09:59:24PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2020-Jun-16, at 21:34, bob prohaska wrote: >>=20 >>> Just noticed there are now two u-boot ports for the RPi3, one >>> called u-boot-rpi3-32 and (the presumably original) u-boot-rpi3. >>>=20 >>> The descriptions are equally bland, what's the difference? >>> The goal is to boot a recent snapshot of -current from USB >>> using a Pi3b (no +). Now it's suffering from cpu_reset failed. >>=20 >> Looking, the check in history for sysutils/u-boot-rpi3-32 >=20 > Could you write a few words about how one checks such history? > There doesn't seem to be anything in /usr/ports/UPDATING. Getting there directly: https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi3-32/?view=3Dlog In steps via exploring: https://svnweb.freebsd.org then click on ports/ to get to: https://svnweb.freebsd.org/ports/ then click on head/ to get to: https://svnweb.freebsd.org/ports/head/ then click on sysutils/ to get to: = https://svnweb.freebsd.org/ports/head/sysutils/ then select Page 2 in the Page popup so that the various u-boot* would be in range This gets one to: = https://svnweb.freebsd.org/ports/head/sysutils/?dir_pagestart=3D1000 (currently) then click on the number to the right of u-boot-rpi3-32/ (536829 = currently) This gets one to: = https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi3-32/?view=3Dlog For the example in use here there is only one log entry currently. >> reports for the creation of sysutils/u-boot-rpi3-32 : >>=20 >> Revision 536829 - Directory Listing=20 >> Added Fri May 29 01:27:16 2020 UTC (2 weeks, 5 days ago) by brd >> Add sysutils/u-boot-rpi3-32 to build a 32-bit version of u-boot >>=20 >> This is useful for using the camera hardware, as >> misc/raspberrypi-userland does not support aarch64. >>=20 >> Approved by: imp, manu >> Differential Revision:=09 >> https://reviews.freebsd.org/D21603 >>=20 >>=20 >> So: >>=20 >> A) sysutils/u-boot-rpi3 is for use with aarch64 FreeBSD >> B) sysutils/u-boot-rpi3-32 is for use with armv7 FreeBSD >>=20 >>=20 >=20 > Mine is case A, but Case B is a little puzzling; will armv7=20 > run on a Pi3 ? I thought arm64 was mandatory. Sure, even Raspberry Pi OS still does not even have an official 64-bit release for any armv7 or later based Raspberry Pi that I'm aware of: all armv7 for official releases for such RPi*'s. (There are earlier stage 64-bit materials these days for the aarch64 capable RPi*'s, at least for the kernel. But no 64-bit/aarch64 userland that I'm aware of: just armv7.) I'm unclear on if there are contexts for which both sysutils/u-boot-rpi2/ and sysutils/u-boot-rpi3-32/ are possibilities for use with armv7 FreeBSD. sysutils/u-boot-rpi2/ does have a log entry indicating that it was tested on both a RPi2 V1.1 and a v1.2, but it is not explicit about which FreeBSD variant(s) were involved for either. If there are contexts where both u-boot's are possibilities, then I do not know why one would pick one over the other. May be sysutils/u-boot-rpi2/ can not handle an RPi3 despite handling a RPi2 V1.2? FYI: even under aarch64 FreeBSD, one can install an armv7 world in its own directory tree and chroot to it and run armv7 software (world material, ports, etc., not kernel). And poudriere can use such to do armv7 port builds on CortexA53/A57/A72 and many more without qemu being involved (or even installed). (There are oddities like Cortex-A32 that is ARMv8.0-A but 32-bit only and Cortex-A34 that is ARMv8.0-A but 64-bit only. Qualcomm also has an ARMv8.1-A that is AArch64 only, not 32-bit. There may be more such oddities.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jun 17 11:45:02 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C542734C0A7 for ; Wed, 17 Jun 2020 11:45:02 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49n3CK5p7Kz3RZc for ; Wed, 17 Jun 2020 11:45:01 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 17 Jun 2020 11:44:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1592394298; bh=OLZmjHhQFwl/wDu1mGAryDEPZhztjenYfv01a26hXeo=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=YJNVS0eEQL13qCduHlKULjPe3iFq2Q6D0ZrztJQ7qphw8Xv1jflxfIee7RjQoo6Gp EAe2HE1+blGLNucAa5RX1VadpOGvTX4OJ+h6lHcgXVi70/nQ4TM4fTUErasNIExMRo spK7WraWUEr6r+UrnlzYfUWUzEtxENH5AKXj+z+c= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49n3CK5p7Kz3RZc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=YJNVS0eE; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.134 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.20 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.99)[-0.990]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.134:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.15)[-0.155]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.134:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 11:45:02 -0000 > > > AHCI is looking better and better! > > > I'm going to do a little bit of poking at that > > > SATA HDD just to see how stable it really is. > > > > Well, it's definitely stable enough for lab use, that's a bonus. I caus= ed myself a few headaches by doing stupid things that caused a series of pa= nics, but all are easily attributed to human errata... > > Oddly the i2c bus is gone - any ideas what we changed that caused it to= disappear? > > https://gist.github.com/agrajag9/03d9f2f52084ef0ae1e64cbba190e062 > > If I'm reading the DSDT correctly, then it should be hanging right off = acpi0. We can even see it in an older dmesg.boot: > > i2c0: iomem 0x2000000-0x= 200ffff irq 7 on acpi0 > > But now, nothing... > > Probably because I deleted that i2c acpi attachment at some point, becaus= e it didn't seem to actually work. Yes, that would make sense... > > Aside - since the builtin netifs are basically useless for us, any sugg= estions on USB wifi dongles? I tried a few from my parts piles, but all of = them were unstable Realtek trash. I know Atheros chips are usually a good b= et in Linux land - does that hold true in FreeBSD as well? > > Not sure how common Atheros is on USB.. I guess we're going to find out! https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-l= inux-tpe-n150usb > Ralink is fine I think? Actually Realtek wifi shouldn't be unusable too.. While the realtek device I have does move packets, it also likes to emit wa= rnings every few minutes, and it was definitely caused problems during boot= a few times as well. > For USB Ethernet though, I recommend the "Nintendo Switch compatible" ASI= X chips (axge). Hah! I would not have expected that, but I may pick one up as well for the = future - sadly no eth in my office at the moment. > By the way, did you get any different firmware builds in the meantime? Th= at don't have everything suspiciously routed to the SMMU in IORT.. No, not yet. I think he may be a one-man-army over there for a lot of SR's = firmwares and progress has been slow - especially because they're focused s= o much on supporting Linux. Also, is there some good intro documentation for SMMU and IORT? I'm still p= retty new to both Arm and ACPI, and while the spec docs on uefi.org have be= en great reference material, they're a bit challenging to just sit down and= read. From owner-freebsd-arm@freebsd.org Wed Jun 17 16:48:59 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A242A3537E4 for ; Wed, 17 Jun 2020 16:48:59 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49n9y24gKYz43Wx for ; Wed, 17 Jun 2020 16:48:58 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 17 Jun 2020 16:48:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1592412536; bh=sKtr7R+KBSbFqDYUpWWR8P7pVBiBM0exvy+6SKALjKk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Rq3pq57y3S9+W+oo3JDCM1tmWU8G6MWk8D0/BlSyk5uTLKWuodMSiLOmFWNAiFzhR 0ab60mtJCdx8mjf7FpPlgTVZGTuUdyBOU0zyg0My0ZV6KlLvnvkA5MNdbcg/bia+Ps NY88XxAVLKmAHd3Q8EVlyQVYZVTqOFRfhI+2HQAE= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49n9y24gKYz43Wx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=Rq3pq57y; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.22 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.90 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.98)[-0.981]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.22:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.83)[-0.828]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.22:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 16:48:59 -0000 > By the way, did you get any different firmware builds in the meantime? Th= at don't have everything suspiciously routed to the SMMU in IORT.. s/suspiciously/by design/ BEGIN QUOTE the PCIe root nodes are hidden from the rich OS with this configuration. = To access the root nodes you need a quirk implemented. eventually it will be an option for those that want to run custom kernels, = but for now this is the solution for the most SBSA like configuration END QUOTE From owner-freebsd-arm@freebsd.org Wed Jun 17 17:38:49 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C42AF354DAE for ; Wed, 17 Jun 2020 17:38:49 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49nC3X38cDz46w7 for ; Wed, 17 Jun 2020 17:38:47 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Wed, 17 Jun 2020 17:38:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1592415525; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0d9kTbyKUm4f/6NfVc3Rf+hzj54efwlFQBYP0T6aArk=; b=dsM5nd6IRX4PerGs8g82GA9J+3RWwKbzfJIilUtva3EIjMhoyo44ujiYl/RxMSDzHjCjlM 626V5e3yRaeEr2VNEK6ozIaZ+AARJpi3KgHthKZnvs8KUr78NLMgDS7CJC9mw0xFDTplv4 bVqM3mRljivgFdyXkSt+fnIcXaCa9H0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Dan Kotowski CC: freebsd-arm Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X In-Reply-To: References: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49nC3X38cDz46w7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=dsM5nd6I; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.60 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-0.97)[-0.970]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.64)[-0.636]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[91.121.223.63:from]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 17:38:49 -0000 On June 17, 2020 4:48:49 PM UTC, Dan Kotowski wrote: >> By the way, did you get any different firmware builds in the meantime? = That don't have everything suspiciously routed to the SMMU in IORT=2E=2E > >s/suspiciously/by design/ > >BEGIN QUOTE >the PCIe root nodes are hidden from the rich OS with this configuration= =2E To access the root nodes you need a quirk implemented=2E > >eventually it will be an option for those that want to run custom kernels= , but for now this is the solution for the most SBSA like configuration >END QUOTE And how are we supposed to get any MSI-X interrupts in this configuration? Our fallback code for when nothing was matched in IORT (i=2Ee=2E directly = using PCIe RID with no offset) did not result in working interrupts=2E IIRC legacy interrupts didn't work either, but maybe you should retest the= m (disabling MSI, MSI-X)=2E From owner-freebsd-arm@freebsd.org Wed Jun 17 20:32:43 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9E497334FE6 for ; Wed, 17 Jun 2020 20:32:43 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49nGwB5N7rz4Sld for ; Wed, 17 Jun 2020 20:32:42 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Wed, 17 Jun 2020 20:32:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1592425959; bh=u3tN50Myf1fRz5G3u2ybDOHqYaoARoewurpNWFXjgeE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Em71Awr/2HAFWKzenurl4bIT5sR54g4UM5s6s2C9nlt7qF3WQ51g4uqm66v6kJPg0 wekTiCvTTUBGVYT45ogbDTq8uqgcXrsFOSVGnDdc9/8UM5mBcLqZnVJsvWxWjWIctN 8ryqxLQtZ57QUDSLnvhWPHr2hKgbLwfWJY7vFKBE= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: References: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49nGwB5N7rz4Sld X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=Em71Awr/; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.133 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.80 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-0.97)[-0.967]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.73)[-0.735]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.133:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.133:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 20:32:43 -0000 > > > By the way, did you get any different firmware builds in the meantime= ? That don't have everything suspiciously routed to the SMMU in IORT.. > > > > s/suspiciously/by design/ > > BEGIN QUOTE > > the PCIe root nodes are hidden from the rich OS with this configuration= . To access the root nodes you need a quirk implemented. > > eventually it will be an option for those that want to run custom kerne= ls, but for now this is the solution for the most SBSA like configuration > > END QUOTE > > And how are we supposed to get any MSI-X interrupts in this configuration= ? > > Our fallback code for when nothing was matched in IORT (i.e. directly usi= ng PCIe RID with no offset) did not result in working interrupts. > > IIRC legacy interrupts didn't work either, but maybe you should retest th= em (disabling MSI, MSI-X). NSTR, but here you go anyways: https://gist.github.com/agrajag9/d4d75d7dca4= 1b3cb64c0a4243eed4eb7 Forgive my n00bishness and feel free to correct me below, I'm still learnin= g my way around down here... What are we doing with all the GSIVs in the IO= RT SMMU node? Based on reading the table and dmesg.boot, I'm seeing the following: * ITS node for gics * 2 root complex nodes for pci0 and 1, * Named component nodes for MCE, ugens, mmcs (if we still had that in), and= ahcis But then the SMMU node has: * 64 context interrupts, * 10 PMU interrupts, and * 5 ID mappings Where do these go? Are we perhaps not walking this section properly and tha= t's the quirk to which Jon is referring? From owner-freebsd-arm@freebsd.org Thu Jun 18 01:12:54 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E787E33CDD5 for ; Thu, 18 Jun 2020 01:12:54 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49nP7V0Krlz3YqM for ; Thu, 18 Jun 2020 01:12:53 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Thu, 18 Jun 2020 01:12:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1592442766; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uucSA8+zx96KHBHoSHR1YxMcUebXRa7asKJGbV8fR1Q=; b=EPhQm7EcuGMDhZgMOD0icY4u6Tn6AviwjGbcDJJmTXBxPfcPp2le/OHrvPPxrsOBhU5ojY qTdgIIvZ0w1rhNq151plXKrqHgENzTPG7fm9p1pPBSbalcu0LaBvtrlaNeyK2T3S5nkliP X9nLPdUoIE7s/36LgDe1CVT955C9tx0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: Dan Kotowski CC: freebsd-arm Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X In-Reply-To: References: <940a6099e971e01bd6d04564d0982b9d@unrelenting.technology> Message-ID: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49nP7V0Krlz3YqM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=EPhQm7Ec; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 94.23.1.103 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.54 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.07)[-1.072]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.23.1.103]; NEURAL_HAM_LONG(-0.97)[-0.970]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-0.49)[-0.494]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[94.23.1.103:from]; ASN(0.00)[asn:16276, ipnet:94.23.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 01:12:55 -0000 On June 17, 2020 8:32:36 PM UTC, Dan Kotowski wrote: >> > > By the way, did you get any different firmware builds in the meanti= me? That don't have everything suspiciously routed to the SMMU in IORT=2E= =2E >> > >> > s/suspiciously/by design/ >> > BEGIN QUOTE >> > the PCIe root nodes are hidden from the rich OS with this configurati= on=2E To access the root nodes you need a quirk implemented=2E >> > eventually it will be an option for those that want to run custom ker= nels, but for now this is the solution for the most SBSA like configuration >> > END QUOTE >> >> And how are we supposed to get any MSI-X interrupts in this configurati= on? >> >> Our fallback code for when nothing was matched in IORT (i=2Ee=2E direct= ly using PCIe RID with no offset) did not result in working interrupts=2E >> >> IIRC legacy interrupts didn't work either, but maybe you should retest = them (disabling MSI, MSI-X)=2E > >NSTR, but here you go anyways: https://gist=2Egithub=2Ecom/agrajag9/d4d75= d7dca41b3cb64c0a4243eed4eb7 > >Forgive my n00bishness and feel free to correct me below, I'm still learn= ing my way around down here=2E=2E=2E What are we doing with all the GSIVs i= n the IORT SMMU node? > >Based on reading the table and dmesg=2Eboot, I'm seeing the following: > >* ITS node for gics >* 2 root complex nodes for pci0 and 1, >* Named component nodes for MCE, ugens, mmcs (if we still had that in), a= nd ahcis > >But then the SMMU node has: > >* 64 context interrupts, >* 10 PMU interrupts, and >* 5 ID mappings > >Where do these go? Are we perhaps not walking this section properly and t= hat's the quirk to which Jon is referring? We do not support the SMMU at all=2E (There is a patch for SMMUv3 support = but this chip has a v1/v2=2E) SMMU support should not be mandatory, it's an IOMMU used for virtualizatio= n or additional DMA security protection (like dmar on Intel)=2E NetBSD does not support it either, and they don't seem to have any interru= pt problems=2E=2E In public code (lx2160a master), PCIe interrupts are routed to the ITS aft= er all=2E From owner-freebsd-arm@freebsd.org Thu Jun 18 03:53:05 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E628B34283D; Thu, 18 Jun 2020 03:53:05 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49nShK0lFfz42xy; Thu, 18 Jun 2020 03:53:04 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 05I3r2OU088703; Wed, 17 Jun 2020 20:53:02 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05I3r2W4088702; Wed, 17 Jun 2020 20:53:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006180353.05I3r2W4088702@gndrsh.dnsmgr.net> Subject: Re: nbdkit on FreeBSD In-Reply-To: To: alan somers Date: Wed, 17 Jun 2020 20:53:02 -0700 (PDT) CC: "freebsd-virtualization@freebsd.org" , freebsd-arm X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49nShK0lFfz42xy X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [2.31 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.30)[0.296]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.68)[0.679]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(0.43)[0.433]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 03:53:06 -0000 > Does anybody use nbdkit on FreeBSD? It's a fancy NBD (Network Block > Device) server. It runs fine on FreeBSD, but there's no port. If anybody > is interested, I'll make a port for it. However, if I'm the only one then > I won't bother. > > https://github.com/libguestfs/nbdkit/ I am not sure if this is what I looked at, but I was looking for a way to do old style sun "nd", and this looks to be 1/2 of that, in that I see a server, but no client for the kernel. I would be interested in NBD if we have both ends. > -Alan -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Jun 18 04:06:33 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6BF2B342D9B for ; Thu, 18 Jun 2020 04:06:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49nSzr2cjfz43xS for ; Thu, 18 Jun 2020 04:06:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x842.google.com with SMTP id w90so3430946qtd.8 for ; Wed, 17 Jun 2020 21:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tlUmWdqbwSmmBWzFOOnQo2wOVfMIj1bSPyeLymwuzx0=; b=NRAqm5Ots5ZhWsLbTiV6lkrnpDpRB60e/en+UqxwbuzevXoJYwmb74VzwWa8GqSD1R souE7haqnaLSSMS80Dd/adhRhyF94Wj991P9nXVN8qHh46kMMJGdWwm71JxfekZVX2Bj ouasZ/3urCLefGSWAmwEQ4F6LgTUbyNjoq2hvIdBBR5tfrPiUd1VkLf3UZP/DWNjXEcy 9HEVpPy9ZcovRGBg9q+HRn9oFvsjYzg1cgIKihr9M/JfXh3mtkwX497+ngKyCCKA4OuF MXjqwieSO5lISXFiv3qKIs3UU0fREF3GYHPusGecghJr2WKTS5AyqzfWu8hsnwd/4JE4 1Eew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tlUmWdqbwSmmBWzFOOnQo2wOVfMIj1bSPyeLymwuzx0=; b=mAfsiFonGyTwaPbD+/G3r5w4eUSU04zBkw2fqHvTB5l7BoAe4h/V0Ym4sptvObCuDW s9k97brvLbHF8TYKejtsk2rzFR+v+b4xWmLstwANv7qPy8Nc0c9ymV/6qpCEKw5EbdOM 0PETp+bA2/xfPqhgChK/P/I3Q2ONNID6gyvzIMr1KKjEuqmD7NlunQZQcvtyobBqPUNs NPPGjKeRwXx8mMsS/Cw0UqwkNbZv9sbPPM6ToICQxezQeSgsSt/UmlsdmSnttPyKIaT3 S3wxGj4nfW7gLdCDv0OrpCwh6lwqb75uOq8jM4s9v0mCPaiy1R8zqi0pQXNAxR2MGgn8 pG/w== X-Gm-Message-State: AOAM533CVwFsgcZAzSXZBs0zuiKRugVEKOX/H7DUUOuvOuShxJruJgl7 8CZ3zHIrbjJUREZhlIAxGYxpErtw3KGSWU2IPX02Sw== X-Google-Smtp-Source: ABdhPJyBXO3OWiZgrp68UiUV/ymKfFQqgxyEaKv9zSouYxb9buXCDqXZlfShjvdtkm3yJz1suichfEGEpW2kh2U9MVU= X-Received: by 2002:ac8:34e8:: with SMTP id x37mr196004qtb.291.1592453191556; Wed, 17 Jun 2020 21:06:31 -0700 (PDT) MIME-Version: 1.0 References: <202006180353.05I3r2W4088702@gndrsh.dnsmgr.net> In-Reply-To: <202006180353.05I3r2W4088702@gndrsh.dnsmgr.net> From: Warner Losh Date: Wed, 17 Jun 2020 22:06:20 -0600 Message-ID: Subject: Re: nbdkit on FreeBSD To: "Rodney W. Grimes" Cc: alan somers , "freebsd-virtualization@freebsd.org" , freebsd-arm X-Rspamd-Queue-Id: 49nSzr2cjfz43xS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=NRAqm5Ot; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::842) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.65 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.67)[-0.670]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.00)[0.003]; NEURAL_HAM_LONG(-0.98)[-0.981]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::842:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 04:06:33 -0000 On Wed, Jun 17, 2020 at 9:53 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > Does anybody use nbdkit on FreeBSD? It's a fancy NBD (Network Block > > Device) server. It runs fine on FreeBSD, but there's no port. If > anybody > > is interested, I'll make a port for it. However, if I'm the only one > then > > I won't bother. > > > > https://github.com/libguestfs/nbdkit/ > > I am not sure if this is what I looked at, but I was looking > for a way to do old style sun "nd", and this looks to be 1/2 > of that, in that I see a server, but no client for the kernel. > > I would be interested in NBD if we have both ends. > There's lots of 'other ends' including qemu for this. This is really cool! Warner From owner-freebsd-arm@freebsd.org Thu Jun 18 08:06:33 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3D45D348612; Thu, 18 Jun 2020 08:06:33 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49nZJm3SVWz4H8v; Thu, 18 Jun 2020 08:06:32 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-yb1-f178.google.com with SMTP id b15so2652257ybg.12; Thu, 18 Jun 2020 01:06:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2WaBbLMY+1LAlYT9rz3OtPgEhVVipGSGrWdcu8APj/g=; b=X2b15TZd9Q6Es9njesabsNTxj71WlO67QlHxfl7nEXnc0/fYQJ3lKfCwN3t/qM3zv7 T+dUbSs4ZrHmcU7JI8geoevBIxabxgT2ij5/zCnJXW4IVY5HE1l+Mpn3PYdUqR/ZPk49 Pu9xivowffp6t6wGHRAvp2oR1/gH9yiqu7azZxqXw4TqJ7xiFthfEaHiB/HUhyffo06x YcaviGKA6mi2nAR36au+a7oOU2RjhKDO89nE5Ty1z1UJMpA0xhtlOgTdrqvIACqNG7DZ cc1AbZ+B1oyIog03+voBnmlE0+jKN/+oKOgCMBMykoUlkJmAADJAn1K/8RJ6HBeAliNE Urpg== X-Gm-Message-State: AOAM530pHedq0hXRDAqyIF2rT8ZNos02B4fNK0d04+CHJbFZh00KFAJZ sHs8hD9ny1dTTA8WB2Ythy/4sz67vd6eXpiSHJ4= X-Google-Smtp-Source: ABdhPJxZmNy4Onbr3/GRxfig+8qnWX8C+m78lWTRLpFbTbqdBDXsQIpnu67VSReWDlSSGLYZnol/BkcPUngUHQiPvj4= X-Received: by 2002:a25:d088:: with SMTP id h130mr4740042ybg.451.1592467591159; Thu, 18 Jun 2020 01:06:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Li-Wen Hsu Date: Thu, 18 Jun 2020 16:06:20 +0800 Message-ID: Subject: Re: nbdkit on FreeBSD To: alan somers Cc: "freebsd-virtualization@freebsd.org" , freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49nZJm3SVWz4H8v X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-0.89 / 15.00]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.88)[-0.883]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.49)[-0.493]; NEURAL_SPAM_SHORT(0.48)[0.483]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.178:from]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.178:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 08:06:33 -0000 On Thu, Jun 18, 2020 at 5:03 AM alan somers wrote: > > Does anybody use nbdkit on FreeBSD? It's a fancy NBD (Network Block > Device) server. It runs fine on FreeBSD, but there's no port. If anybody > is interested, I'll make a port for it. However, if I'm the only one then > I won't bother. > > https://github.com/libguestfs/nbdkit/ I would say just make a port if making it isn't that painful. Having a port might also attract more users, and it cloud save your upgrading time in the future. It would be nice to also let upstream know there is demand of using it on FreeBSD. Li-Wen From owner-freebsd-arm@freebsd.org Thu Jun 18 20:28:02 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 22954332E7E; Thu, 18 Jun 2020 20:28:02 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49ntmK1XHbz428v; Thu, 18 Jun 2020 20:28:00 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 05IKRwbK092015; Thu, 18 Jun 2020 13:27:58 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05IKRwah092014; Thu, 18 Jun 2020 13:27:58 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006182027.05IKRwah092014@gndrsh.dnsmgr.net> Subject: Re: nbdkit on FreeBSD In-Reply-To: To: Warner Losh Date: Thu, 18 Jun 2020 13:27:58 -0700 (PDT) CC: "Rodney W. Grimes" , alan somers , "freebsd-virtualization@freebsd.org" , freebsd-arm X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49ntmK1XHbz428v X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.39 / 15.00]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.14)[0.137]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.02)[-0.024]; NEURAL_SPAM_LONG(0.37)[0.372]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_CC(0.00)[gndrsh.dnsmgr.net,gmail.com,freebsd.org] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 20:28:02 -0000 > On Wed, Jun 17, 2020 at 9:53 PM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > Does anybody use nbdkit on FreeBSD? It's a fancy NBD (Network Block > > > Device) server. It runs fine on FreeBSD, but there's no port. If > > anybody > > > is interested, I'll make a port for it. However, if I'm the only one > > then > > > I won't bother. > > > > > > https://github.com/libguestfs/nbdkit/ > > > > I am not sure if this is what I looked at, but I was looking > > for a way to do old style sun "nd", and this looks to be 1/2 > > of that, in that I see a server, but no client for the kernel. > > > > I would be interested in NBD if we have both ends. > > > > There's lots of 'other ends' including qemu for this. I specifically meant native FreeBSD kernel. > This is really cool! > > Warner -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Jun 19 13:48:40 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C799D34C4A7 for ; Fri, 19 Jun 2020 13:48:40 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49pKs36l4Hz471X for ; Fri, 19 Jun 2020 13:48:39 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-ej1-x643.google.com with SMTP id l27so10306653ejc.1 for ; Fri, 19 Jun 2020 06:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oKcdVFTiixF/44jwMh9XuhB8NIfobOt0OnEYabHS77A=; b=hw3X7pBqzr70vNIGCrHl4yvE4OlRi0mXZ7tYlU8dSJYckqZh15LScWGqorgBGQ/FKQ MZpLhZK3b5DkMYAn8CK0Z+uSRewtqwAya7uj2iPCNrb7uMvTBKfSpVDPGoXppt4HKI+0 Tf2mW2PUQlg0byFX/Y9lJN6wVr+whG2p+Xv/Gu5tqUXNnLkqbIHqyaPKku48aBS9ijpK eSc7o12t5o7lD9xT+DfPO21Jgdo+26gFMIT4BGefoMGQmm69sKO/jxIw5wGjFijKDoXP JYIt3ZfBtv3lP4EJ2eX6vyr0t4C96SoCsZOuuj6Mwj03honSnzvpboE6kdNQJD7wat8J CDiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oKcdVFTiixF/44jwMh9XuhB8NIfobOt0OnEYabHS77A=; b=Rxs8MKFj6UWEiqV774YVGy9SzuhPuNFavwTmycXIbmmfHFWriMeZ89kEKpcGgxfn5/ xQS1D0Hm1YoOrw7GKMF9lf6I7lvoXOyECwlKlc4pYEXda14P7hNfP87go2uL4fdBCTKT kQnk2GO55loXAsWbH+S/PeeO3dRKeMcv70ea4RsYJ7mo205bqQBL2YdM5JgunzIjrxKO i3OCSHo9skltYo3PFrTLSYnfJI8OwZmkA558gBfsSI4ODW2sVdZ45VzLJgvA0Lxbcrox 5UQs3C2bwDUDwoLaKnDfw+ft4+38UYfM4Ls2DycF+fEXytMH3lv38zk4OSyKkpDwS1n5 TLWA== X-Gm-Message-State: AOAM5336dAh19olluzhJ8PnNkt04DPXvUnr5QRD8qxkA7BiaSRelFSuz Z9kc900DZEOkSA8lEhH5CI1dZ2yT X-Google-Smtp-Source: ABdhPJwhmhrAKN8WYmQIcIAwhezLLcQ5+sHcMdSIcD6kYNRW/nUpGK71AYo7RF0/4gDmcBD3zIseWQ== X-Received: by 2002:a17:906:7103:: with SMTP id x3mr3514211ejj.363.1592574518367; Fri, 19 Jun 2020 06:48:38 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id sa19sm4904762ejb.15.2020.06.19.06.48.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 06:48:37 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: <7B4746AD-A8B7-43F0-B5EC-F3812A91F344@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Rock64 dwc interface issues Date: Fri, 19 Jun 2020 15:48:36 +0200 In-Reply-To: <877d6e2d-6cd8-30f3-08c3-60a2bacb5873@scd-systems.net> Cc: freebsd-arm@freebsd.org To: charlesr@scd-systems.net References: <877d6e2d-6cd8-30f3-08c3-60a2bacb5873@scd-systems.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49pKs36l4Hz471X X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=hw3X7pBq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::643 as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [-2.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.72)[-0.716]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.71)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.01)[-1.010]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::643:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 13:48:40 -0000 You might not be alone :) I got my shiny new rockpro64 (yeah a little = different) and it probes the dwc device just fine (todays -current) dwc0: mem 0xfe300000-0xfe30ffff = irq 9 on ofwbus0 miibus0: on dwc0 rgephy0: PHY 0 on = miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 6 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on = miibus0 rgephy1: OUI 0x00e04c, model 0x0011, rev. 6 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto dwc0: bpf attached dwc0: Ethernet address: X:X:X:X:X:X It does not work however, no error msgs or anything, but no traffic = enter or leaves at all. I had a similar issue with the dwc compat chip on the Allwinner R40 = (Bananapi M2 Berry) and got that working, so I=E2=80=99ll se if similar = hacks works here=E2=80=A6 -S=C3=B8ren > On 22 May 2020, at 11.12, Charles wrote: >=20 > Hi, >=20 >=20 > I am currently trying to setup my Rock64 V2.0 SoC with FreeBSD (Image: = http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm64/aarch64/ISO-IMAGES/13.0= /FreeBSD-13.0-CURRENT-arm64-aarch64-ROCK64-20200514-r361019.img.xz) >=20 > The spi from the rock64 board is not flashed and the sd-card is = booting successful FreeBSD. >=20 > But the dwc0 network interface makes trouble. >=20 > At first I tried to reach the soc by ssh without success, the = connection ends into a timeout. Next i tried to reach the board by icmp = requests from other machines and i only got approx. every 3-4 packets = answered back from the rock. > The arp table from the rock64 machine is fine, same on the other side. >=20 > icmp outout: >=20 > # ping 192.168.178.79 > PING 192.168.178.79 (192.168.178.79): 56 data bytes > 64 bytes from 192.168.178.79: icmp_seq=3D3 ttl=3D64 time=3D0.422 ms > 64 bytes from 192.168.178.79: icmp_seq=3D7 ttl=3D64 time=3D0.295 ms > 64 bytes from 192.168.178.79: icmp_seq=3D8 ttl=3D64 time=3D0.284 ms > 64 bytes from 192.168.178.79: icmp_seq=3D11 ttl=3D64 time=3D0.289 ms > 64 bytes from 192.168.178.79: icmp_seq=3D12 ttl=3D64 time=3D0.282 ms >=20 > tcpdump dump from the rock: >=20 > # tcpdump -i dwc0 -n icmp > tcpdump: verbose output suppressed, use -v or -vv for full protocol = decode > listening on dwc0, link-type EN10MB (Ethernet), capture size 262144 = bytes > 01:24:30.275479 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 0, length 64 > 01:24:31.286399 IP truncated-ip - 16384 bytes missing! 192.168.178.21 = > 192.168.242.79: ICMP echo request, id 20996, seq 4097, length 16448 > 01:24:33.400434 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 3, length 64 > 01:24:33.400533 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, = id 20996, seq 3, length 64 > 01:24:34.460477 IP truncated-ip - 16384 bytes missing! 192.168.242.21 = > 192.168.178.79: ICMP echo request, id 20996, seq 4, length 16448 > 01:24:35.512486 IP 192.168.178.21 > 192.168.186.79: ICMP echo request, = id 20996, seq 5, length 64 > 01:24:36.572512 IP truncated-ip - 16384 bytes missing! 192.168.178.21 = > 192.168.178.79: ICMP echo request, id 20996, seq 6, length 16448 > 01:24:37.632534 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 7, length 64 > 01:24:37.632631 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, = id 20996, seq 7, length 64 > 01:24:38.688549 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 8, length 64 > 01:24:38.688640 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, = id 20996, seq 8, length 64 > 01:24:39.709363 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 9, length 64 > 01:24:40.711011 IP truncated-ip - 16384 bytes missing! 192.168.178.21 = > 192.168.178.79: ICMP echo request, id 20996, seq 10, length 16448 > 01:24:41.712351 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 11, length 64 > 01:24:41.712449 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, = id 20996, seq 11, length 64 > 01:24:42.775589 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 12, length 64 > 01:24:42.775677 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, = id 20996, seq 12, length 64 >=20 >=20 > Output ifconfig: >=20 > dwc0: flags=3D8843 metric 0 = mtu 1500 > options=3D80008 > ether 3a:6f:36:64:e6:9c > inet 192.168.178.79 netmask 0xffffff00 broadcast = 192.168.178.255 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=3D29 >=20 > dmesg: >=20 > ---<>--- > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2020 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #0 r361019: Thu May 14 09:26:15 UTC 2020 > = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 > FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-10.0.0-0-gd32170dbd5b) > WARNING: WITNESS option enabled, expect reduced performance. > VT: init without driver. > module firmware already present! > KLD file umodem.ko is missing dependencies > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > MAP fbf1b000 mode 2 pages 1 > MAP fbf24000 mode 2 pages 1 > MAP fbf27000 mode 2 pages 1 > MAP fef30000 mode 2 pages 16 > WARNING: Device "kbd" is Giant locked and may bware Device Tree> > simplebus0: on ofwbus0 > clk_fixed0: on ofwbus0 > rk_grf0: mem 0xff100000-0xff100fff = on ofwbus0 > rk3328_cru0: mem = 0xff440000-0xff440fff on ofwbus0 > rk3328_cru0: cannot get parent at idx 6 > Cannot set frequency for clk: aclk_bus_pre, error: 34 > rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000 > Cannot set frequency for clk: aclk_peri_pre, error: 34 > rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000 > clk_fixed1: on ofwbus0 > regfix0: on ofwbus0 > regfix1: on ofwbus0 > regfix2: on ofwbus0 > regfix3: on ofwbus0 > simple_mfd0: mem = 0xff450000-0xff45ffff on ofwbus0 > psci0: on ofwbus0 > gic0: mem = 0xff811000-0xff811fff,0xff812000-0xff813fff,0xff8140s 160 > rk_pinctrl0: on ofwbus0 > gpio0: mem 0xff210000-0xff2100ff irq = 52 on rk_pinctrl0 > gpiobus0: on gpio0 > gpio1: mem 0xff220000-0xff2200ff irq = 53 on rk_pinctrl0 > gpiobus1: on gpio1 > gpio2: mem 0xff230000-0xff2300ff irq = 54 on rk_pinctrl0 > gpiobus2: on gpio2 > gpio3: mem 0xff240000-0xff2400ff irq = 55 on rk_pinctrl0 > gpiobus3: on gpio3 > rk_i2c0: mem 0xff160000-0xff160fff irq 16 on ofwbus0 > iicbus0: on rk_i2c0 > rk805_pmu0: at addr 0x30 irq 56 on iicbus0 > generic_timer0: irq 4,5,6,7 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rk_tsadc0: mem 0xff250000-0xff2500ff = irq 22 on ofwbus0 > cpuliseq_dt1: on cpu1 > cpu2: on cpulist0 > cpufreq_dt2: on cpu2 > cpu3: on cpulist0 > cpufreq_dt3: on cpu3 > uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on = ofwbus0 > uart0: console (-1,n,8,1) > iic0: on iicbus0 > rockchip_dwmmc0: mem 0xff500000-0xff503fff irq 41 on ofwbus0 > rockchip_dwmmc0: Hardware version ID is 270a > mmc0: on rockchip_dwmmc0 > rockchip_dwmmc1: mem 0xff520000-0xff523fff irq 43 on ofwbus0 > rockchip_dwmmc1: Hardware version ID is 270a > mmc1: on rockchip_dwmmc1 > dwc0: mem 0xff540000-0xff54ffff = irq 44 on ofwbus0 > miibus0: on dwc0 > rgephy0: PHY 0 on = miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseT0baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto > dwc0: Ethernet address: 3a:6f:36:64:e6:9c > dwcotg0: mem = 0xff580000-0xff5bffff irq 46 on ofwbus0 > usbus0 on dwcotg0 > ehci0: mem 0xff5c0000-0xff5cffff irq 47 on = ofwbus0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > ohci0: mem 0xff5d0000-0xff5dffff irq 48 on = ofwbus0 > usbus2 on ohci0 > gpioc0: on gpio0 > gpioc1: on gpio1 > gpioc2: on gpio2 > gpioc3: on gpio3 > gpioled0: on ofwbus0 > gpioled0: failed to map pin > gpioled0: failed to map pin > cryptosoft0: > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 12Mbps Full Speed USB v1.0 > Obsolete code will be removed soon: random(9) is the obsolete = Park-Miller LCG from 1988 > ugen1.1: at usbus1 > uhub0 on usbus1 > uhub0: on usbus0 > ugen2.1: at usbus2 > uhub2 on usbus2 > uhub2: on = usbus2 > mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/2048-block > mmc1: No compatible cards found on bus > Release APs...done > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> > Instruction Set Attributes 0 =3D > Instruction Set Attributes 1 =3D <> > Processor Features 0 =3D > Processor Features 1 =3D <> > Memory Model Features 0 =3D > Memory Model Features 1 =3D <8bit VMID> > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3,Debugv8> > Debug FeatureCortex-A53 r0p4 affinity: 3 > WARNING: WITNESS option enabled, expect reduced performance. > Warning: no time-of-day clock registered, system time will not be set = accurately > uhub2: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > uhub0: 1 port with 1 removable, self powered > lo0: link state changed to UP > dwc0: link state changed to DOWN > dwc0: link state changed to UP >=20 >=20 > Does anyone know this issue ? >=20 >=20 > Best, >=20 > Charles > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Jun 19 15:17:53 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 59C0834F78C for ; Fri, 19 Jun 2020 15:17:53 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49pMr03kKSz4HNk for ; Fri, 19 Jun 2020 15:17:52 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Fri, 19 Jun 2020 15:17:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1592579869; bh=3kK9t3+R4xU6bsnYqxNDMTTcz1ELEpq8LmBV/IeK0Ew=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Z6IPfc6Xj3IjnVXvukgzlbON4VzhqebXnvIx49i6yKOTCsOOjETtjE0nJiJrbksuW ODEc6R5RVdmOmIcyBkVGLQeVhBefXR2VI4I7hvamrsPsZAg12wKQvm3c2TmFHDx89d V4tRjgoKfEOJE+FDIGHnwv8TplJUd58e4ey4YA48= To: myfreeweb From: Dan Kotowski Cc: freebsd-arm Reply-To: Dan Kotowski Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X Message-ID: In-Reply-To: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> References: <71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 49pMr03kKSz4HNk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=Z6IPfc6X; dmarc=pass (policy=none) header.from=a9development.com; spf=pass (mx1.freebsd.org: domain of dan.kotowski@a9development.com designates 185.70.40.133 as permitted sender) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.66 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-1.04)[-1.043]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-0.52)[-0.521]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.133:from]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[185.70.40.133:from] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 15:17:53 -0000 > > > > > By the way, did you get any different firmware builds in the mean= time? That don't have everything suspiciously routed to the SMMU in IORT.. > > > > > > > > s/suspiciously/by design/ > > > > BEGIN QUOTE > > > > the PCIe root nodes are hidden from the rich OS with this configura= tion. To access the root nodes you need a quirk implemented. > > > > eventually it will be an option for those that want to run custom k= ernels, but for now this is the solution for the most SBSA like configurati= on > > > > END QUOTE > > > > > > And how are we supposed to get any MSI-X interrupts in this configura= tion? > > > Our fallback code for when nothing was matched in IORT (i.e. directly= using PCIe RID with no offset) did not result in working interrupts. > > > IIRC legacy interrupts didn't work either, but maybe you should retes= t them (disabling MSI, MSI-X). > > > > NSTR, but here you go anyways: https://gist.github.com/agrajag9/d4d75d7= dca41b3cb64c0a4243eed4eb7 > > Forgive my n00bishness and feel free to correct me below, I'm still lea= rning my way around down here... What are we doing with all the GSIVs in th= e IORT SMMU node? > > Based on reading the table and dmesg.boot, I'm seeing the following: > > > > - ITS node for gics > > - 2 root complex nodes for pci0 and 1, > > - Named component nodes for MCE, ugens, mmcs (if we still had that in= ), and ahcis > > > > But then the SMMU node has: > > > > - 64 context interrupts, > > - 10 PMU interrupts, and > > - 5 ID mappings > > > > Where do these go? Are we perhaps not walking this section properly and= that's the quirk to which Jon is referring? > > We do not support the SMMU at all. (There is a patch for SMMUv3 support b= ut this chip has a v1/v2.) > > SMMU support should not be mandatory, it's an IOMMU used for virtualizati= on or additional DMA security protection (like dmar on Intel). > > NetBSD does not support it either, and they don't seem to have any interr= upt problems.. > > In public code (lx2160a master), PCIe interrupts are routed to the ITS af= ter all. But NetBSD did not have those interrupt problems on the older firmware, whe= re the ECAM workaround was done via PCI quirks. I fetched a generic evbarm = img to test with the current firmware and it looks like NetBSD may now be i= n the same boat as us. https://gist.github.com/agrajag9/daa072b23dbb4cdb9dae899a5b2d01f5 Jon says there's a new build with published sources coming soon, supposedly= with better ECAM support (current is "proof of concept"). Hopefully that h= elps some, but if the problem is actually that everything is behind the SMM= U and we just don't support that at all, then... From owner-freebsd-arm@freebsd.org Fri Jun 19 15:54:59 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD99F330C39 for ; Fri, 19 Jun 2020 15:54:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49pNfp6CJ8z4LNl for ; Fri, 19 Jun 2020 15:54:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IRmsXCIVM1ngr_nAiZtowPRyckO8.7YVb8ldHj4oH5p8JhAZxn0ySpV_KwINrr9 rgODVrU7vVhKvYauTkFjw9LoRokLkW9x3MNfyyBwMwCsWkEtMU.gEd5deyH_TwHQeHSTDL.lC8Aw D378h1SV.NZ3VjR0CnW.mIds_TPrU6oOGzP55Vx2JeCGHKLGWUfm.HuLTHqj7jBaiDARcJTIUAGn lQkkrYooAumPgN8M5595F.s.RBCsNb0jYeoGihmd1..slGTQAbGpYBW3JWDKwI8Ost3nIA252YnZ r6mMGzo4vf1_OeEO3H77sZ._W.J9LJHK3HEvVY6y4st.K1Pfcsc7q_wDhdLlcIF4UE99nHYY0W5f f05Y_DHM.jvZchvHz5dz4dwT0dsgas8WPY9yPxqFsmCJ05QaLjMQNfBy9zQr5htQOO9z.Hwr8PdK FQJ8zkXom5KyRB6Jiz4LpOShXonZkShu8MNxgIDXj3LOpgAjNButeSIBvZHPRpJlMfjXiQxK6lWI YHZgPS0wQUJqc.Hkn59sSJkac6YhqRsvHjxVFR0OyinhGS.NB5vt0g.qwhDXt1OoH9AIPJeJ9UO. Vqe1L91LrSt_4sD.bXCbI25OGXxG.5ye7U4W.pYuIsNyMiu_FXPz1FVtmrCvix0nOqHBNnUVEg3g yt.hSzCKFtqH1590u3ePuSS8r7hIhLL885NutW2aCUrMozjt_B7q41MDCDMsGih9OVvMn9LhjH1r TRRnqqCDOOFOv_IkfHhjax4SduPfzwXI39LY6N5oUifK5So2hpdOc68XK_zQPxYCsBVpPKD.dp0O UIyHAyJT0TfoTshbdUeTTse2x8Ip1IKhgPKfy9bxusRstpKDRqsLu_SXHaENJ0PrMv86tUsKfdHp MB1o6hjswlM3FDh45nYKeJMYyb7SKm.s3L.bQsmCO1RzWnJkxfjI6pAV_0aFbKGcgAUXYEC39V.c 2U4fLP_OVlXYM.u46ts4lSa7f5bGDGZ0x7XkSxUSYNnhyugBKSzL.pelJaUvUa5KOJgsGFFQ2Zq8 9ykGbiJ2ssDP1CQilEnsQksg.JKXprg934_DGe9YAnX8dzTvwhCC0_Wjoia0XRH5xcnGowLKiQid 3b1LuQH1i8DDhZGFJpzZzEFtAIEUN4JLvax8TttZxJbdGF4Fw_RYPLdPH1W1f_V6km99MTvQF64e nxULC21EXbfgHVhP7UmMJywjAs0AIpg2g_rMIhuMNLonESQCcXXdwDxx0ZWq7D.NaR0Lo19wJNbm 5Q__5y3O4FIc_QRWlwT3Hy8ndArmJClGhc408GVwKZeuGXBqWywcEyrGC0bNLOF32lgG4XpjY5qF qkPLaJzAYXnnKIrDXfOXGD2W2.SWhAi1o7bniCL2X8Ojx_uyMJPTl09Ayfx3tE591HxJvvpPzRm7 0mYH0iCqkezSNFhM44DdUcWuPCodDfTf3ZerEaNFApeYHZA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Jun 2020 15:54:56 +0000 Received: by smtp411.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0c16615686433f79daa8a14e07aa3201; Fri, 19 Jun 2020 15:54:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: 4 GiByte RPi4 -j4 buildworld buildkernel when booted via https://github.com/pftf/RPi4/releases/tag/v1.16 materials: somewhat under 13 hours Message-Id: <22283E0A-29A9-40EE-895C-9641F9EA4E1D@yahoo.com> Date: Fri, 19 Jun 2020 08:54:52 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <22283E0A-29A9-40EE-895C-9641F9EA4E1D.ref@yahoo.com> X-Rspamd-Queue-Id: 49pNfp6CJ8z4LNl X-Spamd-Bar: - X-Spamd-Result: default: False [-1.52 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; URL_IN_SUBJECT(1.00)[github.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.028]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.00)[0.002]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.204:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.204:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 15:54:59 -0000 This was using over_voltage=3D6 and arm_freq=3D2000 via config.txt . The environment is (mostly) based on head -r360311 . EFI/BOOT/BOOTAA64.EFI ( loader.efi ) was more recent. A USB3 Ethernet is in use because the built-in Ethernet does not show up in FreeBSD. ( /dev/mmcsd0 does not show up either. ) The RPi4 has heatsinks and a fan and was using a 5.1V 3.5A power supply. I deleted the prior contents of the build tree first. . . . make[1]: "/usr/src/Makefile.inc1" line 323: SYSTEM_COMPILER: Determined = that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 328: SYSTEM_LINKER: Determined = that LD=3Dld matches the source tree. Not bootstrapping a cross-linker. . . . >>> World built in 43050 seconds, ncpu: 4, make -j4 . . . >>> Kernel(s) GENERIC-NODBG built in 2768 seconds, ncpu: 4, make -j4 So a little under 12 hours for buildworld and somewhat under 50 minutes for buildkernel. So, somewhat under 13 hours overall when not needing to build a bootstrap compiler or linker. But my selections of what/how to build are somewhat unusual. For reference: # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host=20 TO_TYPE=3Daarch64 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #Disables avoiding bootstrap: WITHOUT_LLVM_TARGET_ALL=3D WITH_LLVM_TARGET_AARCH64=3D WITH_LLVM_TARGET_ARM=3D WITHOUT_LLVM_TARGET_MIPS=3D WITHOUT_LLVM_TARGET_POWERPC=3D WITHOUT_LLVM_TARGET_RISCV=3D WITHOUT_LLVM_TARGET_X86=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITHOUT_BINUTILS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # # NO_WERROR=3D MALLOC_PRODUCTION=3D # # Avoid stripping but do not control host -g status as well: DEBUG_FLAGS+=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a53 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a53 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a53 ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto I currently use the same media with a Rock64 and currently choose to tune for that CortexA53 context instead of for CortexA72. (Both are -march=3Darmv8-a and so are compatible.) For reference, my odd variation of top reported: 2104Mi MaxObsActive 661004Ki MaxObsWired 2628Mi MaxObs(Act+Wir) "Obs" is short for "Observed". =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jun 19 17:42:32 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2642633436D for ; Fri, 19 Jun 2020 17:42:32 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49pR2t4g2vz4YHN for ; Fri, 19 Jun 2020 17:42:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1592588542; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X6Slijf4jmarYVnoqWuakbiJlUWN1H+1vsiQ8clNfRM=; b=RLO/CImZ5sVzO1jFprwwnRW+y9fTr0BeCBrW38YeP1BUjKbfIdxu72LCzKlnBVAnPP62+A Q9/skoEbzvBhRn2zeDvoSFQtF78L16moZDqFXX2w+j4vM/Yfocn9k2v3IZWzb0ZzYy6Eyk 1RKPe2CfL5TQDNgM5ZblHKvjxpZAGXg= Received: from skull.home.blih.net (lfbn-idf2-1-900-181.w86-238.abo.wanadoo.fr [86.238.131.181]) by mx.blih.net (OpenSMTPD) with ESMTPSA id d84a6993 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 19 Jun 2020 17:42:22 +0000 (UTC) Date: Fri, 19 Jun 2020 19:42:22 +0200 From: Emmanuel Vadot To: =?ISO-8859-1?Q?S=F8ren?= Schmidt Cc: charlesr@scd-systems.net, freebsd-arm@freebsd.org Subject: Re: Rock64 dwc interface issues Message-Id: <20200619194222.73bc7dd705f6d80e63757796@bidouilliste.com> In-Reply-To: <7B4746AD-A8B7-43F0-B5EC-F3812A91F344@gmail.com> References: <877d6e2d-6cd8-30f3-08c3-60a2bacb5873@scd-systems.net> <7B4746AD-A8B7-43F0-B5EC-F3812A91F344@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49pR2t4g2vz4YHN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=RLO/CImZ; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.010]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.86)[-0.863]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 17:42:32 -0000 Hello S=F8ren, Charles, On Fri, 19 Jun 2020 15:48:36 +0200 S=F8ren Schmidt wrote: > You might not be alone :) I got my shiny new rockpro64 (yeah a little dif= ferent) and it probes the dwc device just fine (todays -current) >=20 > dwc0: mem 0xfe300000-0xfe30ffff ir= q 9 on ofwbus0 > miibus0: on dwc0 > rgephy0: PHY 0 on miibus0 > rgephy0: OUI 0x00e04c, model 0x0011, rev. 6 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT= -FDX, 1000baseT-FDX-master, auto > rgephy1: PHY 1 on miibus0 > rgephy1: OUI 0x00e04c, model 0x0011, rev. 6 > rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT= -FDX, 1000baseT-FDX-master, auto > dwc0: bpf attached > dwc0: Ethernet address: X:X:X:X:X:X >=20 > It does not work however, no error msgs or anything, but no traffic enter= or leaves at all. >=20 > I had a similar issue with the dwc compat chip on the Allwinner R40 (Bana= napi M2 Berry) and got that working, so I?ll se if similar hacks works here? >=20 > -S=F8ren >=20 > > On 22 May 2020, at 11.12, Charles wrote: > >=20 > > Hi, > >=20 > >=20 > > I am currently trying to setup my Rock64 V2.0 SoC with FreeBSD (Image: = http://ftp.freebsd.org/pub/FreeBSD/snapshots/arm64/aarch64/ISO-IMAGES/13.0/= FreeBSD-13.0-CURRENT-arm64-aarch64-ROCK64-20200514-r361019.img.xz) > >=20 > > The spi from the rock64 board is not flashed and the sd-card is booting= successful FreeBSD. > >=20 > > But the dwc0 network interface makes trouble. > >=20 > > At first I tried to reach the soc by ssh without success, the connectio= n ends into a timeout. Next i tried to reach the board by icmp requests fro= m other machines and i only got approx. every 3-4 packets answered back fro= m the rock. > > The arp table from the rock64 machine is fine, same on the other side. > >=20 > > icmp outout: > >=20 > > # ping 192.168.178.79 > > PING 192.168.178.79 (192.168.178.79): 56 data bytes > > 64 bytes from 192.168.178.79: icmp_seq=3D3 ttl=3D64 time=3D0.422 ms > > 64 bytes from 192.168.178.79: icmp_seq=3D7 ttl=3D64 time=3D0.295 ms > > 64 bytes from 192.168.178.79: icmp_seq=3D8 ttl=3D64 time=3D0.284 ms > > 64 bytes from 192.168.178.79: icmp_seq=3D11 ttl=3D64 time=3D0.289 ms > > 64 bytes from 192.168.178.79: icmp_seq=3D12 ttl=3D64 time=3D0.282 ms > >=20 > > tcpdump dump from the rock: > >=20 > > # tcpdump -i dwc0 -n icmp > > tcpdump: verbose output suppressed, use -v or -vv for full protocol dec= ode > > listening on dwc0, link-type EN10MB (Ethernet), capture size 262144 byt= es > > 01:24:30.275479 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 0, length 64 > > 01:24:31.286399 IP truncated-ip - 16384 bytes missing! 192.168.178.21 >= 192.168.242.79: ICMP echo request, id 20996, seq 4097, length 16448 > > 01:24:33.400434 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 3, length 64 > > 01:24:33.400533 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, id= 20996, seq 3, length 64 > > 01:24:34.460477 IP truncated-ip - 16384 bytes missing! 192.168.242.21 >= 192.168.178.79: ICMP echo request, id 20996, seq 4, length 16448 > > 01:24:35.512486 IP 192.168.178.21 > 192.168.186.79: ICMP echo request, = id 20996, seq 5, length 64 > > 01:24:36.572512 IP truncated-ip - 16384 bytes missing! 192.168.178.21 >= 192.168.178.79: ICMP echo request, id 20996, seq 6, length 16448 > > 01:24:37.632534 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 7, length 64 > > 01:24:37.632631 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, id= 20996, seq 7, length 64 > > 01:24:38.688549 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 8, length 64 > > 01:24:38.688640 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, id= 20996, seq 8, length 64 > > 01:24:39.709363 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 9, length 64 > > 01:24:40.711011 IP truncated-ip - 16384 bytes missing! 192.168.178.21 >= 192.168.178.79: ICMP echo request, id 20996, seq 10, length 16448 > > 01:24:41.712351 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 11, length 64 > > 01:24:41.712449 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, id= 20996, seq 11, length 64 > > 01:24:42.775589 IP 192.168.178.21 > 192.168.178.79: ICMP echo request, = id 20996, seq 12, length 64 > > 01:24:42.775677 IP 192.168.178.79 > 192.168.178.21: ICMP echo reply, id= 20996, seq 12, length 64 > >=20 > >=20 > > Output ifconfig: > >=20 > > dwc0: flags=3D8843 metric 0 mtu= 1500 > > options=3D80008 > > ether 3a:6f:36:64:e6:9c > > inet 192.168.178.79 netmask 0xffffff00 broadcast 192.168.178.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > nd6 options=3D29 > >=20 > > dmesg: > >=20 > > ---<>--- > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2020 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 13.0-CURRENT #0 r361019: Thu May 14 09:26:15 UTC 2020 > > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC= arm64 > > FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvm= org-10.0.0-0-gd32170dbd5b) > > WARNING: WITNESS option enabled, expect reduced performance. > > VT: init without driver. > > module firmware already present! > > KLD file umodem.ko is missing dependencies > > Starting CPU 1 (1) > > Starting CPU 2 (2) > > Starting CPU 3 (3) > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > random: unblocking device. > > random: entropy device external interface > > MAP fbf1b000 mode 2 pages 1 > > MAP fbf24000 mode 2 pages 1 > > MAP fbf27000 mode 2 pages 1 > > MAP fef30000 mode 2 pages 16 > > WARNING: Device "kbd" is Giant locked and may bware Device Tree> > > simplebus0: on ofwbus0 > > clk_fixed0: on ofwbus0 > > rk_grf0: mem 0xff100000-0xff100fff on= ofwbus0 > > rk3328_cru0: mem 0xff440000-0xff= 440fff on ofwbus0 > > rk3328_cru0: cannot get parent at idx 6 > > Cannot set frequency for clk: aclk_bus_pre, error: 34 > > rk3328_cru0: Failed to set aclk_bus_pre to a frequency of 15000000 > > Cannot set frequency for clk: aclk_peri_pre, error: 34 > > rk3328_cru0: Failed to set aclk_peri_pre to a frequency of 15000000 > > clk_fixed1: on ofwbus0 > > regfix0: on ofwbus0 > > regfix1: on ofwbus0 > > regfix2: on ofwbus0 > > regfix3: on ofwbus0 > > simple_mfd0: mem 0xff450000-0xff4= 5ffff on ofwbus0 > > psci0: on ofwbus0 > > gic0: mem 0xff811000-0xff811fff,0xff= 812000-0xff813fff,0xff8140s 160 > > rk_pinctrl0: on ofwbus0 > > gpio0: mem 0xff210000-0xff2100ff irq 52= on rk_pinctrl0 > > gpiobus0: on gpio0 > > gpio1: mem 0xff220000-0xff2200ff irq 53= on rk_pinctrl0 > > gpiobus1: on gpio1 > > gpio2: mem 0xff230000-0xff2300ff irq 54= on rk_pinctrl0 > > gpiobus2: on gpio2 > > gpio3: mem 0xff240000-0xff2400ff irq 55= on rk_pinctrl0 > > gpiobus3: on gpio3 > > rk_i2c0: mem 0xff160000-0xff160fff irq 16 on ofwbus0 > > iicbus0: on rk_i2c0 > > rk805_pmu0: at addr 0x30 irq 56 on iicbus0 > > generic_timer0: irq 4,5,6,7 on ofwbus0 > > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 > > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > > rk_tsadc0: mem 0xff250000-0xff2500ff irq= 22 on ofwbus0 > > cpuliseq_dt1: on cpu1 > > cpu2: on cpulist0 > > cpufreq_dt2: on cpu2 > > cpu3: on cpulist0 > > cpufreq_dt3: on cpu3 > > uart0: <16750 or compatible> mem 0xff130000-0xff1300ff irq 14 on ofwbus0 > > uart0: console (-1,n,8,1) > > iic0: on iicbus0 > > rockchip_dwmmc0: mem 0xff500000-0xff503fff irq 41 on ofwbus0 > > rockchip_dwmmc0: Hardware version ID is 270a > > mmc0: on rockchip_dwmmc0 > > rockchip_dwmmc1: mem 0xff520000-0xff523fff irq 43 on ofwbus0 > > rockchip_dwmmc1: Hardware version ID is 270a > > mmc1: on rockchip_dwmmc1 > > dwc0: mem 0xff540000-0xff54ffff = irq 44 on ofwbus0 > > miibus0: on dwc0 > > rgephy0: PHY 0 on miib= us0 > > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseT0baseTX-FDX, 1= 000baseT-FDX, 1000baseT-FDX-master, auto > > dwc0: Ethernet address: 3a:6f:36:64:e6:9c > > dwcotg0: mem 0xff580000-0xff5bf= fff irq 46 on ofwbus0 > > usbus0 on dwcotg0 > > ehci0: mem 0xff5c0000-0xff5cffff irq 47 on of= wbus0 > > usbus1: EHCI version 1.0 > > usbus1 on ehci0 > > ohci0: mem 0xff5d0000-0xff5dffff irq 48 on of= wbus0 > > usbus2 on ohci0 > > gpioc0: on gpio0 > > gpioc1: on gpio1 > > gpioc2: on gpio2 > > gpioc3: on gpio3 > > gpioled0: on ofwbus0 > > gpioled0: failed to map pin > > gpioled0: failed to map pin > > cryptosoft0: > > Timecounters tick every 1.000 msec > > usbus0: 480Mbps High Speed USB v2.0 > > usbus1: 480Mbps High Speed USB v2.0 > > usbus2: 12Mbps Full Speed USB v1.0 > > Obsolete code will be removed soon: random(9) is the obsolete Park-Mill= er LCG from 1988 > > ugen1.1: at usbus1 > > uhub0 on usbus1 > > uhub0: on usbus0 > > ugen2.1: at usbus2 > > uhub2 on usbus2 > > uhub2: on usb= us2 > > mmcsd0: 32GB at mmc0 5= 0.0MHz/4bit/2048-block > > mmc1: No compatible cards found on bus > > Release APs...done > > CPU 0: ARM Cortex-A53 r0p4 affinity: 0 > > Cache Type =3D <64 byte D-cacheline,64 byte I-cacheli= ne,VIPT ICache,64 byte ERG,64 byte CWG> > > Instruction Set Attributes 0 =3D > > Instruction Set Attributes 1 =3D <> > > Processor Features 0 =3D > > Processor Features 1 =3D <> > > Memory Model Features 0 =3D > > Memory Model Features 1 =3D <8bit VMID> > > Memory Model Features 2 =3D <32bit CCIDX,48bit VA> > > Trying to mount root from ufs:/dev/ufs/rootfs [rw]... > > Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 Breakpoin= ts,PMUv3,Debugv8> > > Debug FeatureCortex-A53 r0p4 affinity: 3 > > WARNING: WITNESS option enabled, expect reduced performance. > > Warning: no time-of-day clock registered, system time will not be set a= ccurately > > uhub2: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > uhub0: 1 port with 1 removable, self powered > > lo0: link state changed to UP > > dwc0: link state changed to DOWN > > dwc0: link state changed to UP > >=20 > >=20 > > Does anyone know this issue ? > >=20 > >=20 > > Best, > >=20 > > Charles > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I've just took the last image for rock64 and rockpro64 to test on my boards (I usually netboot but testing the image give a common reference between everyone). As a reference the image I've burned on the sd are : FreeBSD-13.0-CURRENT-arm64-aarch64-ROCK64-20200618-r362292.img.xz FreeBSD-13.0-CURRENT-arm64-aarch64-ROCKPRO64-20200618-r362292.img.xz On Rock64 v2.0 (2017-0713) I see no issues, I got an IP from my dhcp server and could install packages properly. Using iperf3 I have ~275Mbits/sec which isn't great but we're aware of the bad perf of the dwc(4) driver. On RockPro64 v2.1 I also see no issues, iperf3 give the same speed result for tx but rx is worse (~100Mbits/sec). S=F8ren, what are your hack for R40 (which do not have support for in term of clock so I'm not surprise that you need "something" for it).=20 Charles, could you test the same image as me and see if that makes a difference (but I doubt since not much changed recently that could affect that). Cheers, --=20 Emmanuel Vadot