From nobody Tue Jan 28 11:42:37 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yj3LQ3Fq5z5mWMT for ; Tue, 28 Jan 2025 11:42:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yj3LP6X7zz4Cl6 for ; Tue, 28 Jan 2025 11:42:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1738064557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RIEqjE8jZKCxQ4ArViBW1O6necz1ubaQL7RZ3n5UeOM=; b=jTOQzUY34ax33hnwRtbRnQDiFdsH8hQ4L6R2wHJebw0omxMH9COexQ0NvF2mSHTbSuLMRW PGl6KIdWar5XlK/cIWdYIpPacUb+sYp4edNqUarYXFAnlH1vj3hDsIdAbuaFP/EcwgSOeZ 9WuHoz2psAvT3xy/tKdeFfSy2e4eAsCzOExI6Ie9Mv1sKARtlyd24yoELQwPWvuUmi8Jh3 JvVlqgVVLGqPEafqchCKcoUWmJ6HKkbQckO3eFH4T7jBJErAfD7V32xuTKdvDDOjxZK0xm qcNsxHJllRIJJpXf7qW5tbTCo1ssY14h191BorGTCyzewIdSt2ywcp6QzgkRIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1738064557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RIEqjE8jZKCxQ4ArViBW1O6necz1ubaQL7RZ3n5UeOM=; b=Nz9MayrYmxvwzt4uvjS58HUuYwhQTa/ylSR3rFRAYadC8VdxVwmeeVkfwxDt7t72Bz5C+X 1Ls6NGolGicAyZ51UNZ6AWbZnb4srv8g6mOfDBLsNLK/dG11g3YkFsrUj6umOdxt3gVU3J eemAgYTVsYs46TNPJc1j8+QRntvqH4SiKlxrHNfHxDfUzLGpGqrmG9+5Le43/cnBh3mTNb VoavjulQc7nmN9ZkUz7rpwDhLLAB94O4c0NlSF1Yj1DWfXVdntfs5UhpyD8wav1dUAhdr/ V2kSCu/3sCLAWsjcR6gNIbUYM9eF9/bhHLcYbCa3PZ2WyPhUKKibEGv9+vNkpA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1738064557; a=rsa-sha256; cv=none; b=UCBiLyArrtidYc0nPA5TkTLsbsBEYhjwi6U583UMlogHKuVPqpvrg/C7yJtX8DUHC8Zh4l JKMsAMKseJSy8t0PFYMK3ZtNebSudkR9mGY61HdL1REvLmU756OrDlSbLFQ24fE6ilA6Ky REy3rvPuvY/NBM/AJ+ptHFgLjZTwaEOIA3KMBtWXX+xKtc5uR6SRqjitlle1rs435W9EAX qhcTn/QX+DQQXy44aKtQbMsBLffpdTkKPEiGTueze0+MT7+mplShQVzTMT7GwXiH9Fm7G+ +W/WO2+QKysrkgI3xS4Jo8qy1X5+07ZxYZiHcku5w2pQxcFk7/6lg2ltMhEosQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Yj3LP67lVz1CZT for ; Tue, 28 Jan 2025 11:42:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 50SBgb0h072945 for ; Tue, 28 Jan 2025 11:42:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 50SBgbs8072944 for freebsd-arm@FreeBSD.org; Tue, 28 Jan 2025 11:42:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217434] Raspberry Pi sound: locks when running make in any ports directory Date: Tue, 28 Jan 2025 11:42:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Feedback Timeout X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217434 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Feedback Timeout Status|Open |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jan 28 11:43:05 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yj3Lx6h37z5mWdl for ; Tue, 28 Jan 2025 11:43:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yj3Lx3HRdz4CxT for ; Tue, 28 Jan 2025 11:43:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1738064585; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=By7fdeq+tHiMIuLJalnxBeVUyAghDQ2KpqbjbDACaHU=; b=vv/pMRvxXyYxv/3WRDhNRKoSpdo5I452iuHqYj/Tk41mfuYd0xktGNdtuGqG1HYBioXI6c cC+e6DPnl+MLTlFtfR0TNsMbplS8bZe3o7ruV5888gFXYGJqlO+4rp+J12ouL1F3wRVV1B um1fYasymkw1TpRzp/5cQQfRuZhugLgjN3ozfR99ug8OeY0F8PdW/Hsz0o2Xjc4gTnwkTr Rd8WdRsCo8JZ/QBZ+G4ZNCEmvT76BHROat+H5Ulyx+Ga79Dgn7NC6fp6W86GvnQ7l0AsVY NTeLdNq1bowWmEekDDj/3X9o7MNOj/HOy7lj3ED1O6oeIy3WBrBbvD4h9/OFaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1738064585; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=By7fdeq+tHiMIuLJalnxBeVUyAghDQ2KpqbjbDACaHU=; b=WZSTCVFBaBXOy6ShnUaRJ+d4+xbwIFbZQqgwAGIU0w7VAPzBKP1iCKV/ggLnyopjyvw5W6 vSlNF6UGtutT28K6Q85WcYBISFi+YhUVUdiCgbP/YDyWT/0OQOjysNr+SQAkZKHXRhahTb cM7Qiw/5OPk3SpR/X2oTQ+prON+yFKat5gimTVRIptmwv0+ZeNVGhJ2CN9+lXqDtGdhd71 V86QxCZxjedg9KILKIOF70o97VrN1E2OXxQR1SE69P9bOGEbHznCa9tIRLNbDL+G3wJjIC N6Isvm2PWR8a+kQp2nJBq6MgPqRq6TtGlEs/UaC4eq1u/sz7fKgutW0HABWxIQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1738064585; a=rsa-sha256; cv=none; b=T1wA88cYn1yHKQQG1TaqMyp07a3gRnd3lPYMn8mGh/LEx3YHoHYGdADp9i9nIChskh1hFO 7FNj6oSjeZpZXHhLXQvyh+/C6SjM4pLcZNyG9uAsLHkKysxFhoticQzAVMI/4BovScwLpp 3J4dLXh4MaCW5r4BDnrnM6pIuawNOwrFwph5/+x71zyg2mGMocIzmpxLiaLugdNBHpXOqZ r96MET0mIFrSI4f76/It7Epo9zbhnRG13v2SV6HEcMLcPcBf6cVHmVxcRIFP0rNnc2SAhf BGlNp0l7NG+uvetm1XelvLnJckjYJZhzC7T0gcVkrgMdHZV07MBoIERi3B0Ofg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Yj3Lx2srbz1CFF for ; Tue, 28 Jan 2025 11:43:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 50SBh5bG073306 for ; Tue, 28 Jan 2025 11:43:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 50SBh5wq073305 for freebsd-arm@FreeBSD.org; Tue, 28 Jan 2025 11:43:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 239647] Segfault writing to mmap'd /dev/dsp0 (uaudio) in PulseAudio on aarch64 Date: Tue, 28 Jan 2025 11:43:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Feedback Timeout X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239647 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Feedback Timeout Status|Open |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jan 28 15:16:59 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yj8692BGpz5lbcp for ; Tue, 28 Jan 2025 15:17:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yj8674hzhz3gnK for ; Tue, 28 Jan 2025 15:17:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=e7vhZqxf; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1738077432; bh=CRn82xXYa4bvhizySOxb4ZJxIAZx/mYkIP70mDAuMUY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=e7vhZqxfrg+loZBPauzj2/X1e7KSWnhJ7q1GL3/SxeEmlTmjuPbZty0ppmJRJC26QH9FosX+uP7ugBZQHPVzui+7pupDDw1FtxpsUV/z6ykMPCBMJpGaRVCn6vCxg9OylX604O38i4isV2W0LWIJj/ARnC3yL23i61zOuHRNQ9honRMpizPiIaY94K7VHVuc9KuS1/xiRwizwZf7ypcXO6yCBEanCtKFsI+JC3rHbv/hTZ5qT4zp+jNx5+bKZHGFhCGvr71p6drwd3xNKwG8BDSjvpajQsowZfy5/kCOwWwz4wRFaat90acEsVbYNGXN6y/z6bmORABM6vNn2z4xoQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1738077432; bh=di8H/wsVjnOcRzQs6DEuenINjvUpf90yoqVnGJtw83L=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pY9ka3jvZtSsvGcd5m8uRSeqsjFLm+sfTl+9jC/65wzWUo1wTzTI3DcTv6QOTe2iQGa3xMO2Ir1FzwEklxpRiIrR+h/r2YA3e8ZG8UcmKDlOGUgleAjJskI62/d6Ecj5z2meh1JQxRlgNtBWuuBcHx35uQ73dErbAsBCMgxv7/UbD6JcmAKVGlJ8XsZ9gplShyxpuWPdVNVRL6oAResnx5mKvJisno3w0jA/sVXuhRDugMAbz8OzODPN+FkpiaHLZqRNhhf2nDNjW3jIOVgQQ88v9Oe4WdFyh4m8YlDUHyb+O3zTmDXhiR0ZwEKwYhOzeKt9Ky50BEoO+wcyKZXrsA== X-YMail-OSG: Jb2EYzsVM1lcmnXv7IVJMBmxwkgkpc4yaJXZBuSk77hQI2lH2DLKqbPEwRUgg1p tYouNAo7km8vrngybfZIf4Z79oveJTHlJDzw4O2w3OKKrn7CmQKJNQ_WEu7MHujsVUr_AzrZaHnN .j__mqcaXmAGXXm.Oe_yKJE97iA7.dqsH7T6JMI.6T5dHDucqBPcStJpTS5PHeiBa61Q5csElyYn ve7zmt1WCBk0a_fJQ2Z.wH0Tbywnego9qI2MxHzpLwlz_x3At_LsASCAmLhkfzaZ0O6kRXpoGm1s gvq8pVt9DOp0WCt2.XI_QslKuNuoWwdii1qedQt1oM3UsLMjXQ6b0S59b7vvCDzlKxv3aXq9LWVm dnYCRTd2zwDn_4UmV0Be8uLBmAbz3mRKK99AIguVFoCn3wKB3LiuberzShYTUF56AElNMWGJCuzu Js4dD1xr9zVFVZboV4VY.VPtkv3lUm2v8jQ6f6aEhgejqR6KZjKqp3wQSNErReXDl1ALo5PszSkn OgO77u6OnG6X2SxEhfkrWUSSyv1d1lbnrDyK7mfemXMSRAJ621C4XTB0R1PuCm6rj65GJbLdfT6_ n8M1jhWvGd8UBTvldeHlV24mfSvcaw4vQa76dLSrd0U0.xiA8yxJEzkybAQL8WFLKm8vz00NkrTE HtPpbfUkKG2xsUHmg_5ShLG_30ZrbfwMoO9YONYdUh0stg.W81LBe5hTNB5ekzl4PJqgIhubnIyC NAOxO3Gowo_6lhHh9x02AHDp6ObmPdvfkwkNol54Uo0GKsALRzCaGfXJyViucJrzvOrLmDzccvQA 9B98.lgM4ZfXKRdI.VJUuBml1RIhQPQSpqHG3dY.6HR0knTl0DNfaSWg4T0nGgd05dpJQ8WMfaRy Ul6p902ztjXLVBIyM6KwAzCg9Bs6xpKm4h8KMCTNTxB5tg6oOzLb2o7f0ekwneJs5DpjoF0twE6_ dMURCb8Vsc7IUB9Do.SjgiqzIs8rEjYS3Wlqgrh_d21F5hR3_dasx3hzvD7F_49QhEjzxO06q3tI cF2m_imY9zUo9wjr5tQNKQ3gSww9JRDF7DzferncCP9ythbMIS62PUgU1V6592TMngOkK4g5o6ql gRtPBpn9YP4HuB4rrh_aux_7H_4p9lhdp9GQVAuZmOTrXQ21rGRq_Nt.epDBOhuxUhVKbXKTgEzb GkN0osW0wgW0ovbZFgA8YhQ.NGkb81SLFBWx6AdrLZEsq_rMCdbqFwL4cGH0ozM6jy5Nvkf2n5Uj HRdngXCV41FYrF79WXxS6Xee449JyBWB1Zm2.t6GB.tkS9pKFdD2VrALwwQMYRK154k14fEm6alt UVhMHmWG0bGRkoomCubvN6kkSMxbFmHx7_Tv4tIGRAKs8x4ucin0RhowJr.L9R4OcOrk0XpMzBra CKwnmTF3ZsvJHJn25Ps7VFNuPJzLh4M05UItQcTNnKX.dXfRkgJSoyRzl6S6JfNnIW9OE6d0EjMd GiGd5zvV1m6TTcvfXiUVbdBbtwqrG6Kz6SlCu3zcZJXAeJSMelYvegPTRIwfwy1UleR1LBYW3PFQ rINcAWLQYBRJN.bu4h1ARkhs7ELuTX90AlkhKHPLb92dliLwLP7o9v.1qpjOSLQl.__gc09WN_UQ GKTQk.FK2ftKX53UWAqx33UoMhhQy6n.mr6S1IrDPtcV16cHhwAyxw7jeAnybaJR51dg4vFx4XyT hseHPgZmr08uM61aEzWiCcoRKkG_bWwVfs6M5xFwnCLOoP81xvew6CSG3KtKRtWE7ROocXkTxLm6 erVyLAxJkfzQHLIbRAW5o.Tz2lg8Uddi.C8OCftpMlX5V9VdvUoZWogaIDQSOTewSakbvWTg5yLJ 4gTCic49c.X8V9v5sJD3k2O4Z7rR9m5rkpZDFj6UGb5dpq_BN3W90N90x9juKANnhdocRCbZwyXG wcu6dVxF3MC4vk3v7KlU5JtmavWb2yXb06eOQhOG_l8bZG3IJDwDKbwL1LN85b7griT0PJS4QxPj Kq38ACEdum675cGMQFDHuvEvLrpK6IdA_1.fFXcePDq.66CKx_AoHo_LJZ3xMUqELrzfwVaosYxn YbwYL8BBcOJo1IY36VaxhWKMYUu0Df8b4midt.x2E9Vvt4tVbtYkgDsF3FLWzsgZSa2WfRA9y6M4 kH6CYuRmZK7mJIwkY4CPA4ccPjKk2ZRsjE0oTN9RWH3Vrgr_m3_4AuFAPoKriPFQZDPgbizw9oRd 9pqd67MWyJ.nPAFD0.4nv4PU0MIJsELl7Viha5MQY4QxsBuGXbJmYGQmy0jzxyof7L4i54HHPWFN _Lro- X-Sonic-MF: X-Sonic-ID: 6967b338-ef1a-4153-8490-ecd0b1aa6316 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Jan 2025 15:17:12 +0000 Received: by hermes--production-gq1-5dd4b47f46-k4d2j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2726bc2717b72182d625bcec5737dd02; Tue, 28 Jan 2025 15:17:10 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: trimming_ignore poudriere failure [134releng-armv7-quarterly also failed, still no armv7 2025Q1 build in process] From: Mark Millard X-Priority: 3 In-Reply-To: <7214CF2F-76F5-4478-AE79-0B3B4BB0F70F@yahoo.com> Date: Tue, 28 Jan 2025 07:16:59 -0800 Cc: freebsd-arm@freebsd.org, "freebsd-pkg@freebsd.org" , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <636BDBB6-7358-4979-8A3F-E468852C0BBA@yahoo.com> References: <4226686C-BADB-4D9D-9CF9-54C3AF1692EB.ref@yahoo.com> <4226686C-BADB-4D9D-9CF9-54C3AF1692EB@yahoo.com> <1710947431.3032.1737106880170@localhost> <893896323.1642003.1737126216196@privateemail.com> <6EA6FE58-BB10-418C-86C3-9A8F6BAE80FF@yahoo.com> <61EBD844-922A-411B-93DF-8AD6EECCD4EB@yahoo.com> <501413E9-8C14-41E8-A7C2-767FABA426D0@yahoo.com> <7214CF2F-76F5-4478-AE79-0B3B4BB0F70F@yahoo.com> To: Ronald Klop X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Spamd-Result: default: False [-4.45 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; RBL_SENDERSCORE_REPUT_9(-1.00)[98.137.64.147:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.948]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; HAS_X_PRIO_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Yj8674hzhz3gnK On Jan 23, 2025, at 17:51, Mark Millard wrote: > On Jan 22, 2025, at 21:02, Mark Millard wrote: >=20 >> On Jan 20, 2025, at 16:17, Mark Millard wrote: >>=20 >>> On Jan 17, 2025, at 21:00, Mark Millard wrote: >>>=20 >>>> On Jan 17, 2025, at 10:19, Mark Millard wrote: >>>>=20 >>>>> On Jan 17, 2025, at 07:03, Mark Linimon = wrote: >>>>>=20 >>>>>> On 01/17/2025 3:41 AM CST Ronald Klop = wrote: >>>>>> See latest 141releng-armv7-quarterly = (https://pkg-status.freebsd.org/ampere1/jail.html?mastername=3D141releng-a= rmv7-quarterly) failure: https://pkg-status.freebsd.org/ampere1/. >>>>>>=20 >>>>>> The part of the logs about this error are not public (AFAIK) >>>>>=20 >>>>> The machine is only accessible by IPv6. I have a 6 to 4 bridge = running and >>>>> I was able to access them. >>>>>=20 >>>>> I have access to any bulk build logs and I expect Ronald does too. >>>>> that includes to: >>>>>=20 >>>>> = https://pkg-status.freebsd.org/ampere1/data/141releng-armv7-quarterly/93a8= 6df99a36/logs/ >>>>>=20 >>>>> and to the the (here) empty: >>>>>=20 >>>>> = https://pkg-status.freebsd.org/ampere1/data/141releng-armv7-quarterly/93a8= 6df99a36/logs/errors/ >>>>>=20 >>>>> The type of log showing any error information would not seem to be >>>>> port/package specific but more like what what should show the >>>>> poudriere commands themselves: logs from outside the builder = process >>>>> instead of/from inside a builder process. >>>>>=20 >>>>> As for what can be seen from odd/incomplete content for logs for = inside builder process . . . >>>>>=20 >>>>> There are several logs that are incomplete (all stop with >>>>> "---Begin Environment---") but that do not report any errors. >>>> . . . >>>>=20 >>>> An interesting point for almost all of the too-small log files >>>> (not for the one later example of a zero-size log) . . . >>>>=20 >>>> = https://github.com/freebsd/poudriere/blob/3.4.2/src/share/poudriere/common= .sh >>>>=20 >>>> has: >>>>=20 >>>> echo "---Begin Environment---" >>>> injail /usr/bin/env >>>> echo "---End Environment---" >>>>=20 >>>> which only has "injail /usr/bin/env" before the next echo >>>> and the /usr/bin/env output also did not show up either. >>>>=20 >>>> Some sort of racy "injail" failure specific to armv7, >>>> given the usual lack of failure? >>>>=20 >>>> Some sort of racy "/usr/bin/env" failure specific to armv7, >>>> given the usual lack of failure? (Possibly only for jail >>>> contexts?) >>>=20 >>> FYI: 134releng-armv7-quarterly for 93a86df99a36 also got a >>> failure that leads to "trimming_ignore:" being as far as >>> the status goes: >>>=20 >>> default quarterly 134releng-armv7 93a86df99a36 0 0 0 700 1291 -1991 = trimming_ignore: Mon, 20 Jan 2025 21:39:37 GMT 00:04:14 ampere1 >>>=20 >>> There are, again, a bunch of short logs that end just after: >>> "---Begin Environment---". >>>=20 >>> So, again it is going to be a notable time before armv7 gets a >>> 2025Q1 build, even if the eventual next *releng-armv7 build >>> attempt works. >>=20 >> 141releng-armv7-quarterly for 5db4fd43d478 is building. This will >> jump from failing to build rust-1.81.0 to trying to build >> rust-1.83.0 . >>=20 >> One property is that rust-1.83.0 internally uses llvm19 so anything >> that tries for llvm18 or before but also involves LTO and rust will >> likely fail. (LLVM vintage mixes tend not to work for LTO, >> especially based on older linkers getting involved.) >=20 > rust-1.83.0 built just fine over 06:21:37 . so 4000+ more > packages may end up having an attempted build for > 141releng-armv7-quarterly --finally. 134releng-armv7-quarterly also built rust-1.83.0 just fine, over 06:10:07 . So 4000+ more packages may end up having an attempted build --finally. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jan 29 16:30:24 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YjnhS1Fhhz5lWX9 for ; Wed, 29 Jan 2025 16:30:48 +0000 (UTC) (envelope-from bounce.biir6d7uqwtcue0=jof262k9akjz=4d3v3nhyhne1ib@em790814.fubar.geek.nz) Received: from e3i188.smtp2go.com (e3i188.smtp2go.com [158.120.84.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YjnhP0pqPz3j8h for ; Wed, 29 Jan 2025 16:30:44 +0000 (UTC) (envelope-from bounce.biir6d7uqwtcue0=jof262k9akjz=4d3v3nhyhne1ib@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smtpservice.net header.s=a1-4 header.b=3Embk8eE; dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=MhRiPhSi; spf=pass (mx1.freebsd.org: domain of "bounce.biir6d7uqwtcue0=jof262k9akjz=4d3v3nhyhne1ib@em790814.fubar.geek.nz" designates 158.120.84.188 as permitted sender) smtp.mailfrom="bounce.biir6d7uqwtcue0=jof262k9akjz=4d3v3nhyhne1ib@em790814.fubar.geek.nz"; dmarc=pass (policy=none) header.from=fubar.geek.nz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtpservice.net; i=@smtpservice.net; q=dns/txt; s=a1-4; t=1738168241; h=feedback-id : x-smtpcorp-track : date : message-id : to : subject : from : reply-to : sender : list-unsubscribe : list-unsubscribe-post; bh=82ymbsnOtrbkLB2VwtniN/8x6xXpLG/Gne46X0kHA28=; b=3Embk8eEJXV/5I8D0w0QF7d6WtST7xbCrAr7D0eVBAV5yTKzNFrimCqMtpMzk2gv3Hjy1 KFGb/6aaQWsN276Aco4iffVnVtKg94IIMgWbbH3rbKT7fkHUkqqnp31o/0SuVKhz95EfNjl pqJ/RCZ+HZtffwYgDvOtJiGAx5jjkj/dNOj4MiDUITImjok/C0vq9+YGr+GD4VkoBL82xc2 SzA9AffQcrlrYMS60JWOp3MnxLjKja6CUj64hmv6UX9Cm1E5T4kw/3Lk380FmN13jJbUiDL HraR9jDoCLuAL31UEXV1KqHP/zwVmtDHB9YBPhyx9xMfkrc11wHyyDKvQS+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1738168241; h=from : subject : to : message-id : date; bh=82ymbsnOtrbkLB2VwtniN/8x6xXpLG/Gne46X0kHA28=; b=MhRiPhSiDDyIvxAvJDXDK6Y0Xn0oSwvtaglEZjED8Lr/t6H0sj9WmO/uAqVKzVcDqUV8D Jqcv2B/oFd78Zjh88zjKxSKAMIjR/j/Gj62jaQfHYlPt/GMJIPogbfPIizsRsRbrkAzlMsj pGNDz0fjEm2HG8ISrr4F43yJ/BA6cb3e4Sgh6a4iLr8WvNJsQmyHYx4ngacNlsHYAQ+GgVH XKpj2j+keeu7JKCvlHUIhfknFwuswbsye6/sytjeKzJKG/5qZyX7wMnLFAiZL0TOAqqsuzJ 5YRcuR+LomoiBxhHuoy5rvRosD6ndKaK+cjFwzrePH/sBIyyX+xqMiOSQJcg== Received: from [10.99.243.232] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97.1-S2G) (envelope-from ) id 1tdAxb-AIkwcC8j10z-HVFK; Wed, 29 Jan 2025 16:30:39 +0000 Received: from smtpclient.apple (92.40.185.212.threembb.co.uk [92.40.185.212]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 606C042363; Wed, 29 Jan 2025 16:30:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: Radxa Orion O6 From: Andrew Turner In-Reply-To: Date: Wed, 29 Jan 2025 16:30:24 +0000 Cc: FreeBSD ARM List , Warner Losh , Mark Millard Content-Transfer-Encoding: quoted-printable Message-Id: <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> References: <087C4A9F-288B-40EA-BE1B-ACFD32C86DF2@yahoo.com> <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> To: FUKAUMI Naoki X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 790814m:790814amQcrys:790814sUhNOnlKVb X-smtpcorp-track: 2tPGwrT3K4f_.BRb-fNIwFCbE.8F7eNwAUwQ3 X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_SENDERSCORE_REPUT_9(-1.00)[158.120.84.188:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bounce.biir6d7uqwtcue0=jof262k9akjz=4d3v3nhyhne1ib@em790814.fubar.geek.nz]; R_SPF_ALLOW(-0.20)[+ip4:158.120.80.0/21]; R_DKIM_ALLOW(-0.20)[smtpservice.net:s=a1-4,fubar.geek.nz:s=s790814]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:23352, ipnet:158.120.84.0/22, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,bsdimp.com,yahoo.com]; FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bounce.biir6d7uqwtcue0=jof262k9akjz=4d3v3nhyhne1ib@em790814.fubar.geek.nz]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[smtpservice.net:+,fubar.geek.nz:+] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4YjnhP0pqPz3j8h > On 25 Jan 2025, at 23:18, FUKAUMI Naoki wrote: >=20 > Hi, >=20 > On 1/23/25 10:01, FUKAUMI Naoki wrote: >> On 1/23/25 08:02, FUKAUMI Naoki wrote: >> : >>> pcib0: on acpi0 >>> pcib0: Bus is cache-coherent >>> pcib0: ECAM for bus 96-127 at mem 26000000-27ffffff >>> pcib0: could not allocate memory. >>> device_attach: pcib0 attach returned 6 >>> pcib0: on acpi0 >>> pcib0: Bus is cache-coherent >>> pcib0: ECAM for bus 48-79 at mem 23000000-24ffffff >>> pcib0: could not allocate memory. >>> device_attach: pcib0 attach returned 6 >>> pcib0: on acpi0 >>> pcib0: Bus is cache-coherent >>> pcib0: ECAM for bus 0-31 at mem 20000000-21ffffff >>> pcib0: could not allocate memory. >>> device_attach: pcib0 attach returned 6 >> PCIe is not configured in ACPI mode too. >=20 > PCIe is not working yet. Any idea? I suspect there is a conflict where two devices both try to allocate the = same memory resource. Can you try booting with =E2=80=9Cdebug.rman_debug=3D1=E2=80=9D set from = the loader prompt? It will print a lot of logging about different memory = and interrupt resources being allocated so you will likely need = something to save the output, e.g. reading the serial output under = script. It=E2=80=99s will also likely be too much for the list, so you = can email it to me directly. Andrew From nobody Wed Jan 29 22:41:53 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yjxws3BRmz5mN3k for ; Wed, 29 Jan 2025 22:42:05 +0000 (UTC) (envelope-from naoki@radxa.com) Received: from smtpbg151.qq.com (smtpbg151.qq.com [18.169.211.239]) (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 4Yjxwr3gDSz401W for ; Wed, 29 Jan 2025 22:42:04 +0000 (UTC) (envelope-from naoki@radxa.com) Authentication-Results: mx1.freebsd.org; none X-QQ-mid: bizesmtpip2t1738190516tce0id1 X-QQ-Originating-IP: kao4dFLNs8rFogBTg5LJOnwICSlNzNnexq2QWsluztQ= Received: from [IPV6:240f:10b:7440:1:d810:3703 ( [localhost]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 30 Jan 2025 06:41:54 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 8906672972866427565 Message-ID: <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> Date: Thu, 30 Jan 2025 07:41:53 +0900 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Radxa Orion O6 To: Andrew Turner Cc: FreeBSD ARM List , Warner Losh , Mark Millard References: <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> Content-Language: en-US From: FUKAUMI Naoki In-Reply-To: <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpip:radxa.com:qybglogicsvrgz:qybglogicsvrgz8a-1 X-QQ-XMAILINFO: MyirvGjpKb1j5lsKWishG09U/yFS8noBLRaT4shuJ00LrEWqcumP68xG aASavf2J7KketWUKAfopWHBSZpAU9vHSW5vsQWhQtL5Rp+xW0A9EAUitHUbfw1KsZ3j78O3 gGRvjc4j0X0YyIHyLMgXh79D11Keee/0eLbDwZpXerwlb5zrmcvujGPQyt2BPl8BTH/PcTL MCibSaTyc/bL0z34TTZuuzFm0fRa6tEXEblqZR6XxasqZ912E3626kH5BywE4Db7BTfClmi RH9KGH5TI7J0snf2zg0D3rI4zPVqGKrzs78XWbg+SUK1cRgWCIFvkEnLBtmXl13RQerQ+Mz p4JRyA8tzRwUGoTEFmPQboS6hRzZTQ4K45d703Xmd+HZhUEFY3cf+2WNJlJTEes0XCLb11L E5C6b7Ke9oZr2j0xDxEr/n5SO1e0mail4HonZYenUI7WMjlK5rBP3Hu5Sd4HcxU1jbFJ/4Z f7KCoLtlUC6Wwz4y/RYf9XaTrxcp0Pb7968Gi1Ag9Sygxzg4UhfCFQVTEMhANO1hGj1rEyz 0m8tckP4/8eoS4FqFNweg33O5W0fC5NfJmhaDfbW/kJhIoJKpW/jFVYFTXrHe1QONS8F+Jk QkW445RdA/hBds3zAYi4/pI6pRhlgUEgIt2Jf6Iw5TW4tx0y+ol5iaoRUrarZFZrotm0psc JJENAZFCoHU2NLKZC3TOajPMBN7PalCoCWt/WizeW3P2aAawAIOr4Nf9P3taSbhQpsyBKn9 P5dtjSBsyzu4x6VtSyCIbn1nC+lNKt6D4zW16XMbJ9hoXFsrvZm6IN262FlYkoFzobtsn6C 64ZCkt4klJlmQMX+k7QLbE7D1u74tFuLgBkzuCJMBl6qcgLwaTsbsxDS3LZkKLjMgSSRgEV 7IixbZgFDX2r5WC08QNFI3IuuiV54EziE2W5SwpV785cvl6KODMLiIk3NHgZwnNqQpPT12L UtAb5ZBfz9Lzov712ObKF/IgX X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU= X-QQ-RECHKSPAM: 0 X-Rspamd-Queue-Id: 4Yjxwr3gDSz401W X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:18.168.0.0/14, country:US] Hi Andrew, On 1/30/25 01:30, Andrew Turner wrote: >>>> pcib0: on acpi0 >>>> pcib0: Bus is cache-coherent >>>> pcib0: ECAM for bus 96-127 at mem 26000000-27ffffff >>>> pcib0: could not allocate memory. >>>> device_attach: pcib0 attach returned 6 >>>> pcib0: on acpi0 >>>> pcib0: Bus is cache-coherent >>>> pcib0: ECAM for bus 48-79 at mem 23000000-24ffffff >>>> pcib0: could not allocate memory. >>>> device_attach: pcib0 attach returned 6 >>>> pcib0: on acpi0 >>>> pcib0: Bus is cache-coherent >>>> pcib0: ECAM for bus 0-31 at mem 20000000-21ffffff >>>> pcib0: could not allocate memory. >>>> device_attach: pcib0 attach returned 6 >>> PCIe is not configured in ACPI mode too. >> >> PCIe is not working yet. Any idea? > > I suspect there is a conflict where two devices both try to allocate the same memory resource. > > Can you try booting with “debug.rman_debug=1” set from the loader prompt? It will print a lot of logging about different memory and interrupt resources being allocated so you will likely need something to save the output, e.g. reading the serial output under script. It’s will also likely be too much for the list, so you can email it to me directly. I uploaded dmesg here: https://drive.google.com/file/d/1HzZFFIaBu2gyDHF7oPnNLuzU_CBMF5dC/view?usp=sharing Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. From nobody Thu Jan 30 14:14:26 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YkLcq34Xwz5mXKn for ; Thu, 30 Jan 2025 14:14:35 +0000 (UTC) (envelope-from bounce.nl1dwe19bbrle82=8qbi3clk9ulb=94eifkt75r7wro@em790814.fubar.geek.nz) Received: from e3i188.smtp2go.com (e3i188.smtp2go.com [158.120.84.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YkLcp6f6Pz3H6p for ; Thu, 30 Jan 2025 14:14:33 +0000 (UTC) (envelope-from bounce.nl1dwe19bbrle82=8qbi3clk9ulb=94eifkt75r7wro@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtpservice.net; i=@smtpservice.net; q=dns/txt; s=a1-4; t=1738246471; h=feedback-id : x-smtpcorp-track : date : message-id : to : subject : from : reply-to : sender : list-unsubscribe : list-unsubscribe-post; bh=XMvSIVccFzD2IxPTcp927/+OSsBra6Ey9IMfN6MJFyA=; b=SCmIiHoqgrmRwSMoJrLexxm6x49x8vIl5MiWZoudUUqGpOZP3QDvU2o6tfmCcVPT7UtsQ fdr8iLhRmC+rqp4y4cLGMsAHQRHIt/g7/Nv5SqwtSIBoVoKM2t055B1LvMhLDnXBsj44kBA 6OTIejjTuZlhjd7lQVCdnV+sppi6/C5MeHqSv4SOjP4wI+3fAHBeUYjMb1702uMz6T177cB 8eFvhxhnCa0+o6UenAXyHK9MMPTqseofMoCxHT8bp4O0E93CEN95YjDV+kHp7S9Gcko2sCM YDQ1VLTzMS31Fxv9ZuvJWeOZS0cI8ZF5qjo4darkOmFCiNYFpijYkEDY+UvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1738246471; h=from : subject : to : message-id : date; bh=XMvSIVccFzD2IxPTcp927/+OSsBra6Ey9IMfN6MJFyA=; b=QL0HYpblFPxZkbyRJogs6jEBEzj8qoV2EW/q+qcLFuCNh9wxWCfZ+karPu6mYR90pkQVw kM2BnaXU31QoGdYsaV1QbhSciK+FWj6TZsaLjutT93F0Rl29961IxfymCq0zChUHPOaNYkr NTb54si+NzNvyVUWja+e1mp6MTHsYEcY4eX/kIlO+x6EwNUu3+DOh7YD0ZC+Pceeabr+gUD D0Tuelk9NE3S0n79K5mhOVXcJqY+TqSM0R2QTwaNLqc2AC7u0/8kRMqR7KJiL5+IeOq8rmN QZ6LZdwAclmm4st+M37kzwtfNNQq6YnRWI62MzUmYEGPGBN4DFmMMS124oCA== Received: from [10.99.243.232] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97.1-S2G) (envelope-from ) id 1tdVJM-AIkwcC8nhp6-J8Jj; Thu, 30 Jan 2025 14:14:28 +0000 Received: from webmail.fubar.geek.nz (unknown [IPv6:2a01:4f8:c010:8044::1]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 9D4E342C44; Thu, 30 Jan 2025 14:14:26 +0000 (UTC) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Date: Thu, 30 Jan 2025 14:14:26 +0000 From: Andrew Turner To: FUKAUMI Naoki Cc: FreeBSD ARM List , Warner Losh , Mark Millard Subject: Re: Radxa Orion O6 In-Reply-To: <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> References: <9B90ADE3-9E1E-448A-B592-509B0E61B197@yahoo.com> <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> Message-ID: <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> X-Sender: andrew@fubar.geek.nz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 790814m:790814amQcrys:790814sUhNOnlKVb X-smtpcorp-track: FXSgis5SOXCQ.-0P75dtJ4LKX.MnmgJQ78jfj X-Rspamd-Queue-Id: 4YkLcp6f6Pz3H6p X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:158.120.84.0/22, country:US] On 2025-01-29 22:41, FUKAUMI Naoki wrote: > Hi Andrew, > > On 1/30/25 01:30, Andrew Turner wrote: >>>>> pcib0: on acpi0 >>>>> pcib0: Bus is cache-coherent >>>>> pcib0: ECAM for bus 96-127 at mem 26000000-27ffffff >>>>> pcib0: could not allocate memory. >>>>> device_attach: pcib0 attach returned 6 >>>>> pcib0: on acpi0 >>>>> pcib0: Bus is cache-coherent >>>>> pcib0: ECAM for bus 48-79 at mem 23000000-24ffffff >>>>> pcib0: could not allocate memory. >>>>> device_attach: pcib0 attach returned 6 >>>>> pcib0: on acpi0 >>>>> pcib0: Bus is cache-coherent >>>>> pcib0: ECAM for bus 0-31 at mem 20000000-21ffffff >>>>> pcib0: could not allocate memory. >>>>> device_attach: pcib0 attach returned 6 >>>> PCIe is not configured in ACPI mode too. >>> >>> PCIe is not working yet. Any idea? >> >> I suspect there is a conflict where two devices both try to allocate >> the same memory resource. >> >> Can you try booting with “debug.rman_debug=1” set from the loader >> prompt? It will print a lot of logging about different memory and >> interrupt resources being allocated so you will likely need something >> to save the output, e.g. reading the serial output under script. It’s >> will also likely be too much for the list, so you can email it to me >> directly. > > I uploaded dmesg here: > > https://drive.google.com/file/d/1HzZFFIaBu2gyDHF7oPnNLuzU_CBMF5dC/view?usp=sharing Hello, The follow lines indicate another device has reserved the PCIe memory, however the details of which device has the reservation has been lost from the top of output. considering [0x2c000000, 0x2fffffff] region is allocated Is it possible to get the data from earlier in the boot? Andrew From nobody Thu Jan 30 14:45:59 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YkMKQ1vvwz5md3N for ; Thu, 30 Jan 2025 14:46:18 +0000 (UTC) (envelope-from naoki@radxa.com) Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) (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 4YkMKP14kQz3NpB for ; Thu, 30 Jan 2025 14:46:16 +0000 (UTC) (envelope-from naoki@radxa.com) Authentication-Results: mx1.freebsd.org; none X-QQ-mid: bizesmtpip2t1738248364tmbpja8 X-QQ-Originating-IP: lUpw6oW/R5FxZUJUmQSllrpbeToHOAuMLia6N9kPgSE= Received: from [IPV6:240f:10b:7440:1:ca80:432: ( [localhost]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 30 Jan 2025 22:46:00 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 1128524495825441986 Message-ID: <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> Date: Thu, 30 Jan 2025 23:45:59 +0900 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Radxa Orion O6 To: Andrew Turner Cc: FreeBSD ARM List , Warner Losh , Mark Millard References: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> Content-Language: en-US From: FUKAUMI Naoki In-Reply-To: <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpip:radxa.com:qybglogicsvrgz:qybglogicsvrgz8a-1 X-QQ-XMAILINFO: M5aCtjAndv5OL2Fkf/XSXtTAKAMxQ0DjHTNhLNWdigLyFPGdh/7QpwRF 7TpEDdxyCaHRvvWE1/W2lOhRqAx1Z9vgvM2LOMzFjhLaCSize4Nvr3ZqcMLRsaCuSDrmyYA oFyQrDJSo7Rn5BQbb8N9bnR6aicaKAkWgJwbzu40Vu2tiPQGIPNPOD3XEbrOdbN3Mfuy+W0 vn7lyKIWSBrov1Kw0X3dRU3RXRTm9H82b9Go5nkgqL0wDTZZWK6uHcYyUrI26gN4JLcpai6 0fC+YHcG4CKA9HZhk5Cb0A1zXB0M8LSoV4Wjdj/PPnwgO2eZcFkHhQL5mhGjVV9IejAROEg D2pnsgoOOQHZG1eV5YRLN92BZ5c4sH7IHJ4sCBONjSBIvaDjMvrYDFNhtuP/l6X7QN1CfI4 AL/cLA4FfYzaH1JkxlN1zt2rREigSqkAoWtTu7SIO3fEhCS3sw2mgMm8VqbHGj5UqiSB7Bv GfbLVbFcv9SsBMo1Izr4CtlKaaG820TzP6UUfrDjkdQOmM7SPnC+uGmFeJLkj1PcmbUHTz9 6HsoAyy+guEeEFIYWZKa3GTkQ0UrVzKTLdW/Ar5+ZOWVf8kFyYJF+l1mCCfbYJkmUA9IqFd ti9hQxow9WXuOT8rnk1GPuPp+DkCoFf70Kjd53s7JsvgousfFZRIr/ZDJLZhXYe0uUXxDv4 1UjyZDctjCh6EEHMCXzCvD939bU8b/Vpox5d/Cm+uqoUMZgtj3NA7jkv7f/XFVdi20QrT5g eSxRQo+bp+tDVpH05tpTFPKUU8gjQCsZ6iEe2eadQRf5uc3DykE5qXYTU35tgiVjpXl903c Csl8RPtc8t09xoZSMukb7uCjoQeRKaFa2yFKQrq0mTdStu4b+gn5LojKHOrro3AeT0ja0bV Ao/TTPTo+smZalPNWGij6DdlU5Vz851P0mIR2ek3VkXLZ2N690fLgqjYB6wD/j/8 X-QQ-XMRINFO: OWPUhxQsoeAVDbp3OJHYyFg= X-QQ-RECHKSPAM: 0 X-Rspamd-Queue-Id: 4YkMKP14kQz3NpB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US] Hi Andrew, On 1/30/25 23:14, Andrew Turner wrote: >>>> PCIe is not working yet. Any idea? >>> >>> I suspect there is a conflict where two devices both try to allocate >>> the same memory resource. >>> >>> Can you try booting with “debug.rman_debug=1” set from the loader >>> prompt? It will print a lot of logging about different memory and >>> interrupt resources being allocated so you will likely need something >>> to save the output, e.g. reading the serial output under script. It’s >>> will also likely be too much for the list, so you can email it to me >>> directly. >> >> I uploaded dmesg here: >> >> https://drive.google.com/file/d/1HzZFFIaBu2gyDHF7oPnNLuzU_CBMF5dC/ >> view?usp=sharing > > Hello, > > The follow lines indicate another device has reserved the PCIe memory, > however the details of which device has the reservation has been lost > from the top of output. > > considering [0x2c000000, 0x2fffffff] > region is allocated > > Is it possible to get the data from earlier in the boot? Sorry, I didn't realise the log was incomplete. This should be complete... https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/view?usp=sharing Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. From nobody Thu Jan 30 21:11:22 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YkWt13VR7z5mktW for ; Thu, 30 Jan 2025 21:11:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YkWt061M3z3My5 for ; Thu, 30 Jan 2025 21:11:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1738271494; bh=f9+I6jxm+IW/X89sHcQAyho/QbdsegYk2HVcSZr6vFA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KQvUMSJ0PWZK6Yrz4BHpxjIoXqLdsSs11dZcnfzoxJ5jWOCV9ukuIgsoXl/k9klBuTjC91JxchziZmafmejgBiDJg5mXMzSq/hEmpMTKhabHuIn6ZWrMOQHN4hamDbTZA83ODcKWUzCZ0Ec/x63uSNiUwUrU4TJ7NBYeiiYPiyEWH8J5mRWoGvYFUBX7THDAme86xB20U6yuL+rgAAb98SI/Y+t6eJfCuGv6FzREOhoycWpHzW/fEKKhMZjojHj1Nwaaz7osbtEcSSbsyQsFecnfolB+u+Ao87+vTOaJfoz9gAWn+w0Bnpl18ru44dAdmh/PZsriITnQwnTThMs3Bw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1738271494; bh=uXfCjKKpLVUkzzp6oyVC7CoTDVr08UzZ9CT5kqFCPXc=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CZ88CAG7hEDrW392telG1h3SNJhXTQF6ZnmM6COpP10X94UN9VOI/oKDp/yhNMBKd/ZuWIN6vO+iG+6j4mJtmiKO+w+spKoDnKRkdeUzyyeJj4JcNE/u3G/z1v0sty+j2CFMnHEZX0QrhoBQl/cbq4tyjdWSmt3HVbruDePq/awAxBJvMS/AFS2gF65mUz9DOIjmC9ZudxgPFxaGcKAwFLXqpk0MA+54/NzQOcZAJ2WBUckzAKbfsg5SGel7RlVIZ239CHGCwn4Q6U4zO2UCT3XLATlCQwUfFKNCaz5j572XqaYTmTpRbvXKUG+Z7iw7+z6MZK5pC4xmfT5iEVGFjQ== X-YMail-OSG: aKktbYwVM1lwxXvAgHvZpSALy3e_tmKnrdNQ3rSuOe9oJvkBKd05aqImwv5kGa4 KGRq_zSKJP9gecUYtTAIVCli7TgDiO2EvFCU9KfVGn1RB5AiNEJjWXfOp8bTQxfY353HPuI1aqtL i7CzxRDO0G5CR0..QlD21MXyBScdszLsdMaknC0hXS6z_868KQp1EP6R0mzNnzLUuyHqFIEHf7v5 btfd1l5.Bc9etNQKpAxL9HUDOCUDCEeGsmheNZkIDWodRy8hOggJTrmYNeV7GI9T_kxpSo0FllAp BcwaOLVssUPA40TlYRrFyAL6c5sx17vMVCYRtJer9WeUKPhkpVq76e2CXhLLVA4MhN3DhWEa.Xy_ sbhGMk9wGhdPeOdw3LpgtQrqWqDrKwBiIvgWM4yxUc9iYkOBdjzmwkV1iq0tBg1Cwf7arP8bURVQ uD8ZoGyaIsWTCYLKyYtbr7HPQEeW2ar.tf1VKefz2ZJ6YEJ5NEixZZL_Cef5gPx1s_JoHlIkYwm2 b5JROXXFKpTsZRwcEUIDGSd6xzl7cn.s5YuxO4GzhRa7A05G89XB2s1oea4yEmXQsMV1.Pfj9rjN 3MwXdVhUH_Pdr8yhisBgx51PZrTw5uSfx1MHoJJJxxCp2QtWd2i4giA_3vkEg4vRbhQNZ9Nm5uLu vBiNjcxgW8lJagVVhRvaw7hncKyAUCjfSlsxbXeHxO1vVJITIhKrEVQLa9tCJqqBesDfkA7VSgsz qBdHOl4DetlJISy9cTgTbJkjiPxLZ9eX2XEafk45b.oZmlRCxozBDDfWSHzFmcvIDgdiicawxYlI yaq_bjWEvToU4c5gddPXUTfMCRvs2OX9qL.hsSKZACsTFp3cy6MlWkGAEanmm5mFjn8AtiQQhjbl _yFIkdIsN4C5.IFEIQI7d7cMKzyZOJ1Nkxi.._oXptCQym.0j_t7rHa0S0YuK2pRQ4lYLeNB4PVE kwkWOyNUjjwOBK5D6B.NCfVPr9eBEaXAnQMrMzfZKsY1MDr.daWHn3jEqV2rL1VBsrPH8PoVs1u9 aSeV.D0s0LP4V_pYswMBazDRghnJHUN_DUgaK78pbLRtedwvwi1GXfmShWZpjTZtSINMfAoHY7H4 lWEHZXmQ1RUBK..F7NUNX8aRAilYO0dp_Qr548UWpx7kINJ5SbdvZQ9mNWXKTqaGTnlLW7XSnva4 cHr88COE5vGqz9B3RePme8uRUcUP1y.Dsc7o9lo1db4XUUKyzeTiEHEopKmHqbGSeZ7Y2G4Ex9eF Bn2keeRSUogqf25T3jeaWUoBZHx7B_mgvOo7BLIeKKd.ks6URRTvsCWBADq9rnPqfpgErDT8SLM. Qh469hRCnM_ganZZfmWvOxHH3dPWBkd6PVlGKiC1MrXkb.3UyWmtGExmSG.pDMIjIWLQ3EeJfFyu 0Zqbo_XTXTkhtxZKtpyRHj5SUv8Ir_dM72sHR4qFVIPQxNecRlhnAKMJZSswF8T4HzYoymy1RL46 j1Yl5XP3f0SzP_3rFz5PE84D5Vl7juqDRpgIFIzjdM0DePJ_fHhfUhA7mL._WJL4A6inWUmsPT4X 5cLvp0lQs5RLEssJv_FHWZmkNHKmylA9lmA1QKuiXDagkuooA60S4x8bPfmDlwuQ5AmmuntK5ijT I568x3K.kwAwdlOdZMbRDfM2a_SaxMMAj8.upV8d4_7VJcIuy5tFZtN6ty_4p1KhhjKTbe5QGMDs TWnHby1p5SFIJJ5TsGDlhNJtzBnafAfpC4B0ibpo2ig1yBMDV_myGBEWTV.48dvNEf2ELL6g_1tt r_UCTdo.nm45ZJAqx0GLTe6o5xZVff4IbFwbvlHihZEIJxsLLCvfUFB9ebg5FBkz.oKaqCU6z7dE JKexiDGqLumo6sOD5XPzzZ4nLM9iEr8_besjms1XQHXNLJQ9984eUPDfN8aMTaS83_Dq3e7FGxQD KSUL1WrgiX4647uu7zwImM5mEEev8MhWhKX5wapSM23rvLpJiwycF6N8au7tJUU.v3EjOIF83MQK ywjlY9GE4OBUcx8GyD7NzkNKCRQczlSl8.P_Uyo6JOH75ioR8lvjSBrVSKSSY1wuBLn63mFKZHaw _UNHD2d4ImrDnbm8ErcshNzJvp.rP7bkl9xk41lN9eciHlUYmOQ0pSgjIKIX4P4paJzqx6J5RuFL leBso1llUb0rM3SIr_kXTrQFlMb8wWXEr7avhbrM3oyzGRkBRVYqfVvkbscCXMdCd9eHyymXSNiy jFCRdsTAaVhqlJPGXacJOPPbwykTM6_lvAXZv6eManeXB499FsBooGt0HfAV2s2amyMqBdPEGjjc a.kM- X-Sonic-MF: X-Sonic-ID: fb8bee9f-efaa-4609-bc90-b09fc747e1ff Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Jan 2025 21:11:34 +0000 Received: by hermes--production-gq1-5dd4b47f46-5kxd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2658b4e78ddfb87321d1800d1d30ea13; Thu, 30 Jan 2025 21:11:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: Re: Radxa Orion O6 From: Mark Millard In-Reply-To: <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> Date: Thu, 30 Jan 2025 13:11:22 -0800 Cc: Andrew Turner , FreeBSD ARM List , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> To: FUKAUMI Naoki X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Queue-Id: 4YkWt061M3z3My5 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Jan 30, 2025, at 06:45, FUKAUMI Naoki wrote: > On 1/30/25 23:14, Andrew Turner wrote: >>>>> PCIe is not working yet. Any idea? >>>>=20 >>>> I suspect there is a conflict where two devices both try to = allocate the same memory resource. >>>>=20 >>>> Can you try booting with =E2=80=9Cdebug.rman_debug=3D1=E2=80=9D set = from the loader prompt? It will print a lot of logging about different = memory and interrupt resources being allocated so you will likely need = something to save the output, e.g. reading the serial output under = script. It=E2=80=99s will also likely be too much for the list, so you = can email it to me directly. >>>=20 >>> I uploaded dmesg here: >>>=20 >>> https://drive.google.com/file/d/1HzZFFIaBu2gyDHF7oPnNLuzU_CBMF5dC/ = view?usp=3Dsharing >> Hello, >> The follow lines indicate another device has reserved the PCIe = memory, however the details of which device has the reservation has been = lost from the top of output. >> considering [0x2c000000, 0x2fffffff] >> region is allocated >> Is it possible to get the data from earlier in the boot? >=20 > Sorry, I didn't realise the log was incomplete. >=20 > This should be complete... > = https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/view?usp= =3Dsharing There are 21 "no unshared regions found", 19 of which also report a prior "region is allocated" hit as well. There are also 3 "NULL list head"/"could not find a region" examples: all being pcib0 examples with "". Each of the 3 has one of the "no unshared regions found" for "" just prior as well. The 21 "no unshared regions found" (some with some extra context) are: rman_reserve_resource: request: [0x16000000, = 0x16000fff], length 0x1000, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x16000000,0xfff> . . . rman_reserve_resource: tried 0x15ffffff <0x16000000,0xfff> considering [0x16000000, 0x16000fff] region is allocated considering [0x16001000, 0x16006fff] s->r_start (0x16001000) + count - 1> end (0x16000fff) no unshared regions found rman_reserve_resource: request: [0x4160000, = 0x4160fff], length 0x1000, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x4160000,0xfff> . . . rman_reserve_resource: tried 0x416011b <0x4160000,0xfff> considering [0x416011c, 0x416ffff] s->r_start (0x416011c) + count - 1> end (0x4160fff) no unshared regions found rman_reserve_resource: request: [0x16000000, = 0x16000fff], length 0x1000, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x16000000,0xfff> . . . rman_reserve_resource: tried 0x15ffffff <0x16000000,0xfff> considering [0x16000000, 0x16000fff] region is allocated considering [0x16001000, 0x16006fff] s->r_start (0x16001000) + count - 1> end (0x16000fff) no unshared regions found . . . rman_reserve_resource: request: [0x6590000, = 0x659007f], length 0x80, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x6590000,0x7f> . . . rman_reserve_resource: tried 0x658ffff <0x6590000,0x7f> considering [0x6590000, 0x659ffff] region is allocated considering [0x65a0000, 0x65affff] s->r_start (0x65a0000) + count - 1> end (0x659007f) no unshared regions found rman_reserve_resource: request: [0x65a0000, = 0x65a007f], length 0x80, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x65a0000,0x7f> . . . rman_reserve_resource: tried 0x659ffff <0x65a0000,0x7f> considering [0x65a0000, 0x65affff] region is allocated considering [0x65b0000, 0x70effff] s->r_start (0x65b0000) + count - 1> end (0x65a007f) no unshared regions found . . . rman_reserve_resource: request: [0x7110000, = 0x711ffff], length 0x10000, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x7110000,0xffff> . . . rman_reserve_resource: tried 0x710ffff <0x7110000,0xffff> considering [0x7110000, 0x711ffff] region is allocated considering [0x7120000, 0x930ffff] s->r_start (0x7120000) + count - 1> end (0x711ffff) no unshared regions found . . . rman_reserve_resource: request: [0x7110000, = 0x711ffff], length 0x10000, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x7110000,0xffff> . . . rman_reserve_resource: tried 0x710ffff <0x7110000,0xffff> considering [0x7110000, 0x711ffff] region is allocated considering [0x7120000, 0x930ffff] s->r_start (0x7120000) + count - 1> end (0x711ffff) no unshared regions found rman_reserve_resource: request: [0x7000000, = 0x7ffffff], length 0x1000000, flags 0, device (null) rman_reserve_resource: trying 0x40affff <0x7000000,0xffffff> . . . rman_reserve_resource: tried 0x711ffff <0x7000000,0xffffff> considering [0x7120000, 0x930ffff] s->r_start (0x7120000) + count - 1> end (0x7ffffff) no unshared regions found . . . rman_reserve_resource: request: [0xa060000, = 0xa06ffff], length 0x10000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0xa060000,0xffff> . . . rman_reserve_resource: tried 0xa05ffff <0xa060000,0xffff> considering [0xa060000, 0xa06ffff] region is allocated considering [0xa070000, 0xa07ffff] s->r_start (0xa070000) + count - 1> end (0xa06ffff) no unshared regions found . . . rman_reserve_resource: request: [0xa060000, = 0xa06ffff], length 0x10000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0xa060000,0xffff> . . . rman_reserve_resource: tried 0xa05ffff <0xa060000,0xffff> considering [0xa060000, 0xa06ffff] region is allocated considering [0xa070000, 0xa07ffff] s->r_start (0xa070000) + count - 1> end (0xa06ffff) no unshared regions found . . . rman_reserve_resource: request: [0x9018000, = 0x901ffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x9018000,0x7fff> . . . rman_reserve_resource: tried 0x9017fff <0x9018000,0x7fff> considering [0x9018000, 0x901ffff] region is allocated considering [0x9020000, 0x902ffff] s->r_start (0x9020000) + count - 1> end (0x901ffff) no unshared regions found . . . rman_reserve_resource: request: [0x90f8000, = 0x90fffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x90f8000,0x7fff> . . . rman_reserve_resource: tried 0x90f7fff <0x90f8000,0x7fff> considering [0x90f8000, 0x90fffff] region is allocated considering [0x9100000, 0x910ffff] s->r_start (0x9100000) + count - 1> end (0x90fffff) no unshared regions found . . . rman_reserve_resource: request: [0x91d8000, = 0x91dffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x91d8000,0x7fff> . . . rman_reserve_resource: tried 0x91d7fff <0x91d8000,0x7fff> considering [0x91d8000, 0x91dffff] region is allocated considering [0x91e0000, 0x91e7fff] s->r_start (0x91e0000) + count - 1> end (0x91dffff) no unshared regions found . . . rman_reserve_resource: request: [0x91e8000, = 0x91effff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x91e8000,0x7fff> . . . rman_reserve_resource: tried 0x91e7fff <0x91e8000,0x7fff> considering [0x91e8000, 0x91effff] region is allocated considering [0x91f0000, 0x920ffff] s->r_start (0x91f0000) + count - 1> end (0x91effff) no unshared regions found . . . rman_reserve_resource: request: [0x9268000, = 0x926ffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x9268000,0x7fff> . . . rman_reserve_resource: tried 0x9267fff <0x9268000,0x7fff> considering [0x9268000, 0x926ffff] region is allocated considering [0x9270000, 0x928030f] s->r_start (0x9270000) + count - 1> end (0x926ffff) no unshared regions found . . . rman_reserve_resource: request: [0x9298000, = 0x929ffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x9298000,0x7fff> . . . rman_reserve_resource: tried 0x9297fff <0x9298000,0x7fff> considering [0x9298000, 0x929ffff] region is allocated considering [0x92a0000, 0x92b030f] s->r_start (0x92a0000) + count - 1> end (0x929ffff) no unshared regions found . . . rman_reserve_resource: request: [0x92c8000, = 0x92cffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x92c8000,0x7fff> . . . rman_reserve_resource: tried 0x92c7fff <0x92c8000,0x7fff> considering [0x92c8000, 0x92cffff] region is allocated considering [0x92d0000, 0x92e030f] s->r_start (0x92d0000) + count - 1> end (0x92cffff) no unshared regions found . . . rman_reserve_resource: request: [0x92f4000, = 0x92f7fff], length 0x4000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x92f4000,0x3fff> . . . rman_reserve_resource: tried 0x92f3fff <0x92f4000,0x3fff> considering [0x92f4000, 0x92f7fff] truncated region: [0x92f4000, 0x92f7fff]; size 0x4000 (requested 0x4000) candidate region: [0x92f4000, 0x92f7fff], size 0x4000 candidate region is entire chunk rman_reserve_resource: request: [0x92f8000, = 0x92fffff], length 0x8000, flags 0, device (null) rman_reserve_resource: trying 0x401ffff <0x92f8000,0x7fff> . . . rman_reserve_resource: tried 0x92f7fff <0x92f8000,0x7fff> considering [0x92f8000, 0x92fffff] region is allocated considering [0x9300000, 0x930ffff] s->r_start (0x9300000) + count - 1> end (0x92fffff) no unshared regions found . . . acpi_tz0: on acpi0 pcib0: on acpi0 pcib0: Bus is cache-coherent pcib0: ECAM for bus 144-175 at mem 29000000-2affffff rman_reserve_resource: request: [0x29000000, = 0x2affffff], length 0x2000000, flags 100, device pcib0 rman_reserve_resource: trying 0x401ffff <0x29000000,0x1ffffff> . . . rman_reserve_resource: tried 0x28ffffff <0x29000000,0x1ffffff> considering [0x29000000, 0x2bffffff] region is allocated considering [0x2c000000, 0x2fffffff] s->r_start (0x2c000000) + count - 1> end (0x2affffff) no unshared regions found rman_reserve_resource: request: [0x29000000, = 0x2affffff], length 0x2000000, flags 100, device pcib0 NULL list head could not find a region pcib0: could not allocate memory. device_attach: pcib0 attach returned 6 pcib0: on acpi0 pcib0: Bus is cache-coherent pcib0: ECAM for bus 48-79 at mem 23000000-24ffffff rman_reserve_resource: request: [0x23000000, = 0x24ffffff], length 0x2000000, flags 100, device pcib0 rman_reserve_resource: trying 0x401ffff <0x23000000,0x1ffffff> . . . rman_reserve_resource: tried 0x22ffffff <0x23000000,0x1ffffff> considering [0x23000000, 0x25ffffff] region is allocated considering [0x26000000, 0x28ffffff] s->r_start (0x26000000) + count - 1> end (0x24ffffff) no unshared regions found rman_reserve_resource: request: [0x23000000, = 0x24ffffff], length 0x2000000, flags 100, device pcib0 NULL list head could not find a region pcib0: could not allocate memory. device_attach: pcib0 attach returned 6 pcib0: on acpi0 pcib0: Bus is cache-coherent pcib0: ECAM for bus 0-31 at mem 20000000-21ffffff rman_reserve_resource: request: [0x20000000, = 0x21ffffff], length 0x2000000, flags 100, device pcib0 rman_reserve_resource: trying 0x401ffff <0x20000000,0x1ffffff> . . . rman_reserve_resource: tried 0x1fffffff <0x20000000,0x1ffffff> considering [0x20000000, 0x22ffffff] region is allocated considering [0x23000000, 0x25ffffff] s->r_start (0x23000000) + count - 1> end (0x21ffffff) no unshared regions found rman_reserve_resource: request: [0x20000000, = 0x21ffffff], length 0x2000000, flags 100, device pcib0 NULL list head could not find a region pcib0: could not allocate memory. device_attach: pcib0 attach returned 6 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Jan 31 10:56:22 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ykt9v2Yz9z5mNLH for ; Fri, 31 Jan 2025 10:56:35 +0000 (UTC) (envelope-from bounce.jkfe5q7d2qfov37=10b6vuerwuip=48k0xxw3wdneiq@em790814.fubar.geek.nz) Received: from e3i188.smtp2go.com (e3i188.smtp2go.com [158.120.84.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ykt9t5n6tz4HjL for ; Fri, 31 Jan 2025 10:56:33 +0000 (UTC) (envelope-from bounce.jkfe5q7d2qfov37=10b6vuerwuip=48k0xxw3wdneiq@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtpservice.net; i=@smtpservice.net; q=dns/txt; s=a1-4; t=1738320990; h=feedback-id : x-smtpcorp-track : date : message-id : to : subject : from : reply-to : sender : list-unsubscribe : list-unsubscribe-post; bh=94AmNzJHv/+AaCfNxYMV11GoUEjLu9Rwq8TJrchQUDY=; b=KLo4ZxAs7ATSK1XH1vmxWIU/v6PBDAIo7fccFbflgUZhwd6HOM5ezU4qaZ6qTgxV0Lfop Ogt1i+rVaiqRKVGcLxplaeznq1h/HLjOWpuFrXasooFcmQOalpnBuudtedZgVKYsr6tdMxv UliBSVhRoTuBC1geXpm1USrVSaX8ApBJ7DqXI6VitVYxEjxZ5AslNBQurSj1UQ+3G7Oj/Ea 5p+ajLIUUiRCt7kn6Zs0RKIE0xzPfhJG0WWDdH1I7HuSDUoKOdoiVwYMcA96u0bIA06QBpU +N2HY1ygcX6aLpyGHgNtBN0xszxt9jVTsB/BWswIBKfWp1Pqan/SYVoF6vsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1738320990; h=from : subject : to : message-id : date; bh=94AmNzJHv/+AaCfNxYMV11GoUEjLu9Rwq8TJrchQUDY=; b=XUyO/aUauzcWy7stSVpasLi6AFoknSZrXRo3q0hZSprKReWSm0c3DCmRPFHX4XtUQZgir Ir2Awerfoylx3VouEvhPF3+P17P37kZOXNoG90c2Rk9Xq+tk6y9t4U80zZ6J41DEmt3XWeT 88wK1MRURiFqCCYOQLi3VA1fSgcsqDPT5r+NqcEloiBvixrG3QYkcTXZBuVATBK85j3jRRB jEVJMSV9azypFlNKjoKLJp2mns1KGb8BwkrHreZLCNOQagvUMFfD8bLMU5fuBaJf+Dh2Itd 10NaJdbI/3UhyDxHOqYehgx79Jg7AvyZNgM9cMs13b4WFmd0iOPCthG2CqSg== Received: from [10.99.243.232] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97.1-S2G) (envelope-from ) id 1tdohG-FnQW0hPqJ6G-l9QI; Fri, 31 Jan 2025 10:56:26 +0000 Received: from webmail.fubar.geek.nz (unknown [IPv6:2a01:4f8:c010:8044::1]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 08987434B2; Fri, 31 Jan 2025 10:56:23 +0000 (UTC) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Date: Fri, 31 Jan 2025 10:56:22 +0000 From: Andrew Turner To: FUKAUMI Naoki Cc: FreeBSD ARM List , Warner Losh , Mark Millard Subject: Re: Radxa Orion O6 In-Reply-To: <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> References: <1B4F62E3-A269-4611-B9ED-1A72298FFC85@yahoo.com> <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> Message-ID: <9223327d465698d55456d94b5bb0f165@fubar.geek.nz> X-Sender: andrew@fubar.geek.nz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 790814m:790814amQcrys:790814sUhNOnlKVb X-smtpcorp-track: nPWiN5scBKGm.qDK34TFM6YxS.ccfeBw7wmVY X-Rspamd-Queue-Id: 4Ykt9t5n6tz4HjL X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:158.120.84.0/22, country:US] On 2025-01-30 14:45, FUKAUMI Naoki wrote: > Hi Andrew, > > On 1/30/25 23:14, Andrew Turner wrote: >>>>> PCIe is not working yet. Any idea? >>>> >>>> I suspect there is a conflict where two devices both try to allocate >>>> the same memory resource. >>>> >>>> Can you try booting with “debug.rman_debug=1” set from the loader >>>> prompt? It will print a lot of logging about different memory and >>>> interrupt resources being allocated so you will likely need >>>> something to save the output, e.g. reading the serial output under >>>> script. It’s will also likely be too much for the list, so you can >>>> email it to me directly. >>> >>> I uploaded dmesg here: >>> >>> https://drive.google.com/file/d/1HzZFFIaBu2gyDHF7oPnNLuzU_CBMF5dC/ >>> view?usp=sharing >> >> Hello, >> >> The follow lines indicate another device has reserved the PCIe memory, >> however the details of which device has the reservation has been lost >> from the top of output. >> >> considering [0x2c000000, 0x2fffffff] >> region is allocated >> >> Is it possible to get the data from earlier in the boot? > > Sorry, I didn't realise the log was incomplete. > > This should be complete... > > https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/view?usp=sharing I found the DSDT you posted to the NetBSD list and think I now know the issue. The memory range in the MCFG table is not the first entry in the _CRS table for the PCI root. FreeBSD has what appears to be a bug where it assumes this memory range is first in the list _CRS returns, rather than searching for it. I also found why the ram0 driver is failing to attach. The NPU0 device is trying to reserve memory in the range 0x90000000-0x92000000. I would expect this memory is included in the memory map provided by UEFI so the kernel will ignore it. Andrew From nobody Fri Jan 31 13:16:19 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YkxHV479Pz5m0H7 for ; Fri, 31 Jan 2025 13:16:38 +0000 (UTC) (envelope-from naoki@radxa.com) Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (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 4YkxHT29vhz3K96 for ; Fri, 31 Jan 2025 13:16:36 +0000 (UTC) (envelope-from naoki@radxa.com) Authentication-Results: mx1.freebsd.org; none X-QQ-mid: bizesmtpip4t1738329381t2dpv3u X-QQ-Originating-IP: SmEXzdfr2PpZ8pId0dUq72j3ZFOV1rjXwmNpu87D3S4= Received: from [IPV6:240f:10b:7440:1:ffbf:1ecd ( [localhost]) by bizesmtp.qq.com (ESMTP) with id ; Fri, 31 Jan 2025 21:16:19 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 1049990870237400388 Message-ID: <1E5293CB24E6B605+f49a47e6-6598-45a5-a605-d57fcb06f743@radxa.com> Date: Fri, 31 Jan 2025 22:16:19 +0900 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Radxa Orion O6 To: Andrew Turner Cc: FreeBSD ARM List , Warner Losh , Mark Millard References: <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> <9223327d465698d55456d94b5bb0f165@fubar.geek.nz> Content-Language: en-US From: FUKAUMI Naoki In-Reply-To: <9223327d465698d55456d94b5bb0f165@fubar.geek.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtpip:radxa.com:qybglogicsvrgz:qybglogicsvrgz8a-1 X-QQ-XMAILINFO: MQ+wLuVvI2LQnC6afJ9YBx5vSf73kRsjVSjH+UyZm1yWdRUTwd0xOg1Y P3W8JglyXvfRQoaB46gSwOk8hfsq7eIqnWpSuR4fcD6ALeP/o69sZN2JU8cz8bmAspmAavN jUE93kw15NM9FWcEBsjNlShQ2W6ibAtoNPGhGcuXx997joKnYwAchnLS1AkK/XJRorlhOKA Ao8I2CUFQKtnpcqqO+s1UcMID8kaxqNKkuKWR8mLjw6tQBorLQuyrEH1bWClgMRcXmOzaD3 EGRhhQ0qvBPVAYZd9MBYYmtde4GtFB/qH5VrE7n2fxNYfsWqLCbTRGywr40kgwIkGV2yc/P gGUQUPw3yIt7Z7dy4oqHmpO53QSqjrK/dxiqt6olPF4Py9Qblvz5I++3UyN4mIqtGBWQkDy qBzSCcOiLL61ElmtCCZ7wF3Rrrl+EP3AFNNU5C0kbjgpIlsctuvlv83JgjW/9682PFVHk4t IROLCO4J79TfZqIQ/Fj7Mk/xIP6rHJyX6ZD34tvLVGewYJMrJxgKSpr9ZQC1GoDETnvRNFe BKhr8eCq4KBQSNplEaQfnyW5en4zVq4/mtn4uQ6XQoVxaMz8Nsnj822DGUE9g6PhVg2WZ6+ uAiYRAHofaa/s+XuTHwDLFQhx6a58Wt3ryFNhKqI7GNFfNsf/bGfHnewctm8gnMi6wILPe4 b90Q9HFuLJ8KaxI34/m/uFOTCQNEc4NjD0HtICtDbi2PcorjMHHEcWlqSgLnpg4qfhX2Mqn c/nWSflqsOi9Heo/nDvLAuYRSykeBC0bdwmEgPr2CdnVH2hj47SpquOyBw1YCTAcTZi/wwV R35kgpSfdGuqnICkO300j3s2X2e2NAUmq8afuD6d9DMnsBavl+xs48EbQH6WDlIdwkZ3aZV O/rYcRtdYetjf0opNYAVgjPi1izR51qXRsXVEVrCnvq0er1XYChtNLxzp/QZrDV79OAdMLI i57edgwuEcOL0ixQrvA8cyapeTbsLY8zUbhwDxTOVGA18ig== X-QQ-XMRINFO: NyFYKkN4Ny6FSmKK/uo/jdU= X-QQ-RECHKSPAM: 0 X-Rspamd-Queue-Id: 4YkxHT29vhz3K96 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:54.206.0.0/17, country:US] Hi Andrew, On 1/31/25 19:56, Andrew Turner wrote: >> https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/ >> view?usp=sharing > > I found the DSDT you posted to the NetBSD list and think I now know the > issue. The memory range in the MCFG table is not the first entry in the > _CRS table for the PCI root. FreeBSD has what appears to be a bug where > it assumes this memory range is first in the list _CRS returns, rather > than searching for it. > > I also found why the ram0 driver is failing to attach. The NPU0 device > is trying to reserve memory in the range 0x90000000-0x92000000. I would > expect this memory is included in the memory map provided by UEFI so the > kernel will ignore it. Sorry for the scattered information! Thank you for the detailed analysis! By the way, what does the ram0 driver do? Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. From nobody Fri Jan 31 13:47:02 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ykxym6rFpz5m4nw for ; Fri, 31 Jan 2025 13:47:12 +0000 (UTC) (envelope-from bounce.29t7tysi6d6mpf0=8436mnv9h33u=8cbjg98zvnofw2@em790814.fubar.geek.nz) Received: from e3i188.smtp2go.com (e3i188.smtp2go.com [158.120.84.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ykxyl6Zmvz3PV7 for ; Fri, 31 Jan 2025 13:47:11 +0000 (UTC) (envelope-from bounce.29t7tysi6d6mpf0=8436mnv9h33u=8cbjg98zvnofw2@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smtpservice.net; i=@smtpservice.net; q=dns/txt; s=a1-4; t=1738331229; h=feedback-id : x-smtpcorp-track : date : message-id : to : subject : from : reply-to : sender : list-unsubscribe : list-unsubscribe-post; bh=/WYqKNOWGToVtLvkH+SMRFy6PupZUddB2OiFGdCCVDI=; b=ChyZSiY0fcjRGQ3N+6FgddxP3Fz13277qv5vlZxICHVb9y+zYnDNUWqmYT9K3pHxB4rWX zbm3aXGGDENGU8SyYoxv2CvZXQGjtnoXd8F05OYdhZOetas9a1h/Odg/plPpM5zOo0yiOqZ +lYvayiNytc3Aacb3GskMUe2lxwNSgtVG3qfxPTCVWroEUG+ad4nT79kusCOoz4eJBBkCu+ ijVEhBmWIOPDJ7dT1mVB47VhCw6XXABWsDQaOhjRG3LVvRKdKkwR94Gt495UQbyTGoI64kQ mkvPf1aVQEcr22c64m5aH0m3Zb4Hdz4jdnajAwHVtiYaOQo6eZW4GOAFbosg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1738331229; h=from : subject : to : message-id : date; bh=/WYqKNOWGToVtLvkH+SMRFy6PupZUddB2OiFGdCCVDI=; b=gVMUu4YWDtPkle15UWd3GaqDwXA+Kb0fX2mZelxEyOacMskSG7SeQKMqS/M3x/qd+CZkw gMyj9C5yU57yYT2ZZGq/w0LSwEZ0CdnnmVPb5Pts9dRoEj7d/Gl7hQbjQefAlc/ruomOTY2 4c3ZzQ2DcVkIbEVCu+TF4dO9q6/dpGW8xkfBog8mmhmXDI521i9j2arQ+oOoe1r8c90X8Yt kowLJ54ixNvZ+JDr/jumoUx4sMoCK6Wqh+4kaS8chUUpUiVU9ILpTPdx0rkv5UfirWEXpSf vhnnhXkvuW+ct9Kvpas3dEAltvrR9G9f5YeS9DkSqQEd4eah6xJRFNYCQtTw== Received: from [10.99.243.232] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.97.1-S2G) (envelope-from ) id 1tdrMN-4o5NDgrrDg7-le8X; Fri, 31 Jan 2025 13:47:03 +0000 Received: from webmail.fubar.geek.nz (unknown [IPv6:2a01:4f8:c010:8044::1]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 4D50943574; Fri, 31 Jan 2025 13:47:02 +0000 (UTC) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Date: Fri, 31 Jan 2025 13:47:02 +0000 From: Andrew Turner To: FUKAUMI Naoki Cc: FreeBSD ARM List , Warner Losh , Mark Millard Subject: Re: Radxa Orion O6 In-Reply-To: <1E5293CB24E6B605+f49a47e6-6598-45a5-a605-d57fcb06f743@radxa.com> References: <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> <9223327d465698d55456d94b5bb0f165@fubar.geek.nz> <1E5293CB24E6B605+f49a47e6-6598-45a5-a605-d57fcb06f743@radxa.com> Message-ID: <706b0e872932198c6f725d87f0541e67@fubar.geek.nz> X-Sender: andrew@fubar.geek.nz Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Report-Abuse: Please forward a copy of this message, including all headers, to Feedback-ID: 790814m:790814amQcrys:790814sUhNOnlKVb X-smtpcorp-track: 327uvjUAKmCh.pHmpVlauUpHn.lB0ihw-Ffjx X-Rspamd-Queue-Id: 4Ykxyl6Zmvz3PV7 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:158.120.84.0/22, country:US] On 2025-01-31 13:16, FUKAUMI Naoki wrote: > Hi Andrew, > > On 1/31/25 19:56, Andrew Turner wrote: >>> https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/ >>> view?usp=sharing >> >> I found the DSDT you posted to the NetBSD list and think I now know >> the issue. The memory range in the MCFG table is not the first entry >> in the _CRS table for the PCI root. FreeBSD has what appears to be a >> bug where it assumes this memory range is first in the list _CRS >> returns, rather than searching for it. >> >> I also found why the ram0 driver is failing to attach. The NPU0 device >> is trying to reserve memory in the range 0x90000000-0x92000000. I >> would expect this memory is included in the memory map provided by >> UEFI so the kernel will ignore it. > > Sorry for the scattered information! > Thank you for the detailed analysis! > > By the way, what does the ram0 driver do? It's to hold the memory resources of the ram so other drivers don't try to use them. See the commit message in [1] where it was added. I think we could move it earlier in the boot so it holds the resource before the acpi device is attached. This would stop the panic, and block drivers from using memory that may have already been allocated by the system. Andrew [1] https://github.com/freebsd/freebsd-src/commit/e6cf1a0826c9d7f229e41224ec7b783501636528 From nobody Fri Jan 31 14:34:33 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ykz1f6KQQz5mCGF for ; Fri, 31 Jan 2025 14:34:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ykz1f2dCPz3WDy for ; Fri, 31 Jan 2025 14:34:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2ee86a1a92dso2859941a91.1 for ; Fri, 31 Jan 2025 06:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1738334085; x=1738938885; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zyWFcUvM+ZXfPZdUbkDI7/KHlFDBNmtCzBG71GhGSzQ=; b=xixO6D51yejxNlyUmFrXTdpNYQm+5PItZRtyu28Fr6WQ+zIXofGLzeRFagSRnhK7w5 Xpnbm6aFYfX+zoqJC+OImAkvQhKNGmK//oesm/9FhE/1epGgPbmrG3Ea3CZKV6DaHJOl 0XReyYRWxqHyUwigWTjsea0amK6A4WS1i0rNvQ32YT3bZtEb/X302GCmgXvwbZb5kcuO R5bYyu59nRiJHFctZPvtquHJ9lqXoXUqAEKZIdmjsRCGarkecRylqL2dcccnEMRCNptb aJ+9Ez+kebHQbE8brs1pZmpVVMsnS1JTnncYK0ra8xpp6yFK/g/FP+8hxIh4u4avqOAB lJJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738334085; x=1738938885; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zyWFcUvM+ZXfPZdUbkDI7/KHlFDBNmtCzBG71GhGSzQ=; b=B6e5cYzg8A+p0Nc2BAdDpj8o4IBPRgE5HvpcDH1rMRd2YdfIxrNTLgS/ZfkmldF8RT Aw5apAKPx3PQuKfBw6kP2lto2ocmS14to11MistVdEvvg0yQbCa6w9e4rKATGo9JCVu1 Tkh1wEtXq5oXC5SA8wydN5C+BZLeDEkbodAEw5blXziKRvPFHrx88mn7aa7bLnoO6rxV 2ZVnTjktTgPgIvo3DYY47f697js4ZE064pxPy/Mfyme/qH/1TVsQiAmIQeFbTc5d4RUE S1y3Ej0znZDArV1HLafRCBabVjJprmlmtQZyKBOGfBWonDZHM2x+fhMOxkcpENQC6qjF hqxA== X-Forwarded-Encrypted: i=1; AJvYcCUVyh+fc+RPshrdxIX2P9smkqEDQACnrylUe33O3UKtIGlc8JQqO22Fj2EQs/LJRSkVTct6zspAtMq9Ww==@freebsd.org X-Gm-Message-State: AOJu0YzmKcinsYFcHUVYChoP8knZUNyBYNze9MBBspU3liQevjHFZoHI QVD0vg2LLcUffyB84HzDybpCoPLYYJYT4Ug4/794noxu678qVsu6n/1RKV5t9IZzjdPiIlGsUV4 HOX2gcpdztEmHL6iF6UjKmHzxPGfO65S6UqdZOusi97hQKxvCSwY= X-Gm-Gg: ASbGncvP2O98RqoAKL/ECEBf9YN1HzLnjCY+0Tn4YAZY0mQAO5Ibaj4FHhN+rjWd8mi LTH8Rx4S0IELRUSpCfhG8x4BO6wrSg0T0O1TKmI86MpbpKyKQdbnGFelVviNevtZ/VV2ByTPi X-Google-Smtp-Source: AGHT+IFtkSY5DEpnkKwgqSzA7QsOwkrk/XrV9pd6PtXv/s9IaQKkus8Nj4zOnMCAfJ0xksH8XIrqCAgepmimjuNGys0= X-Received: by 2002:a17:90b:4ed0:b0:2ee:9b09:7d3d with SMTP id 98e67ed59e1d1-2f83ac0a3c9mr16385225a91.19.1738334084672; Fri, 31 Jan 2025 06:34:44 -0800 (PST) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 References: <6591E59D-4E91-4325-8A77-46E182303927@yahoo.com> <9581F4025795F7C5+10590950-836c-4d9c-9c05-43b25b880e08@radxa.com> <9EDB5AF9-B11B-474E-8541-6C10098574CE@yahoo.com> <289A1E5B1EB26246+02035adf-93b2-432e-aac7-8b9135ff600e@radxa.com> <77D55F7BE57B9E43+9557bea2-4356-4525-bb9e-c4ea885895f5@radxa.com> <066b43d33f04acffe617eebdfc1384bb@fubar.geek.nz> <5784648BD0765DC0+5569efd0-5ca1-4f4a-be98-60b66b793561@radxa.com> <4E031287-C807-44FA-9CC1-9D39C4CA258F@fubar.geek.nz> <76BFF5FCC5391448+61004119-03e2-47f7-bba3-84f6cb82d4c8@radxa.com> <7391e418a4f0f7cfae645934321cea41@fubar.geek.nz> <12D0A72A07D8A019+83c55ce0-3811-437d-aed2-6a753938e8a3@radxa.com> <9223327d465698d55456d94b5bb0f165@fubar.geek.nz> <1E5293CB24E6B605+f49a47e6-6598-45a5-a605-d57fcb06f743@radxa.com> <706b0e872932198c6f725d87f0541e67@fubar.geek.nz> In-Reply-To: <706b0e872932198c6f725d87f0541e67@fubar.geek.nz> From: Warner Losh Date: Fri, 31 Jan 2025 07:34:33 -0700 X-Gm-Features: AWEUYZm5PHjut1OxF1wjm0FU3qbNOKbsz9lWp81z0VCOnOWElmHJAfZkg1SgGlA Message-ID: Subject: Re: Radxa Orion O6 To: Andrew Turner Cc: FUKAUMI Naoki , FreeBSD ARM List , Mark Millard Content-Type: multipart/alternative; boundary="0000000000009e4aa5062d017118" X-Rspamd-Queue-Id: 4Ykz1f2dCPz3WDy X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --0000000000009e4aa5062d017118 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 31, 2025 at 6:47=E2=80=AFAM Andrew Turner wrote: > On 2025-01-31 13:16, FUKAUMI Naoki wrote: > > Hi Andrew, > > > > On 1/31/25 19:56, Andrew Turner wrote: > >>> https://drive.google.com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/ > >>> view?usp=3Dsharing > >> > >> I found the DSDT you posted to the NetBSD list and think I now know > >> the issue. The memory range in the MCFG table is not the first entry > >> in the _CRS table for the PCI root. FreeBSD has what appears to be a > >> bug where it assumes this memory range is first in the list _CRS > >> returns, rather than searching for it. > >> > >> I also found why the ram0 driver is failing to attach. The NPU0 device > >> is trying to reserve memory in the range 0x90000000-0x92000000. I > >> would expect this memory is included in the memory map provided by > >> UEFI so the kernel will ignore it. > > > > Sorry for the scattered information! > > Thank you for the detailed analysis! > > > > By the way, what does the ram0 driver do? > > It's to hold the memory resources of the ram so other drivers don't try > to use them. See the commit message in [1] where it was added. > > I think we could move it earlier in the boot so it holds the resource > before the acpi device is attached. This would stop the panic, and block > drivers from using memory that may have already been allocated by the > system > That was my first thought when I saw how late the panic was. We should be attaching ram0 almost first thing after nexus. I wanted to confirm the conflict before trying to move it, and then $WORK got in the way. Thanks for the confirmation and tracking down what the conflict is. And I agree: if that device is expected to be used by the system and has ram reserved for it for that purpose, it should have a different UEFI memory type perhaps. Warner > Andrew > > [1] > > https://github.com/freebsd/freebsd-src/commit/e6cf1a0826c9d7f229e41224ec7= b783501636528 > --0000000000009e4aa5062d017118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jan 31,= 2025 at 6:47=E2=80=AFAM Andrew Turner <andrew@fubar.geek.nz> wrote:
On 2025-01-31 13:16, FUKAUMI Naoki wrote:
> Hi Andrew,
>
> On 1/31/25 19:56, Andrew Turner wrote:
>>> https://drive.google.= com/file/d/1PKxfS7BWK4Vo41tw7YrYB1_LfHzLCN-A/
>>> view?usp=3Dsharing
>>
>> I found the DSDT you posted to the NetBSD list and think I now kno= w
>> the issue. The memory range in the MCFG table is not the first ent= ry
>> in the _CRS table for the PCI root. FreeBSD has what appears to be= a
>> bug where it assumes this memory range is first in the list _CRS <= br> >> returns, rather than searching for it.
>>
>> I also found why the ram0 driver is failing to attach. The NPU0 de= vice
>> is trying to reserve memory in the range 0x90000000-0x92000000. I =
>> would expect this memory is included in the memory map provided by=
>> UEFI so the kernel will ignore it.
>
> Sorry for the scattered information!
> Thank you for the detailed analysis!
>
> By the way, what does the ram0 driver do?

