From owner-freebsd-arm@freebsd.org Mon Jul 6 17:00: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 C73EB36C1CB for ; Mon, 6 Jul 2020 17:00:33 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (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 4B0sJc3GDJz4HkL for ; Mon, 6 Jul 2020 17:00:32 +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=1594054823; 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=HCsonnW2BUTt47pHkKkdduzi+J1nZhPGS4ne2j5LZnQ=; b=CCrXweoWK7w4NFKfnEvdTwkfeYfeO4FTn2BDs0PqTPN6K/ZAbK3Uk3jOovbqYISU/DQukw dRldUgeE5BugIvjXdek8cqLLxQ9CzTsu03KdhufQbYXx01VM6PaKC8cFJkKUejV+ZAnMLk bRzgRwEpOUC/uSYfemXmdoMO71S+aLk= Date: Mon, 06 Jul 2020 17:00:22 +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: Subject: Re: FreeBSD on Layerscape/QorIQ LX2160X To: "Dan Kotowski" Cc: "freebsd-arm" In-Reply-To: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> References: <82UUBttUqS5j5wotn5ibAhp3w3JveSof3dsBLqW68NkaOu1xc6txd62UJeyJgV6hk9mLNYqhAJDyEej_PPtiv_ps9vROdUI529pKfxp4lbs=@a9development.com> _____<71481BF5-3972-45A3-8287-FCEB1FCCDC41@unrelenting.technology> <8a3f78ddd5136ef22c59e9f7b1b23ca6@unrelenting.technology> X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 4B0sJc3GDJz4HkL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=CCrXweoW; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-3.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:267::]; NEURAL_HAM_LONG(-1.01)[-1.012]; 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]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.28)[-0.279]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; 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, 06 Jul 2020 17:00:33 -0000 July 6, 2020 7:07 PM, "Dan Kotowski" wro= te:=0A=0A>> In the old firmware, under the Root Complex Nodes, `Output re= ference: 0x30` points to the ITS Node=0A>> with node offset 0x30.=0A>> Th= en in the new firmware, under the Root Copmlex Nodes, `Output reference: = 0x48` points to the SMMU=0A>> with node offset 0x48.=0A>> Is this what yo= u meant when you said everything is "behind the SMMU"?=0A>> =0A>> Yes.=0A= >> =0A>> What patches are we applying right now? I think some new builds = would be good, including one with=0A>> all the stuff we've fixed - like A= HCI - but with the NXP PCIe code so I can test on the old=0A>> firmware. = If I'm keeping track correctly, this includes:=0A>> =0A>> - D20835: enabl= e tagged pointers=0A>> - D20974: Port sbsawdt drive from NetBSD=0A>> - D2= 1017: armv8crypto: add AES-XTS support=0A>> - D24423: arm/pmu: add ACPI a= ttachment, more FDT names=0A>> =0A>> These are not directly related to ru= nning on NXP, just random improvements :)=0A>> =0A>> - D25145: acpi_resou= rce: support multiple IRQs=0A>> - D25157: ahci_generic: add quirk for NXP= 0004=0A>> - D25179: acpi_iort: fix mapping end calculation=0A>> =0A>> Yes= , these three.=0A>> =0A>> Here's the pci_layerscape patch:=0A>> =0A>> htt= ps://github.com/DankBSD/base/commit/c1ea44aa33b29f74daed89eee82b3dfeb105d= 376.patch=0A>> =0A>> If we haven't tried it + acpi_iort fix before, which= is quite likely, maybe that's a combination=0A>> that would work.=0A>> (= I remember when we tried it only, there was only the same interrupt probl= em as usual..)=0A>> =0A>> It's honestly kinda weird that "old" FW require= s the custom controller access while "new" FW=0A>> requires not doing it = >_<=0A> =0A> Any tips on where to add verbosity to dmesg during boot? You= had a handful of extras in there to=0A> print things things from the IOR= T.=0A=0AThat thing is here:=0Ahttps://github.com/freebsd/freebsd/blob/6ce= e1596c05e8a9ab64812444627b61c584ca6bc/sys/arm64/acpica/acpi_iort.c#L169= =0A=0A> Also seeing that NVMe hangs in nvme_ctrlr_start_config_hook,=0A> = maybe we want to add some verbosity to sys/dev/nvme/nvme_ctrlr.c to see w= hat it's waiting for?=0A=0A=0AWe know it's an interrupt.. everything is w= aiting for an interrupt.