From owner-freebsd-arm@freebsd.org Mon May 18 19:44: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 057012DB87E for ; Mon, 18 May 2020 19:44:43 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) (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 49QqGd5dBdz4FfZ for ; Mon, 18 May 2020 19:44:41 +0000 (UTC) (envelope-from greg@unrelenting.technology) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1589831073; 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=lzLqm7zaO0wxOoAGiJTT3pt2L/AbfLcIQKHz6pdbF4c=; b=SQg2oKE5JcL6oPvgS/Pdc8pYrY3ImeAUMJTc397PYTd+LIIMQJPov9D7oW/OqXuRsZSVqZ CeoypXLwk3JSfsvIYco6+dWcKBHir9YUkHHPC4mwD3YNepEIX7DUkHjTiYO3wNjRBB73CY Vvleegiab3dJOd7nPbeQJWUzQ/a/dMM= Date: Mon, 18 May 2020 19:44:32 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: greg@unrelenting.technology Message-ID: <2053cd2299b81860deecc638ef839d1f@unrelenting.technology> Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "John-Mark Gurney" , freebsd-arm@freebsd.org In-Reply-To: References: <9UQiT9Df6hGA9k3-pzwpHifFsu7BVL2zFGOqDsnGva556e8nyvrKPp5XnKWxksvEKx1bpD-dnuYw8VCGiP9Z_kHc6tDFJcmRXzeJqLbo-yo=@a9development.com> <20200516051207.GT4213@funkthat.com> <3nsQUg1Gm4VFYfpHVELk6PWaHyYNb3CoyoKnLV55_3VR48tr90bhaseG3sJg007L8czZ4mXUmR_YMQvYVdMbUs1bsoqGtZp5d17FqYT6b-o=@a9development.com> <7AFDA7E0-82EC-4CD2-BB03-B7E33D019EDA@unrelenting.technology> <_lvahpuNQE69s4KpHud6ANL6yzL3RCVI-MTyB0_J_ULyW-3UWsqAXnm5gfoFcOyvfRQRabZk4Z4bQgyp15a001kA-WcvsvnWcjqgMBkgGTY=@a9development.com> <7F9D7164-2C04-4E27-85F9-A495EAC8FC84@unrelenting.technology> <63b4f78ff4ee07359a345bcbc03afeaa@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49QqGd5dBdz4FfZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=SQg2oKE5; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:863f:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-1.14 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:863f::]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.14)[-0.136]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, 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: Mon, 18 May 2020 19:44:43 -0000 May 18, 2020 10:22 PM, "Dan Kotowski" wr= ote:=0A=0A>> Same as in it still says "using DTB"?=0A>> =0A>> I wonder if= that's the same weirdness I saw on the RPi4,=0A>> FreeBSD failing acpi_f= ind_table(ACPI_SIG_SPCR) even though the SPCR table=0A>> is present and d= eciding we don't have ACPI..=0A>> =0A>> You could try my current kernel w= hich has has_acpi hardcoded to true=0A>> (extract into the root of the me= mstick's ufs partition):=0A>> =0A>> https://send.firefox.com/download/c3d= 69444ce92d3cf/#AuYrYtDvJWNYbEeJWRX4fA=0A> =0A> Yes, it does still say "us= ing DTB"=0A> =0A> Also, your kernel works! Or at least I'm into the insta= ller. It doesn't see the onboard eMMC in the=0A> Partition Editor, but on= ce I have the NVMe gumstick in hand I'll pick back this back up.=0A=0ACoo= l, please please please post a dmesg to https://dmesgd.nycbug.org :)=0A= =0ACreated a bug for the ACPI detection issue:=0Ahttps://bugs.freebsd.org= /bugzilla/show_bug.cgi?id=3D246552=0A=0A> Is there a reason that we can't= use on the DTBs compiled from SolidRun and NXP's sources?=0A=0AThe devic= etree uses NXP specific device descriptions (for USB, SATA, PCIe, all the= things)=0Aand FreeBSD doesn't understand them.=0A=0AACPI tables mostly u= se generic devices descriptions that all operating systems support=0Aout = of the box.=0A=0AIt is technically possible to make a DTB that mostly use= s generic nodes and ACPI tables=0Afull of custom vendor nodes, but almost= nobody does this.=0A(Okay, actually, Qualcomm does ACPI with almost all = vendor nodes on the Windows aarch64 laptops :D)=0A=0AGeneric descriptions= are good. ARM systems that work in the "boring" plug&play way (with stan= dardized=0Ageneric devices) are the ideal we all should strive for, so AC= PI should always be preferred.=0AIf you're using any DTB on a server/work= station-class system, something has gone wrong :)