It's to hold the memory resources of the ram so other drivers don't= try
to use them. See the commit message in [1] where it was added.

I think we could move it earlier in the boot so it holds the resource
before the acpi device is attached. This would stop the panic, and block drivers from using memory that may have already been allocated by the
system

That was my first thought when I= saw how late the panic was. We should be
attaching ram0 almost f= irst thing after nexus. I wanted to confirm the conflict
before t= rying to move it, and then $WORK got in the way. Thanks for the confirmatio= n
and tracking down what the conflict is. And I agree: if that de= vice is expected to
be used by the system and has ram reserved fo= r it for that purpose, it should have
a different UEFI memory typ= e perhaps.

Warner
=C2=A0
Andrew

[1]
https://github= .com/freebsd/freebsd-src/commit/e6cf1a0826c9d7f229e41224ec7b783501636528
--0000000000009e4aa5062d017118-- From nobody Sun Feb 2 09:56:22 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ym4lY6vNRz5mCF4 for ; Sun, 02 Feb 2025 09:56:25 +0000 (UTC) (envelope-from SRS0=mzUg=UZ=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ym4lY0JLqz3N7c for ; Sun, 02 Feb 2025 09:56:24 +0000 (UTC) (envelope-from SRS0=mzUg=UZ=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=DvoXbgCH; spf=pass (mx1.freebsd.org: domain of "SRS0=mzUg=UZ=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=mzUg=UZ=klop.ws=ronald-lists@realworks.nl"; dmarc=pass (policy=quarantine) header.from=klop.ws Date: Sun, 2 Feb 2025 10:56:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1738490182; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=wnQPkWRLPGKifEX9q5kZcPKnaSN1jksWwUVO8kWzTx8=; b=DvoXbgCHF3bXHCDB5C+p/+OlfoHtL3W9FuPzEPkUTsvWn4H9dWBWOXtz7ryvbZZc3BKZUW zh/9k/AIcmbGGtkSrhq4/p1HtDX5uZjYG+TX9JO+IhB7S3XjHbpHz8aG65fSZu49LIhpMn aT1vUz8nCFPzRJ0jecWiuNSWmK1m/X5vZBb+K33r6N9fwvyWpsN2khTgbR02UGXf4vinwO 1cUXSHqZugAgHco/DG7oDCRakI+ri1n5/NDm6znI/ip16aszG3RrZ5gtcB2FMDLp7LfR0r EcE9VJltNYps/2FX/9LQ+/YTjOutszyxlMrhgNmrRDD/w6f8v1AqfnVkiOBsJg== From: Ronald Klop To: freebsd-arm@freebsd.org Message-ID: <1209610970.15723.1738490182716@localhost> Subject: RPI5 16GB panic on boot List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15722_1804235169.1738490182684" X-Mailer: Realworks (736.122) Importance: Normal X-Priority: 3 (Normal) X-Spamd-Result: default: False [-4.09 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[194.109.157.24:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=mzUg=UZ=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=mzUg=UZ=klop.ws=ronald-lists@realworks.nl]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; HAS_X_PRIO_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Ym4lY0JLqz3N7c ------=_Part_15722_1804235169.1738490182684 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, All my goodies are in and connected so I could capture the logs via serial easily. The RPI5 16GB starts booting the kernel and then panics very early in the process. The full serial output can be found here: https://wiki.freebsd.org/RonaldKlop/Raspberry%20Pi%205%2016GB. The TL;DR is: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Loading splash ok No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! EFI framebuffer information: addr, size 0x3f600000, 0x5eec00 dimensions 1440 x 1080 stride 1440 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 x0: 0xffff000000fcae40 x1: 0x0000000000000001 x2: 0x0000000000000019 x3: 0x0000000000000064 x4: 0x0000000000000076 x5: 0x0000000000000000 x6: 0x1700000000000000 x7: 0x0000000000000017 x8: 0xffff000000defb20 x9: 0xffff000001044000 x10: 0xffff00000103f000 x11: 0x0101010101010101 x12: 0x000000000000003b x13: 0x0000000000000001 x14: 0x1700000000000000 x15: 0x0000000000000010 x16: 0x00000000000000b4 x17: 0x0000000000000000 x18: 0xffff000000def880 x19: 0xffff000000fcae40 x20: 0xffff000000dec000 x21: 0xffff00000114b800 x22: 0x0000000000000000 x23: 0x0000000038070018 x24: 0xffff000001152000 x25: 0xffffa00000000000 x26: 0xffffa0003b5d0018 x27: 0x000000003095b000 x28: 0xffff00000114b000 x29: 0xffff000000defaa0 sp: 0xffff000000def880 lr: 0xffff0000008687a8 elr: 0xffff0000008687bc spsr: 0x00000000804002c9 far: 0xe1f35e376ecbf7f7 esr: 0x00000000be000011 panic: Unhandled System Error cpuid = 0 time = 1 KDB: stack backtrace: #0 0xffff000000505fc0 at ??+0 #1 0xffff0000004b6cec at ??+0 #2 0xffff0000004b6b48 at ??+0 #3 0xffff000000885d00 at ??+0 #4 0xffff00000085b158 at ??+0 Uptime: 1s Rebooting... cpu_reset failed Any thoughts about what I could try to fix this? Regards, Ronald. ------=_Part_15722_1804235169.1738490182684 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

All my goodies are in and connected so I could capture the logs via serial easily.

The RPI5 16GB starts booting the kernel and then panics very early in the process.

The full serial output can be found here: https://wiki.freebsd.org/RonaldKlop/Raspberry%20Pi%205%2016GB.

The TL;DR is: 
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Loading splash ok
No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!
EFI framebuffer information:
addr, size     0x3f600000, 0x5eec00
dimensions     1440 x 1080
stride         1440
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
  x0: 0xffff000000fcae40
  x1: 0x0000000000000001
  x2: 0x0000000000000019
  x3: 0x0000000000000064
  x4: 0x0000000000000076
  x5: 0x0000000000000000
  x6: 0x1700000000000000
  x7: 0x0000000000000017
  x8: 0xffff000000defb20
  x9: 0xffff000001044000
 x10: 0xffff00000103f000
 x11: 0x0101010101010101
 x12: 0x000000000000003b
 x13: 0x0000000000000001
 x14: 0x1700000000000000
 x15: 0x0000000000000010
 x16: 0x00000000000000b4
 x17: 0x0000000000000000
 x18: 0xffff000000def880
 x19: 0xffff000000fcae40
 x20: 0xffff000000dec000
 x21: 0xffff00000114b800
 x22: 0x0000000000000000
 x23: 0x0000000038070018
 x24: 0xffff000001152000
 x25: 0xffffa00000000000
 x26: 0xffffa0003b5d0018
 x27: 0x000000003095b000
 x28: 0xffff00000114b000
 x29: 0xffff000000defaa0
  sp: 0xffff000000def880
  lr: 0xffff0000008687a8
 elr: 0xffff0000008687bc
spsr: 0x00000000804002c9
 far: 0xe1f35e376ecbf7f7
 esr: 0x00000000be000011
panic: Unhandled System Error
cpuid = 0
time = 1
KDB: stack backtrace:
#0 0xffff000000505fc0 at ??+0
#1 0xffff0000004b6cec at ??+0
#2 0xffff0000004b6b48 at ??+0
#3 0xffff000000885d00 at ??+0
#4 0xffff00000085b158 at ??+0
Uptime: 1s
Rebooting...
cpu_reset failed
Any thoughts about what I could try to fix this?

Regards,
Ronald.
------=_Part_15722_1804235169.1738490182684-- From nobody Sun Feb 2 17:06:08 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YmGHh28kNz5mSMf for ; Sun, 02 Feb 2025 17:06:24 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YmGHg6spVz3msl for ; Sun, 02 Feb 2025 17:06:23 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-43634b570c1so25762725e9.0 for ; Sun, 02 Feb 2025 09:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1738515982; x=1739120782; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:date:in-reply-to :from:subject:mime-version:from:to:cc:subject:date:message-id :reply-to; bh=1R9SAKk58zRkjEhFxzdoBDwh1bHNqMjGUtCKRnXS+mY=; b=euA7yT5oJb7vHzwKADUV3pAmBkdBu84pjWujr+PSxNvZJ9AELFoZPNJubmbHKyUtkr wO3QgHBbnQOwpFBHYx2oHCYs5liHz0EjL8/6S+B8LPfDGGFuqihODezL0Bnn0Xgunk0R SK/HT0HcWCoBsTUxSxG0VYcwP4g13LbBLKob/yoamDjwKMp/7n+a3kTw5ISp2rYg4fOM aZktcNRnJHduGIaapxVrMha4kl1YAg6q1zNAviQPOBmZsJuvudLbB6AU8JX4PWHCwpIV b1ZKOq1dIKe1JWJVwW8AMVIgKAzZoihB2Ee2otGrPW8idID9J5DuvL7MKUYWqqJclMiE qnKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738515982; x=1739120782; h=to:references:message-id:content-transfer-encoding:date:in-reply-to :from:subject:mime-version:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=1R9SAKk58zRkjEhFxzdoBDwh1bHNqMjGUtCKRnXS+mY=; b=RVZVxyaoiwCQi6QNGFnnDz1tSrY3XC2K+are1dploQV5WAE+BZ2aJU/lf1BY/krjgi pVQbQ1jCacbOW+fg/inNc+c0umyFNO0V+/XwjIGjlrz6QlkllH4TGyWOeYf0iv30RUap IXY6cjNsJjLOMzNBXLFBIs22/91WeGMCXJbO23e+qisd9CbU+z3yOAojI7Jsd+SL01C2 I0rGW4vEEta1VHKwyAuCXaR8QIBLU3oYjrX0IO4OCD0G4sdx3tIuKRaVzMgKs53nsydt DCW+HkSRz+4G51wGck7/pHl7xkyj545uxS0Tz+OcNZyfxPVPGHqDbxDbGqRTZJXVPR5s xa8w== X-Forwarded-Encrypted: i=1; AJvYcCVTxdAOPMES7Sb5+soDziqvI/GGjDF9j+KTGCY6ReVnQVQjl4c+HtlZqRqsSnOwtk30lzf+xjhKjYU3XQ==@freebsd.org X-Gm-Message-State: AOJu0YzvvrZOUR9EoghiU5uVjIMVUjjE/yOxeYfn8Elqp3g4XDtiBAoC lZzBJDOVCe70DJLYeOHcrX64/RfbP+B2F7DrHf0yNGELrmw3ZChZQCxsFA== X-Gm-Gg: ASbGncuVLJZSPJ620jaO8yB7vYyiq1F3cZjXt72SgcCBFTLcOCdKFvxM6+2KlsDY/my O/6ym1yncyVGX1oejvcyRgTIfCEs1/xfiowsk4c28R4UmMRePImDyKeJBlYutizcCFYCZwZOBcQ jrAYe1Dyapl25c3krDKLFIp0pC1rqpFS6wpLv8er/j7d6SY9Z2jTm9qrfQ5Fxzxy3i37RTHYaSB 9nBdiQZMFLG3y1Le9K0jTmRmsCDskA6hMWQ1/mddFYuDWez1fOCJCPlf3mb/ua0qjMJ+z/aNWIS wEIVUouSsj7Sc6AeTBA/YU4IgTGAok6RIzEVU6jMEJEmD7EmDmRmB+2bacRWmz6GW99kmwCoWt2 ZAvZjc4AvNKa8BoZAguhZ X-Google-Smtp-Source: AGHT+IECIpib1WsEp4vP9ooTUv2lGb5dyaAZ3eA7voNrr1LofhJxI8nDOir9kpLPXpEKsHdij8jTaQ== X-Received: by 2002:a05:600c:3c89:b0:436:fbe0:cebe with SMTP id 5b1f17b1804b1-438dc40fd42mr171742055e9.30.1738515981355; Sun, 02 Feb 2025 09:06:21 -0800 (PST) Received: from smtpclient.apple (dynamic-046-114-115-031.46.114.pool.telefonica.de. [46.114.115.31]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-438dcc2ef08sm163026315e9.22.2025.02.02.09.06.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Feb 2025 09:06:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.300.87.4.3\)) Subject: you`ll have to hack u-boot&kernel drivers Re: RPI5 16GB panic on boot From: =?utf-8?Q?Klaus_K=C3=BCchemann?= X-Priority: 3 (Normal) In-Reply-To: <1209610970.15723.1738490182716@localhost> Date: Sun, 2 Feb 2025 18:06:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C65C3F9-50D3-4B27-BB72-6D1B579AF83A@googlemail.com> References: <1209610970.15723.1738490182716@localhost> To: Ronald Klop , freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3826.300.87.4.3) X-Rspamd-Queue-Id: 4YmGHg6spVz3msl X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] > Am 02.02.2025 um 10:56 schrieb Ronald Klop : >=20 >=20 > No valid device tree blob found! >=20 For FreeBSD go the u-boot fdt-based way ! ( since all existing drivers = rely on that).. A device tree blob( dtb) is a compiled binary which is read in by u-boot = ,=20 While a device tree source( dts) can be compiled into u-boot`kernel = directly=E2=80=A6.=20 Some steps further here. I just show you the things I=E2=80=99ve already = hacked ( in u-boot & fbsd-kernel),=20 Not showing you the things which have to be future-hacked into the = kernel:-), it=E2=80=99ll be a massive hack because e.g because the RP1 chip has = many things hanging behind pcie, I have currently pcie detected in boot but there`s something more to = do/hack regarding DMA=E2=80=A6.. and so further and so on : =E2=80=A6 4.05 dt-match: compatible: brcm,bcm2712 match: brcm,bcm2712=E2=80=A6. =E2=80=A6 4.95 Loading 'bcm2712-rpi-cm5-cm5io.dtb' to 0x00000000 offset = 0x100 5.06 Read bcm2712-rpi-cm5-cm5io.dtb bytes 80587 hnd 0x198b =E2=80=A6 5.84 MESS:00:00:05.184071:0: Loaded overlay =E2=80=9Adwc2=E2=80= =98=E2=80=A6 5.04 Loading 'u-boot.bin' to 0x00000000 offset 0x200000,, 5.39 Read u-boot.bin bytes 694000 hnd 0x148d=E2=80=A6 =E2=80=A6. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94 U-Boot 2025.01 (Jan 19 2025 - 06:10:39 +0100) DRAM: 1020 MiB (effective 4 GiB) RPI: Board rev 0x18 outside known range RPI Unknown model (0xc04180) Core: 25 devices, 12 uclasses, devicetree: board MMC: mmc@fff000: 0, mmc@1100000: 1 Loading Environment from FAT... ** Bad device specification mmc 1 ** In: serial,usbkbd Out: serial,vidconsole Err: serial,vidconsole Net: No ethernet found. starting USB... Bus usb@480000: USB DWC2 scanning bus usb@480000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Cannot persist EFI variables without = system partition ** Booting bootflow '' with efi_mgr Booting: mmc 0 =E2=80=94=E2=80=94=E2=80=94 Consoles: EFI console =20 Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 3.0 (Sat Feb 1 03:46:15 UTC 2025 root@fbsd5pro) Command line arguments: loader.efi Image base: 0x3e54d000 EFI version: 2.100 EFI Firmware: Das U-Boot (rev 8229.256) Console: efi,comconsole (0) Load Path: /\EFI\BOOT\BOOTAA64.EFI Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73= b9-a384-4acc-aeab-82e828f3628b,6d00000004000000)/eMMC(0)/eMMC(0)/HD(1,0x01= ,0,0x800,0x19000) BootCurrent: 0000 BootOrder: 0000[*] BootInfo Path: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73= b9-a384-4acc-aeab-82e828f3628b,6d00000004000000)/eMMC(0)/eMMC(0) Ignoring Boot0000: Only one DP found Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73= b9-a384-4acc-aeab-82e828f3628b,6d00000004000000)/eMMC(0)/eMMC(0)/HD(1,0x01= ,0,0x800,0x19000) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73= b9-a384-4acc-aeab-82e828f3628b,6d00000004000000)/eMMC(0)/eMMC(0)/HD(2,0x01= ,0,0x19800,0x9e6800) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local / =E2=80=94=E2=80=94=E2=80=94=E2=80=94 Loading kernel=E2=80=A6 =E2=80=94 Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x3e6da000. Loading splash ok ---<>--- GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb WARNING: Cannot find freebsd,dts-version property, cannot check DTB = compliance Copyright (c) 1992-2025 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 15.0-CURRENT #3: Sat Feb 1 16:02:48 UTC 2025 root@fbsd5pro:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git = llvmorg-19.1.7-0-gcd708029e0b2) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. real memory =3D 4290248704 (4091 MB) avail memory =3D 4152508416 (3960 MB) Starting CPU 1 (100) Starting CPU 2 (200) Starting CPU 3 (300) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: on ofwbus0 regfix0: on simplebus0 regfix1: on simplebus0 simplebus1: on ofwbus0 ofw_clkbus0: on ofwbus0 =E2=80=94=E2=80=94=E2=80=94 simple_mfd0: mem = 0x7d542000-0x7d542eff on simplebus0 bcm2835_firmware0: on simplebus0 ofw_clkbus1: on bcm2835_firmware0 =E2=80=94 psci0: on ofwbus0 smccc0: on psci0 =E2=80=94=E2=80=94 gic0: mem = 0x107fff9000-0x107fff9fff,0x107fffa000-0x107fffbfff,0x107fffc000-0x107fffd= fff,0x107fffe000-0x107fffffff irq 86 on simplebus1 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 320 =E2=80=94 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0 on usbus1 uhub0: on usbus1 bcm2835_cpufreq0: ARM 1500MHz, Core 500MHz, SDRAM 0MHz, Turbo OFF CPU 0: ARM Cortex-A76 r4p1 affinity: 0 0 Cache Type =3D Instruction Set Attributes 0 =3D = Instruction Set Attributes 1 =3D Instruction Set Attributes 2 =3D <> Processor Features 0 =3D = Processor Features 1 =3D Processor Features 2 =3D <> Memory Model Features 0 =3D = Memory Model Features 1 =3D Memory Model Features 2 =3D <32bit CCIDX,48bit VA,IESB,UAO,CnP> Memory Model Features 3 =3D <> Memory Model Features 4 =3D <> Debug Features 0 =3D Debug Features 1 =3D <> Auxiliary Features 0 =3D <> Auxiliary Features 1 =3D <> AArch32 Instruction Set Attributes 5 =3D = AArch32 Media and VFP Features 0 =3D AArch32 Media and VFP Features 1 =3D CPU 1: ARM Cortex-A76 r4p1 affinity: 1 0 CPU 2: ARM Cortex-A76 r4p1 affinity: 2 0 CPU 3: ARM Cortex-A76 r4p1 affinity: 3 0 gic0: using for IPIs Release APs...Trying to mount root from ufs:/dev/ufs/rootfs [rw].. ---