From nobody Mon Jul 12 01:29:51 2021 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 280E58D49AF for ; Mon, 12 Jul 2021 01:29:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GNR5c5pw2z4nlJ for ; Mon, 12 Jul 2021 01:29:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626053394; bh=ShDYuPlyd9aozUgTXT3cLGRdOArvz9OKQ53/bkQ2MEA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=iPAEPIEM+okVqJbMPO2PhNMwP/p0vsf/AHUgRFIazlIgq6KjhOaU8r+WcgORYM8YUJizgQUv/LA7ADvw6bzQAeqnurjwwzPXaCfDJtDMD8a6lc0ykggS20UrqbgFGMzvQieb/bUlKwa1O0rk8XSgqhpN4c3+gZEAoxoAT0Eb6GKy5j5eQaJhHRRP1rBFcn0UQ0cuMlfUG9Z1HtwWX5v3Rc5MRkHIBI222Bf3/iIFgsVAeN7VuXq3ln0v+GYPGrB2sc7w/G+GTbIkyd+E7FqD+e6fXaza0hiEdnMVjP1RQKToxBNgdNI3BXI4JhaYQCWX89JsjnkCKkkYnIQEF1dWAw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626053394; bh=Dqa6gxNBFD9uapA31u5zgMccmpalszhfW6gqH2eiegX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TYdDm7uAakLPrkKt9RK3InOiLSsKThU8KYRDt95ybNOPu7H5kQW19posBXChLELkSC72DRdvPTwlOskCcZLhafODf7grf+eGh1W2vNbf0xVHkhgxjKXo9vKdtkjqlPORy+Yeg42ZUq5iMgrtiOXQf3h75fKaf1cvYnij9UuxmqmkJajjLNU90AslESGIBiVc/F6Qo8uG/KnXwj5B9UpcU3GDNt2zD47iwN68Pz0Gfq/ZvsJIOfRmxMTVcmDlV/jadzUJfN+TZhqxMbVUbY1FlztCl0PawkTN5HTOxhVWVMtHHcqdc/EoSqKl6vE2FCfX60MYDQM/e+UWioiwmuxczQ== X-YMail-OSG: cRztN2UVM1moq.D8DZMe3mEzWqDxkWWjGsL5HO2W7r8WjsFcwev5zn1i10S8HmA SHqEqFjvqgqb0M1jhuaUECq.DBHayzt2vU7Z8WF8kM9sycqFp2ROBFdh8DeQouATNe0.rYxgIjqP eJBO3zldWB3gVw8cBI7ruckdaM8.5L1BGP9q0seM.ueNcqZFwr3l79x3m9huloSIDCANoDiW0Owi fxIS0MiwnxNhwqUtFjAUtSUgAsBN1L4rlPTP352TcH3TYxNP0y7fB8gYDiHzkXmVkOeqLw1VHiQY 0qZsuplzbKFbCM6tyVz6SfrCEYi7f57VkB0_lDnGuoCCg9bJMo4hYh_bGJZ1RvqH_CXC0MeSPG3q h5x8QJt819uuH_jb5y1I4tFH52WKGypf5p9fhcQvTg1UkRU.xpnHG92jAk1ZL8kekx5No0Id4_bR tug312KA0IXp2k_B_fmqwj7S6loPCuLcs8x8otzm07GNnX3gJhHkLSl5znypAB7ww7mVEUdx0aJm eulmPCJGK2bJle2YsLBuZ8Hb46Zt6SgfbR72volarIelHRIrHFMsPJw.sLUClXQCs9GQouh3Kyu_ fedsg1KzUhX86YtbrQpb8lLXxlhdlk4CklgRXoMfOUtAwkpsJV8IgBa6T_yG2S4d503sFT5I5tUY DBptN7qB3oJNn7heUvsFe1rf9fxbMnzl0b71Q8oLCuB6KoxSOBVCzLAV6uoT_wHuJj3Sfa_HXglB awr7mAkuy3V_XuXZ6R6ZsvYNZ9tp.GlXiBRw1Qn5rHhpl.Mug_6jVJnyNAAcgCMwNEY0VvoF_HS8 tEV2hawaj5yMjtMh_NYGUHF0wiH1NPvPTLqhkHaugj_6ogXreUiw_qlrphL9xHYLW9sNxgCmNRxC 3_rcg1NxGitD_FMNpL2HFI7YNqn5l.xjYyowsdMP6.6D1F_xyKS6rQjG0YPo.0pH.cj65_5iVuqA 4dAwKVgHxD7Ex97.7FszwblI_mBpJteDpdYjQkR4vD4IfkR2U_AyKYLiSfcwVPRuQLIu_L2sj0zi IvSIE1I9gafq_OSUU0_pl6_wjleXDFOuUr7lQ.PRuBZJ7d5GEnDfudWvLnAjDf1e.fGTRrTe.53d SrYaBpTxAKVLWVZ_66cAxZKizdv7RqJ_bIWkKcAxAr3WiEZQdC20xeEzfWV8sfInzwpSeCq0bPNS p62A8jarJ4n9sKbrIRCEvmyHSpNoFjLZxVp3kg6SJbbrP4rFttbIQShC.bfomvPfzFMMyCZGs7DU 8gmQFt6JZZowp5QMHhjsOmQXDulBK2QVROvVC3hfQEm8RR6WrifI7OI57sVYMMb4pBEgpG77TQoF BYLU5rCzsJsIejNKfoMWFbMRDoEWYU_3.2I0Ypl8AhaM0RKccHn.Hz54MQXLMscrGu_jkpj3xMdK 6UcWRXhkzNh_zbJSDUVSz3YGqOp6VFp0YN3OVcBOfyGcW3nZT804dB_GMxd8Llk7Cp8KyzRbfioz cTx0oD8ae_1JBujphxK1AEvLUXY6LjC9lDcXtKs8Dx.O9R8bgQ19dxsxb_WOUog6KIlYzN9ckD79 KMS8WSWD_A0Uq04urTUI_66vb3hiAqBEZ_iFBuGHoFDqtxULjBMLkBBnpPf9byHWmSJGMGrFvVD9 qBqJO.SQ.mVeWPc.CEa15cnGx5jxZUDqCnC5sudzovGD084RnKE8a94fkD_7_DEsfdCevF8K.KZ0 grlrk23nyxPKaHBdHh.SlGablERFP5PTJUVfKzlUxgyVQhM1Mlb6l.sM9fGTEt2UrWejKoHb1A6k zM5o5cFqogYjrXm9tdikN8rKz0wnSUUN.nZBIFRie8fAVVu0o2whVM8a_7h5BZkkbVrK1iCvGE9J Wl3U._5tnTCL4bZq7cD5TkXLHEgd55gFEAo8jKhQxl4W6OkR4t4ADQQQzOyqnHQ6zJht22VrfxeC bg3UtRdhWQp5mUoZ8Kr0HovpWpyQKHjzCFcNKXSkMBVzOk19e6Hy8Zd_neVrU8q9KFzSTj2uDY9S 0nHM5oleHh.o3psbr269Z4V1eyPfKRLBp8tQISCEU5oxSfEfC6qLVCDQLT.kTbJEk_oWvSqNsi3r vzjUifNANraVHpI6SAh6mTq6o4kykqrO6iCwd75JwaAxr4mM9tdCT6.5TR3hZ2nf1QWPH2GgqZ.i 2ZP7oPvQiWVej9.g63Ckh4LDKK6ujy16hCGyBy2FFrYLhQIAZvEmt.k8HmLAGe2CXljknz5Fqt.a 7FK4oFL_qmyGDnnEblTg.WOx5yI.4fj5YGeQR0K8pscbdHUV2VCEr3MSTARgTItIITbWUGpLlKVp fFb5_gzNxkbyxFRaEjlrtltsiVpTOt8ObDLRISOFvZY3sJ4DSuLpuF1CLGnf4Ez3vDdb0D0E3myS FdfdrZmPbCNOkKRfcUTD0KukBram_8GzUP.y2i0wT6JPWK6DvPK2dZsNZNAEob.BwA_6mMucS.0I - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 12 Jul 2021 01:29:54 +0000 Received: by kubenode542.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 19987a45ef063654d8c02e9a1bf4274a; Mon, 12 Jul 2021 01:29:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: HoneyComb first-boot notes [a L3/L2/L1/RAM performance oddity] Date: Sun, 11 Jul 2021 18:29:51 -0700 References: <8A6C415F-A57B-4F2F-861F-052B487166D6.ref@yahoo.com> <8A6C415F-A57B-4F2F-861F-052B487166D6@yahoo.com> <40AE6447-77AF-4D0E-864F-AD52D9F3346F@yahoo.com> <12A4EDD1-A2AB-4CE3-AB0E-A4B5D6FB4674@yahoo.com> <5B1B5E1A-8AE4-4889-ABE6-50C206F896FB@yahoo.com> <7DBDC8AB-C80B-4E26-B58F-251A3D29CE41@yahoo.com> <5BBF1B55-F02C-4817-B805-677EDDC5B809@yahoo.com> <0B577668-97AB-44B6-B1A7-C68F6CC299E5@yahoo.com> To: freebsd-arm In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GNR5c5pw2z4nlJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=iPAEPIEM; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[98.137.68.84:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-11, at 04:03, Mark Millard wrote: > On 2021-Jul-10, at 22:09, Mark Millard wrote: >=20 >> On 2021-Jun-24, at 16:25, Mark Millard wrote: >>=20 >>> On 2021-Jun-24, at 16:00, Mark Millard wrote: >>>=20 >>>> On 2021-Jun-24, at 13:39, Mark Millard = wrote: >>>>=20 >>>>> Repeating here what I've reported on teh solidrun discord: >>>>>=20 >>>>> I decided to experiment with monitoring the temperatures reported >>>>> as things are. For the default heat-sink/fan and the 2 other fans >>>>> in the case, buildworld with load average 16.? for some time has >>>>> stayed with tz0 through tz6 reporting between 61.0degC and = 66.0degC, >>>>> say about 20degC for ambiant. (tz7 and tz8 report 0.1C.) During >>>>> stages with lower load averages, the tz0..tz6 tempuratures back = off >>>>> some. So it looks like my default context keeps the system >>>>> sufficiently cool for such use. >>>>>=20 >>>>> I'll note that the default heat-sink's fan is not operating at = rates >>>>> that I hear it upstairs. I've heard the noisy mode from there = during >>>>> early parts of booting for Fedora 34 server, for example. >>>>=20 >>>> So I updated my stable/13 source and built and installed >>>> the update, then did a rm -fr of the build directory >>>> tree context and started a from-scratch build. The >>>> build had: >>>>=20 >>>> SYSTEM_COMPILER: Determined that CC=3Dcc matches the source tree. = Not bootstrapping a cross-compiler. >>>> and: >>>> SYSTEM_LINKER: Determined that LD=3Dld matches the source tree. = Not bootstrapping a cross-linker. >>>>=20 >>>> as is my standard context for doing such "how long does >>>> it take" buildworld buildkernel testing. >>>>=20 >>>> On aarch64 I do not build for targeting non-arm architectures. >>>> This does save some time on the builds. >>>=20 >>> I should have mentioned that my builds are based on tuning >>> for the cortex-a72 via -mcpu=3Dcortex-a72 being used. This >>> was also true of the live system that was running, kernel >>> and world. >>>=20 >>>> The results for the HoneyComb configuration I'm using: >>>>=20 >>>> World build completed on Thu Jun 24 15:30:11 PDT 2021 >>>> World built in 3173 seconds, ncpu: 16, make -j16 >>>> Kernel build for GENERIC-NODBG-CA72 completed on Thu Jun 24 = 15:34:45 PDT 2021 >>>> Kernel(s) GENERIC-NODBG-CA72 built in 274 seconds, ncpu: 16, make = -j16 >>>>=20 >>>> So World+Kernel took a a little under 1 hr to build (-j16). >>>>=20 >>>>=20 >>>>=20 >>>> Comparison/contrast to prior aarch64 systems that I've used >>>> for buildworld buildkernel . . . >>>>=20 >>>>=20 >>>> By contrast, the (now failed) OverDrive 1000's last timing >>>> was (building releng/13 instead of stable/13): >>>>=20 >>>> World build completed on Tue Apr 27 02:50:52 PDT 2021 >>>> World built in 12402 seconds, ncpu: 4, make -j4 >>>> Kernel build for GENERIC-NODBG-CA72 completed on Tue Apr 27 = 03:08:04 PDT 2021 >>>> Kernel(s) GENERIC-NODBG-CA72 built in 1033 seconds, ncpu: 4, make = -j4 >>>>=20 >>>> So World+Kernel took a a little under 3.75 hrs to build (-j4). >>>>=20 >>>>=20 >>>> The MACCHIATObin Double Shot's last timing was >>>> (building a 13-CURRENT): >>>>=20 >>>> World build completed on Tue Jan 19 03:44:59 PST 2021 >>>> World built in 14902 seconds, ncpu: 4, make -j4 >>>> Kernel build for GENERIC-NODBG completed on Tue Jan 19 04:04:25 PST = 2021 >>>> Kernel(s) GENERIC-NODBG built in 1166 seconds, ncpu: 4, make -j4 >>>>=20 >>>> So World+Kernel took a little under 4.5 hrs to build (-j4). >>>>=20 >>>>=20 >>>> The RPi4B 8GiByte's last timing was >>>> ( arm_freq=3D2000, sdram_freq_min=3D3200, force_turbo=3D1, USB3 SSD >>>> building releng/13 ): >>>>=20 >>>> World build completed on Tue Apr 20 14:34:38 PDT 2021 >>>> World built in 22104 seconds, ncpu: 4, make -j4 >>>> Kernel build for GENERIC-NODBG completed on Tue Apr 20 15:03:24 PDT = 2021 >>>> Kernel(s) GENERIC-NODBG built in 1726 seconds, ncpu: 4, make -j4 >>>>=20 >>>> So World+Kernel took somewhat under 6 hrs 40 min to build. >>>=20 >>> The -mcpu=3Dcortex-a72 use note also applies to the OverDrive 1000, >>> MACCHIATObin Double Shot, and RPi4B 8 GiByte contexts. >>>=20 >>=20 >> I've run into an issue where what FreeBSD calls cpu 0 has >> significantly different L3/L2/L1/RAM subsystem performance >> than all the other cores (cpu 0 being worse). Similarly for >> compared/contrasted to all 4 MACCHIATObin Double Shot cores. >>=20 >> A plot with curves showing the issue is at: >>=20 >> = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/Honey= CombFreeBSDcpu0RAMAccessPerformanceIsOdd.png >>=20 >> The dark red curves in the plot show the expected general >> shape for such and are for cpu 0. The lighter colored >> curves are the MACCHIATObin curves. The darker ones are >> the HoneyComb curves, where the L3/L2/L1 is relatively >> effective (other than cpu 0). >>=20 >> My notes on Discord (so far) are . . . >>=20 >> The curves are from my C++ variant of the old Hierarchical >> INTegration benchmark (historically abbreviated HINT). You >> can read the approximate size of a level of cache from=20 >> the x-axis for where the curve drops faster. So, right >> (most obvious) to left (least obvious): L3 8 MiByte, L2 1 >> MiByte (per core pair, as it turns out), L1 32 KiByte. >>=20 >> The curves here are for single thread benchmark >> configurations with cpuset used to control which CPU is >> used. I first noticed this via odd performance variations >> in multithreading with more cores allowed than in use (so >> migrations to a variety of cpus over time). >>=20 >> I explored all the CPUs (cores), not just what I plotted. >> Only the one gets the odd performing memory access >> structure in its curve. >>=20 >> FYI: The FreeBSD boot is UEFI/ACPI based for both systems, >> not U-Boot based. >>=20 >=20 > Jon Nettleton has replicated the memory access performance > issue on the one cpu via a different HoneyComb, running > some Linux kernel, using tinymembench as the benchmark. >=20 Jon reports that for HoneyCombs older and newer, EDK2's older and newer: All show the behavior on cpu 0. "[I]t may have always existed." Jon also reports that U-Boot based booting does not get the behavior. (I've never used U-Boot to boot the HoneyComb for any OS media that I've got around. In my U-Boot ignorance, my quick attempts failed for FreeBSD main and Fedora 34 Server media that I've been using with EDK2's UEFI/ACPI.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Jul 12 07:49:37 2021 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 AFDC212761B9 for ; Mon, 12 Jul 2021 07:49:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GNbWj4DHfz3vWT for ; Mon, 12 Jul 2021 07:49:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 7893F277C for ; Mon, 12 Jul 2021 07:49: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 16C7nbIv074893 for ; Mon, 12 Jul 2021 07:49:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16C7nbC7074892 for freebsd-arm@FreeBSD.org; Mon, 12 Jul 2021 07:49: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 257127] kernel.bin creation fails, empty file Date: Mon, 12 Jul 2021 07:49:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@oldach.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257127 Bug ID: 257127 Summary: kernel.bin creation fails, empty file Product: Base System Version: 13.0-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: freebsd@oldach.net make buildkernel on RPi4/8G: ....................... snip ......................................... text data bss dec hex filename 11133030 1719011 3665920 16517961 0xfc0b49 kernel.full --- kernel.debug --- --- kernel.bin --- --- kernel.debug --- objcopy --only-keep-debug kernel.full kernel.debug --- kernel --- objcopy --strip-debug --add-gnu-debuglink=3Dkernel.debug kernel.full kernel --- kernel.bin --- arm_kernel_boothdr.awk: missing kernbase/_start/_end symbol(s) created kernel.bin from kernel.full -------------------------------------------------------------- >>> Kernel build for GENERIC completed on Mon Jul 12 05:03:24 CEST 2021 -------------------------------------------------------------- >>> Kernel(s) GENERIC built in 1865 seconds, ncpu: 4, make -j8 -------------------------------------------------------------- hmo@p48 /boot/kernel $ l kernel* -r-xr-xr-x 1 root wheel 15834432 Jul 12 09:36 kernel* -r-xr-xr-x 1 root wheel 0 Jul 12 09:36 kernel.bin* hmo@p48 /boot/kernel $ hmo@p48 /usr/obj/usr/src/arm64.aarch64/sys/GENERIC $ l kernel* -rwxr-xr-x 1 root wheel 15834432 Jul 12 09:36 kernel* -rw-r--r-- 1 root wheel 0 Jul 12 09:36 kernel.bin -rwxr-xr-x 1 root wheel 72341960 Jul 12 09:36 kernel.debug* -rwxr-xr-x 1 root wheel 85199304 Jul 12 09:36 kernel.full* hmo@p48 /usr/obj/usr/src/arm64.aarch64/sys/GENERIC $ On 10th July build was still OK: -r-xr-xr-x 1 root wheel 15822088 Jul 10 20:30 /mnt/boot/kernel/kernel* -r-xr-xr-x 1 root wheel 12845936 Jul 10 20:31 /mnt/boot/kernel/kernel.bi= n* Perhaps related to the recent one-tru-awk patches? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jul 12 09:50:10 2021 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 4132D12415E9 for ; Mon, 12 Jul 2021 09:50:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GNfC26qb6z4h5N for ; Mon, 12 Jul 2021 09:50:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1626083415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H9LOATu7yU2t8ttZvyqSuDFUrzozlBUA1Wd2I3XJgL4=; b=g2QVRAQTP9OW0YSozD7SmVnsPc1nX/Oja0TkhkExLrPVRrI56cXJLH30OmGvKCXgqwGro0 +H5K361jIshP5u6FtZJXwwb6hs4p9+hn5dHqD4YTGkxsubpyEka8y6qUUxzuvn7lssAUgI ptwRfo60JMboLsvppin9Dom8Trc9+xs= Received: from skull.home.blih.net (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id b0b3a6fa (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 12 Jul 2021 09:50:15 +0000 (UTC) Date: Mon, 12 Jul 2021 11:50:10 +0200 From: Emmanuel Vadot To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org Subject: Re: git: 1dec3639fd0c - main - sysutils/u-boot: Update to 2021.07 Message-Id: <20210712115010.a405a8f5e313ec75142fa544@bidouilliste.com> In-Reply-To: <87mtqsn0we.wl-herbert@gojira.at> References: <202107071618.167GIvXd048504@gitrepo.freebsd.org> <874kd3390q.wl-herbert@gojira.at> <87o8b8n1rf.wl-herbert@gojira.at> <87mtqsn0we.wl-herbert@gojira.at> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GNfC26qb6z4h5N X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Herbert, Took the last mail of the thread, it was easier. On Sun, 11 Jul 2021 20:47:13 +0200 "Herbert J. Skuhra" wrote: > On Sun, 11 Jul 2021 20:28:36 +0200, "Herbert J. Skuhra" wrote: > > > > On Fri, 09 Jul 2021 15:35:17 +0200, "Herbert J. Skuhra" wrote: > > > > > > With u-boot 2021.07 two of my RPis no longer boot: > > > > > > Raspberry Pi 3 Model B V1.2: mmc not detected; tries to boot over the network. > > > > With u-boot 2021.04 I get: > > > > > mmc list > > mmc@7e300000: 0 (SD) > > > > > mmc part > > > > Partition Map for MMC device 0 -- Partition Type: DOS > > > > Part Start Sector Num Sectors UUID Type > > 1 2048 102400 5fd0f4e4-01 0c Boot > > 2 104448 124631040 5fd0f4e4-02 a5 > > > > > mmcinfo > > Device: mmc@7e300000 > > Manufacturer ID: 3 > > OEM: 5344 > > Name: SC64G > > Bus Speed: 25000000 > > Mode: MMC legacy > > Rd Block Len: 512 > > SD version 3.0 > > High Capacity: Yes > > Capacity: 59.5 GiB > > Bus Width: 4-bit > > Erase Group Size: 512 Bytes > > > > But with u-boot 2021.07 (starting with rc1) I get: > > > > > mmc list > > mmc@7e300000: 2 (SD) > > > > > mmc part > > MMC Device 0 not found > > no mmc device at slot 0 > > > > > mmc info > > MMC Device 0 not found > > no mmc device at slot 0 > > > > I have to run > > > > > mmc dev 2 > > > > Afterwards 'mmc part' and 'mmc info' show the above output. > > But how do I boot from mmc dev 2? And how can I change this > > permanently? > > My RPi3 boots if I run: > > U-Boot> setenv boot_targets 'mmc2' > U-Boot> setenv bootcmd_mmc2 'devnum=2; run mmc_boot' > U-Boot> boot > > -- > Herbert > So I took the latest snapshot image available on the ftp (FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20210701-c5f4772c66d-247671.img) and dd u-boot for the nanopi_m1plus on it. The snapshot already have the u-boot for BeagleBone and RPI* No problems on the BBB No problems on the NanoPi M1Plus I do see the hang on the RPI2 though (RPI2 v1.1) Commit 60a376b09332a0cf061b3 in u-boot removes CONFIG_EFI_GRUB_ARM32_WORKAROUND from the RPI2 defconfig but we do re-add it in the ports tree (see https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/Makefile#n215 and https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/files/FreeBSD_Fragment#n2) So if you bisected from u-boot tree directly and didn't use a fragment that's normal to get this commit as the first bad one. Note that the images don't have a boot.scr (u-boot script) for a long time now, we rely on EFI. (See commit https://cgit.freebsd.org/src/commit/?id=33bec6889a0957d1c06c36378157a46a95fcb004) For your mmc problem this can be that you are not using the dtoverlay that switches between the sdhost controller and the sdhci. Using this rewrite the mmc number for u-boot. Cheers, -- Emmanuel Vadot From nobody Mon Jul 12 11:44:43 2021 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 7CD4A127A097 for ; Mon, 12 Jul 2021 11:44:47 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (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 "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GNhl24bqCz3Ccx for ; Mon, 12 Jul 2021 11:44:46 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Mon, 12 Jul 2021 13:44:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1626090283; bh=aQDyyXq8bTkkWfq9uScClnESdM2uyQUplB2g6a09WbE=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=cl3XU441qh3CtiDEcUmWiz2s2YA3sXJx9iW+2XWsT84oeEuNvd7Qdwu9VQxgAYt5I gSBv3QQk2kBAt429QdGot4EYRxyL4MzmWKCfgCClYpmm+LvWMs+M1NO1J25WbZ48NP W23jvENrLeSQvf14e2+yupYTXXZGwMQAXEV0NvNhrnKFEOiffjuuP88DIta/I39DYK AlmWlprONrE/R/eLG3zH0ZF7S5SR+/b0QiLtiry/7J6M60KEzbKRF17PSJrUfOuPZW r4HMvlnt9wqfbQO26dCbfpr2Oeb+X2s7bQjAH16/rcn5y7hvafjhJynWtHhGok9KbK 8FgMuhvHW60QA== From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: git: 1dec3639fd0c - main - sysutils/u-boot: Update to 2021.07 Message-ID: References: <202107071618.167GIvXd048504@gitrepo.freebsd.org> <874kd3390q.wl-herbert@gojira.at> <87o8b8n1rf.wl-herbert@gojira.at> <87mtqsn0we.wl-herbert@gojira.at> <20210712115010.a405a8f5e313ec75142fa544@bidouilliste.com> 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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210712115010.a405a8f5e313ec75142fa544@bidouilliste.com> X-Rspamd-Queue-Id: 4GNhl24bqCz3Ccx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=cl3XU441; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [-3.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.91)[-0.911]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Hi Emmanuel, thanks for your feedback. On Mon, Jul 12, 2021 at 11:50:10AM +0200, Emmanuel Vadot wrote: > > So I took the latest snapshot image available on the ftp > (FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20210701-c5f4772c66d-247671.img) > and dd u-boot for the nanopi_m1plus on it. > The snapshot already have the u-boot for BeagleBone and RPI* > > No problems on the BBB > No problems on the NanoPi M1Plus > I do see the hang on the RPI2 though (RPI2 v1.1) > > Commit 60a376b09332a0cf061b3 in u-boot removes > CONFIG_EFI_GRUB_ARM32_WORKAROUND from the RPI2 defconfig but we do > re-add it in the ports tree (see > https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/Makefile#n215 > and > https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/files/FreeBSD_Fragment#n2) > > So if you bisected from u-boot tree directly and didn't use a fragment > that's normal to get this commit as the first bad one. I was lazy and built the port (created a *.tar.bz2 archive from the git checkout or rcX downloads and modified distinfo). > Note that the images don't have a boot.scr (u-boot script) for a long > time now, we rely on EFI. (See commit > https://cgit.freebsd.org/src/commit/?id=33bec6889a0957d1c06c36378157a46a95fcb004) Yes, my RPi2 only boots without this change (a361eabce3cf). Maybe it should be reverted until we have a proper fix? Or create images with older U-Boot (2021.01)? > For your mmc problem this can be that you are not using the dtoverlay > that switches between the sdhost controller and the sdhci. Using this > rewrite the mmc number for u-boot. This happens even with the official builds! FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210701-6aee7855180-246143.img.xz ==> OK (U-Boot 2021.04) FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210708-f6d448caf69-246212.img.xz ==> Not OK. (U-Boot 2021.07) I am using U-Boot 2021.04 again because I still don't know how to boot from mmc device 2 automatically. -- Herbert From nobody Wed Jul 14 10:40:31 2021 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 3475E1243363 for ; Wed, 14 Jul 2021 10:40:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GPvCz0x6Hz4W52 for ; Wed, 14 Jul 2021 10:40:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 057971490A for ; Wed, 14 Jul 2021 10:40:31 +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 16EAeUKl037515 for ; Wed, 14 Jul 2021 10:40:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16EAeUSd037514 for freebsd-arm@FreeBSD.org; Wed, 14 Jul 2021 10:40:30 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 256903] arm64: ELF auxiliary vectors for armv7 processors miss VFP information Date: Wed, 14 Jul 2021 10:40:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fuz@fuz.su X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256903 Robert Clausecker changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed --- Comment #1 from Robert Clausecker --- Bug #256897 has a DR (review D31175) fixing this issue. Marking as duplica= te. *** This bug has been marked as a duplicate of bug 256897 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jul 14 14:36:13 2021 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 EF54F1276B9D for ; Wed, 14 Jul 2021 14:36:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQ0S46TLHz3pwY for ; Wed, 14 Jul 2021 14:36:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1626273373; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=giP0wSNW7MXpAqUsI8Y6cRUvOVz2x/uIghVX9KeCJzQ=; b=XIP2B55iGj2rE5opI6+TJh1afOMalq7SG+k6ZmQ6jR2dF4sePoWN4WIyurwVsx8T5uARFV CNYe1JU8s5I097IL7ayw0NvG1IgdWOdMo+Av9otBoMSx0y8xXUb2RBpVfTkJpwKpSSfkM1 q+QQRGSsDhpJqU1F8TEElZRvvg1bcxQ= Received: from skull.home.blih.net (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id f05fec41 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 14 Jul 2021 14:36:13 +0000 (UTC) Date: Wed, 14 Jul 2021 16:36:13 +0200 From: Emmanuel Vadot To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org Subject: Re: git: 1dec3639fd0c - main - sysutils/u-boot: Update to 2021.07 Message-Id: <20210714163613.88579f95ca25130ab712cb45@bidouilliste.com> In-Reply-To: References: <202107071618.167GIvXd048504@gitrepo.freebsd.org> <874kd3390q.wl-herbert@gojira.at> <87o8b8n1rf.wl-herbert@gojira.at> <87mtqsn0we.wl-herbert@gojira.at> <20210712115010.a405a8f5e313ec75142fa544@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GQ0S46TLHz3pwY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=XIP2B55i; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.45 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.956]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_MEDIUM(-0.90)[-0.902]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On Mon, 12 Jul 2021 13:44:43 +0200 "Herbert J. Skuhra" wrote: > Hi Emmanuel, > > thanks for your feedback. > > On Mon, Jul 12, 2021 at 11:50:10AM +0200, Emmanuel Vadot wrote: > > > > So I took the latest snapshot image available on the ftp > > (FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20210701-c5f4772c66d-247671.img) > > and dd u-boot for the nanopi_m1plus on it. > > The snapshot already have the u-boot for BeagleBone and RPI* > > > > No problems on the BBB > > No problems on the NanoPi M1Plus > > I do see the hang on the RPI2 though (RPI2 v1.1) > > > > Commit 60a376b09332a0cf061b3 in u-boot removes > > CONFIG_EFI_GRUB_ARM32_WORKAROUND from the RPI2 defconfig but we do > > re-add it in the ports tree (see > > https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/Makefile#n215 > > and > > https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/files/FreeBSD_Fragment#n2) > > > > So if you bisected from u-boot tree directly and didn't use a fragment > > that's normal to get this commit as the first bad one. > > I was lazy and built the port (created a *.tar.bz2 archive from > the git checkout or rcX downloads and modified distinfo). > > > Note that the images don't have a boot.scr (u-boot script) for a long > > time now, we rely on EFI. (See commit > > https://cgit.freebsd.org/src/commit/?id=33bec6889a0957d1c06c36378157a46a95fcb004) > > Yes, my RPi2 only boots without this change (a361eabce3cf). Maybe it > should be reverted until we have a proper fix? Or create images with > older U-Boot (2021.01)? Damn, I missed that u-boot-rpi2 used its own fragment. Can you try adding CONFIG_EFI_GRUB_ARM32_WORKAROUND=y to sysutils/u-boot-rpi2/files/rpi2_fragment and see if that fixes the issue for you ? > > For your mmc problem this can be that you are not using the dtoverlay > > that switches between the sdhost controller and the sdhci. Using this > > rewrite the mmc number for u-boot. > > This happens even with the official builds! > > FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210701-6aee7855180-246143.img.xz > ==> OK (U-Boot 2021.04) > FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210708-f6d448caf69-246212.img.xz > ==> Not OK. (U-Boot 2021.07) > > I am using U-Boot 2021.04 again because I still don't know how to boot > from mmc device 2 automatically. > > -- > Herbert > -- Emmanuel Vadot From nobody Wed Jul 14 19:28:14 2021 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 B841A8D2E5E for ; Wed, 14 Jul 2021 19:28:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQ6wy24b1z3m9V for ; Wed, 14 Jul 2021 19:28:17 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1626290895; 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=2xVUIvFIKnm1BEd/zEa6lKBPa5rC0606HXW2i/6Foos=; b=g4FuTDS5LuQQzuTzeKgVZjyCW/pMEFCZ/CcezxP/6HlNJBWrYSxYj/dAww4m+wsAWRRqNd TXX5Amc013oeRTslubRPCOupUhjhefIZDY7XXFSRld5AywWCak2tYHxElSgbstKld92Lt9 NtPZonNpTa1JU78gujb8EhyFtUbquU0= Received: from skull.home.blih.net (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 28c6b04a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 14 Jul 2021 19:28:15 +0000 (UTC) Date: Wed, 14 Jul 2021 21:28:14 +0200 From: Emmanuel Vadot To: "Herbert J. Skuhra" , freebsd-arm@freebsd.org Subject: Re: git: 1dec3639fd0c - main - sysutils/u-boot: Update to 2021.07 Message-Id: <20210714212814.eb7fa1f9c35568b22bc5264d@bidouilliste.com> In-Reply-To: <20210714163613.88579f95ca25130ab712cb45@bidouilliste.com> References: <202107071618.167GIvXd048504@gitrepo.freebsd.org> <874kd3390q.wl-herbert@gojira.at> <87o8b8n1rf.wl-herbert@gojira.at> <87mtqsn0we.wl-herbert@gojira.at> <20210712115010.a405a8f5e313ec75142fa544@bidouilliste.com> <20210714163613.88579f95ca25130ab712cb45@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GQ6wy24b1z3m9V X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=g4FuTDS5; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.58 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[212.83.155.74:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.08)[-0.084]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.83.155.74:from]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On Wed, 14 Jul 2021 16:36:13 +0200 Emmanuel Vadot wrote: > On Mon, 12 Jul 2021 13:44:43 +0200 > "Herbert J. Skuhra" wrote: > > > Hi Emmanuel, > > > > thanks for your feedback. > > > > On Mon, Jul 12, 2021 at 11:50:10AM +0200, Emmanuel Vadot wrote: > > > > > > So I took the latest snapshot image available on the ftp > > > (FreeBSD-14.0-CURRENT-arm-armv7-GENERICSD-20210701-c5f4772c66d-247671.img) > > > and dd u-boot for the nanopi_m1plus on it. > > > The snapshot already have the u-boot for BeagleBone and RPI* > > > > > > No problems on the BBB > > > No problems on the NanoPi M1Plus > > > I do see the hang on the RPI2 though (RPI2 v1.1) > > > > > > Commit 60a376b09332a0cf061b3 in u-boot removes > > > CONFIG_EFI_GRUB_ARM32_WORKAROUND from the RPI2 defconfig but we do > > > re-add it in the ports tree (see > > > https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/Makefile#n215 > > > and > > > https://cgit.freebsd.org/ports/tree/sysutils/u-boot-master/files/FreeBSD_Fragment#n2) > > > > > > So if you bisected from u-boot tree directly and didn't use a fragment > > > that's normal to get this commit as the first bad one. > > > > I was lazy and built the port (created a *.tar.bz2 archive from > > the git checkout or rcX downloads and modified distinfo). > > > > > Note that the images don't have a boot.scr (u-boot script) for a long > > > time now, we rely on EFI. (See commit > > > https://cgit.freebsd.org/src/commit/?id=33bec6889a0957d1c06c36378157a46a95fcb004) > > > > Yes, my RPi2 only boots without this change (a361eabce3cf). Maybe it > > should be reverted until we have a proper fix? Or create images with > > older U-Boot (2021.01)? > > Damn, I missed that u-boot-rpi2 used its own fragment. > Can you try adding CONFIG_EFI_GRUB_ARM32_WORKAROUND=y to > sysutils/u-boot-rpi2/files/rpi2_fragment and see if that fixes the > issue for you ? I did test and it worked so new u-boot commited as in 619258548719d > > > For your mmc problem this can be that you are not using the dtoverlay > > > that switches between the sdhost controller and the sdhci. Using this > > > rewrite the mmc number for u-boot. > > > > This happens even with the official builds! > > > > FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210701-6aee7855180-246143.img.xz > > ==> OK (U-Boot 2021.04) > > FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210708-f6d448caf69-246212.img.xz > > ==> Not OK. (U-Boot 2021.07) > > > > I am using U-Boot 2021.04 again because I still don't know how to boot > > from mmc device 2 automatically. > > > > -- > > Herbert > > > > > -- > Emmanuel Vadot > -- Emmanuel Vadot From nobody Thu Jul 15 11:21:53 2021 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 EB6581273488 for ; Thu, 15 Jul 2021 11:22:48 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQX6J0gXkz4lCW for ; Thu, 15 Jul 2021 11:22:47 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-io1-xd2c.google.com with SMTP id g22so5991777iom.1 for ; Thu, 15 Jul 2021 04:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9PcJj2Smi5/3/G+ybmFvOJtRkCX01NuE4z57ZgA0eLw=; b=j1vurb+1Gjp+IxqF8gS3jM00HuvDdrgHErg1kmdzD/lqe5BxWSLU+qRYVdF2ZBswqQ pKQT1ZLpZZjqaqw26qJVf+2zj90GWCKPgNgM1rBdmCNeU0LsdmKVBtG+XA+g78VU21kH s3rEzrg4o3l4Vko/54JUlwssoI44jlH6sYTJlMBGnZ+yF3OYvb/akuXwYxcLo6ozc6BM sMvLG4bNJ61r9WlIBI2MURDblIfD1kBRd6SSe8K++D6BQIXHo/VITxj2tHqbYHIAx7YR u9fmmfQ3CJu0QNhF0BrD4LERUt4AZYv1DwqwU6LYwuf9MGU/o5E7PuhVoxF0oDIi57gr wSGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9PcJj2Smi5/3/G+ybmFvOJtRkCX01NuE4z57ZgA0eLw=; b=By2zCeAJVVL++rglM4XJRloY80gEWu82PCUN09K0u6NSerjBGna1YzBraChPnznOeS ibWuLObD1xNmmFypcMrkfjU3LV4QwIQ47+Ff2o+PcUtMSSs1vCvA8+189OUHEjYPmvLG 0WuWDV2YQDDpWEPLr7kmqxHJjcVpcol+23GacVVeBOce/+PjyiGsWLUg3v+X4Z5qo0yT fNFVzEA11bQGhZpNMJDsQS2PTxLXh1SRhR93tpo88Oof6tLquEc0pBmpE59wXGdUcQAy o80pPbpKBc7kWiJLjz6ES6nvvqJn6/Pnvx6ssSZnfguFx6WWSSo49ITn6AxEqlaKCxdZ pEug== X-Gm-Message-State: AOAM530Bi954Wo+HnzLKuP67Cl7Y/+0u2OvnqsQUBsGF8WBTlRuZ7rI7 c1ZDmxIj2EBWAjuLsXN+DQIqV5fw/YzMyyXJM0R9L1NpF+uSLg== X-Google-Smtp-Source: ABdhPJwIpzW05DPq/RWLA4liZTanSx0nSNgMECr9vFZTTXbGLyYBmmNDjcmsnucW+QBihfQHXdAIL5iZSipK/HnmBD8= X-Received: by 2002:a02:7a50:: with SMTP id z16mr3472285jad.139.1626348166805; Thu, 15 Jul 2021 04:22:46 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 From: Sleep Walker Date: Thu, 15 Jul 2021 14:21:53 +0300 Message-ID: Subject: FreeBSD for new SOC To: Free BSD Content-Type: multipart/alternative; boundary="000000000000c37ede05c727b038" X-Rspamd-Queue-Id: 4GQX6J0gXkz4lCW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=j1vurb+1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s199pwa1k9r@gmail.com designates 2607:f8b0:4864:20::d2c as permitted sender) smtp.mailfrom=s199pwa1k9r@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::d2c:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::d2c:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2c:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: Y --000000000000c37ede05c727b038 Content-Type: text/plain; charset="UTF-8" Hello FreeBSD ARM community! I would like to discuss one issue. A lot of devices have already been sold in the world on Amlogic processors. These are SBCs and VIDEO consoles. But they all run on Andriod or Linux. No FreeBSD support ;-). If it had been, the user community would have grown a lot, FreeBSD would have grown in popularity, and the number of testers and committers would have increased. This would make FreeBSD for ARM even more stable. What are your thoughts on porting FreeBSD to Amlogic? Such attempts have been made before https://github.com/tomtor/image-freebsd-c2 NetBSD supports multiple SBCs on Amlogic http://www.armbsd.org/arm/ Why don't we add this support too? I know several Chinese manufacturers who would be happy to send samples of their products to developers. I recently received a RADXA ZERO on Amlogic S905Y2 as a free samples https://wiki.radxa.com/Zero/hardware https://forum.radxa.com/t/introduce-the-radxa-zero/6550 It is a very interesting and tiny device, it comes with Android pre-installed on eMMC, not even Mainline Linux support yet. I've been studying FreeBSD for ARM for two years now and really want to learn add support for new SOCs to FreeBSD. I now have 3 SOCs to add 1) Pine64 Quartz64, 2) Radxa Zero 3) First Russian ARM SOC - BAIKAL-M https://www.baikalelectronics.com/products/338/ In all three variants, I have the necessary equipment. And I have a great desire to learn. I have already written a USB driver for BAIKAL-M and am successfully booting the system in multi-user mode. The results can be viewed here https://pkg.personalbsd.org/baikal/ It succeeded because many devices on BAIKAL-M use fixed-clock and everything is built on DesignWare IP. But I stopped at the need to write a clock driver necessary for Ethernet and PCIe to work. If anyone would agree to advise me, I would be extremely grateful. I am willing to provide access to BAIKAL-M but ssh (since USB Ethernet works) for easier collaboration and learning. Any help or advice would be appreciated. I am extremely interested in participating in the FreeBSD porting project to the new SOC because I want to contribute to the popularization of FreeBSD. -- Yours faithfully, Sergey Tyuryukanov --000000000000c37ede05c727b038-- From nobody Thu Jul 15 11:43:10 2021 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 B7E621277469 for ; Thu, 15 Jul 2021 11:43:22 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQXZ24hVvz4pc1 for ; Thu, 15 Jul 2021 11:43:22 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi1-x236.google.com with SMTP id w188so6179822oif.10 for ; Thu, 15 Jul 2021 04:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xNFK3FEeCX3UnXAIAAQFRMLc3pHFf6Je+JytB6c3wgM=; b=FkZsD1hiZjIQsnOeVnUJONlIuq6yTeB52Fjy9AXZYC67bfegdYxZJyGZvTKCxzdUGH cAtCArP8QWdad7mx6iwMT0gX0Zv9a1ooEg7Ya/JpIlOVMbphCUaqz2Bm3Mn0eUJ9lq91 jl8fSKqfHKl1Lm6rXGEmBT60+WsWSA2m9lPYpe+l+atGecSzL5nt24LssLu0J4Zl0m/q /d1ym1te2KwK11/zT9Zdd5KT39ZKpDkg3K5SdkC9s5ddYJoobEv3dEW9873LRLUC9dz+ f8IWsQyn69i85mKRlMziLZSitYHguzw1//klT7HhxxcE/ZaCj7pH0iGT6d5mR92YJlwn 4tcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xNFK3FEeCX3UnXAIAAQFRMLc3pHFf6Je+JytB6c3wgM=; b=K18GIjJZLIs99CKJknHxg2t9S4DBMBKZCOdkpc6beL3bDY82A1pcE+4N2BY1Nyqcpz rtdT12WiIwnqwk2drs8qH4qjvIVc5PvzMKePaTZtXO6a1e1kEH5grnfzdP9+ZeDx+qju tZ66+wM2KQjqhURJQt33wb2EkvaUWZNYt0uzuixAvRI6ta5YNjhSHS0Syt47SlTcYA99 Wv0CJunGaREILVAqKMi/we1m+/enKwaNCsWB8eMb+phljqhE98O+JgZADfZ72U0W1HRG V23324O6OLyv2e2NnI4AyieKHnOQzUp+CJHNIbLjoI1CZtTa0hcz/RrymwuYOeFWtY+o p0HQ== X-Gm-Message-State: AOAM531GLv2/R8ib7jRpHYn3fr+Nq3ZaBNLWsoa1FyzOKNiuasSyI2DP C085FqTZXhzWfbC/afJQiOA0qy1wsP+rJKTMSck= X-Google-Smtp-Source: ABdhPJw6/W6C4f2UjeAodlxQXzk68brGkVTy98JzmfRL6wWnOF/+F4ogIR1QQammxpnnmkGJo3ykgpVRkXkw3ESevco= X-Received: by 2002:a05:6808:2d2:: with SMTP id a18mr7764534oid.106.1626349401522; Thu, 15 Jul 2021 04:43:21 -0700 (PDT) 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: In-Reply-To: From: Ganbold Tsagaankhuu Date: Thu, 15 Jul 2021 19:43:10 +0800 Message-ID: Subject: Re: FreeBSD for new SOC To: Sleep Walker Cc: Free BSD Content-Type: multipart/alternative; boundary="0000000000005bc65205c727faee" X-Rspamd-Queue-Id: 4GQXZ24hVvz4pc1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000005bc65205c727faee Content-Type: text/plain; charset="UTF-8" On Thu, Jul 15, 2021 at 7:23 PM Sleep Walker wrote: > Hello FreeBSD ARM community! > > I would like to discuss one issue. > > A lot of devices have already been sold in the world on Amlogic processors. > These are SBCs and VIDEO consoles. > But they all run on Andriod or Linux. No FreeBSD support ;-). > > If it had been, the user community would have grown a lot, FreeBSD would > have grown in popularity, and the number of testers and committers would > have increased. > This would make FreeBSD for ARM even more stable. > > What are your thoughts on porting FreeBSD to Amlogic? > Such attempts have been made before > https://github.com/tomtor/image-freebsd-c2 > NetBSD supports multiple SBCs on Amlogic > http://www.armbsd.org/arm/ > Why don't we add this support too? > Amlogic support was removed last November since there wasn't anyone who could maintain amlogic related codes: https://svnweb.freebsd.org/base?view=revision&revision=367993 Ganbold > > I know several Chinese manufacturers who would be happy to send samples > of their products to developers. > > I recently received a RADXA ZERO on Amlogic S905Y2 as a free samples > https://wiki.radxa.com/Zero/hardware > https://forum.radxa.com/t/introduce-the-radxa-zero/6550 > > It is a very interesting and tiny device, it comes with Android > pre-installed on eMMC, > not even Mainline Linux support yet. > > I've been studying FreeBSD for ARM for two years now and really want to > learn > add support for new SOCs to FreeBSD. > > I now have 3 SOCs to add > 1) Pine64 Quartz64, > 2) Radxa Zero > 3) First Russian ARM SOC - BAIKAL-M > https://www.baikalelectronics.com/products/338/ > > In all three variants, I have the necessary equipment. > And I have a great desire to learn. > > I have already written a USB driver for BAIKAL-M and am successfully > booting the system in multi-user mode. > The results can be viewed here https://pkg.personalbsd.org/baikal/ > > It succeeded because many devices on BAIKAL-M use fixed-clock and > everything is built on DesignWare IP. > > But I stopped at the need to write a clock driver necessary for Ethernet > and PCIe to work. > > If anyone would agree to advise me, I would be extremely grateful. > > I am willing to provide access to BAIKAL-M but ssh (since USB Ethernet > works) > for easier collaboration and learning. > > Any help or advice would be appreciated. > > I am extremely interested in participating in the FreeBSD porting project > to the new SOC because I want to contribute to the popularization of > FreeBSD. > > -- > Yours faithfully, > Sergey Tyuryukanov > --0000000000005bc65205c727faee-- From nobody Thu Jul 15 12:09:11 2021 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 29A24127C0E1 for ; Thu, 15 Jul 2021 12:10:07 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQY8v0T3Bz4sjl for ; Thu, 15 Jul 2021 12:10:06 +0000 (UTC) (envelope-from s199p.wa1k9r@gmail.com) Received: by mail-io1-xd2e.google.com with SMTP id k16so6106972ios.10 for ; Thu, 15 Jul 2021 05:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iDA0aIG5Lugyd+NdCxtO2nCQBBRUCwn8tt7g0UFWc6w=; b=RD8OXcatZ2SugmRLaYUdbVYWgI/Ic1O6q+5ZxgGZZUsLDXW+3q1AcBtITSwn/QbxM2 nC5T5VETambt7u8+bTW3sgbTWYpK3LXY/+hOQtaNrap2LgEzZfe3rDE3mZSu2oqL7zT0 9PG1FhXdrT5BBzyEg7LeFOzS7xsmR73J7einqysR+O5+Ix9vUUX1HzjizRYaBdUVvwYs J6F2PExpcUPspzjGuAsmygtHoEg/5UBpLPRrAoSMQkYbgNWKARCVqtM0WddeWWgQy81s siEqHVwCZ2xbCLgDQSN0HTfoDPqPJ8Ba4tZiiZqB3S/ww/hGvES1cwH5pvVO8oFvmXDz uAwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iDA0aIG5Lugyd+NdCxtO2nCQBBRUCwn8tt7g0UFWc6w=; b=ONjkBEASA10Vvn2LxDteTG07ZwHjFrzUW3ahsTJ/Setk8rrFhN4fN0Ir6goWaC612/ bCYR17L0QsC3PROUDNfinPamq+w3KaSE0m8Tb4umMn16N+X1pGHhs2ril+QBR3mZr/Vh EwgqHmOKCzgYqW0klxFxAXRXzmNONXPmQZ2Y6noB5MSWnUTa+QZ/ejHQBJe7IvxX0IzZ BLA0hacThXtslToTVJHPej205gJ5CyD8VaBWLA90wPSAyIWcLRbykApiKGBx6q7hewx1 IPwbftm0lhPQyYBbw9QDeM8KafBcU5A1OaWk7kJTMzzKEjnE96xmKi9P4SbIV1+kNS19 pZPA== X-Gm-Message-State: AOAM5331uc7KK9/euqFqeL/Udw+nLMWO7DAkwC1rD4QSBGaJXZQyhPz7 diszNtgTkS9fzZaGjX3i68mkzeTg5PyxWXwfAmA= X-Google-Smtp-Source: ABdhPJxzulQVr5K3rCmchWhHnlhTVoBEjIouR3UmlyK/3aRyFn+fGbo7c+gu371mCE+tyRGM4Uoypvy1heUpbqM8QHo= X-Received: by 2002:a05:6638:268d:: with SMTP id o13mr3720160jat.103.1626351005779; Thu, 15 Jul 2021 05:10:05 -0700 (PDT) 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: In-Reply-To: From: Sleep Walker Date: Thu, 15 Jul 2021 15:09:11 +0300 Message-ID: Subject: Re: FreeBSD for new SOC To: Ganbold Tsagaankhuu Cc: Free BSD Content-Type: multipart/alternative; boundary="000000000000facbc405c728591e" X-Rspamd-Queue-Id: 4GQY8v0T3Bz4sjl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000facbc405c728591e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I know that, I will try to experiment with the old code =D1=87=D1=82, 15 =D0=B8=D1=8E=D0=BB. 2021 =D0=B3. =D0=B2 14:43, Ganbold Tsa= gaankhuu : > > > On Thu, Jul 15, 2021 at 7:23 PM Sleep Walker > wrote: > >> Hello FreeBSD ARM community! >> >> I would like to discuss one issue. >> >> A lot of devices have already been sold in the world on Amlogic >> processors. >> These are SBCs and VIDEO consoles. >> But they all run on Andriod or Linux. No FreeBSD support ;-). >> >> If it had been, the user community would have grown a lot, FreeBSD would >> have grown in popularity, and the number of testers and committers would >> have increased. >> This would make FreeBSD for ARM even more stable. >> >> What are your thoughts on porting FreeBSD to Amlogic? >> Such attempts have been made before >> https://github.com/tomtor/image-freebsd-c2 >> NetBSD supports multiple SBCs on Amlogic >> http://www.armbsd.org/arm/ >> Why don't we add this support too? >> > > Amlogic support was removed last November since there wasn't anyone who > could maintain amlogic related codes: > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D367993 > > Ganbold > > > >> >> I know several Chinese manufacturers who would be happy to send samples >> of their products to developers. >> >> I recently received a RADXA ZERO on Amlogic S905Y2 as a free samples >> https://wiki.radxa.com/Zero/hardware >> https://forum.radxa.com/t/introduce-the-radxa-zero/6550 >> >> It is a very interesting and tiny device, it comes with Android >> pre-installed on eMMC, >> not even Mainline Linux support yet. >> >> I've been studying FreeBSD for ARM for two years now and really want to >> learn >> add support for new SOCs to FreeBSD. >> >> I now have 3 SOCs to add >> 1) Pine64 Quartz64, >> 2) Radxa Zero >> 3) First Russian ARM SOC - BAIKAL-M >> https://www.baikalelectronics.com/products/338/ >> >> In all three variants, I have the necessary equipment. >> And I have a great desire to learn. >> >> I have already written a USB driver for BAIKAL-M and am successfully >> booting the system in multi-user mode. >> The results can be viewed here https://pkg.personalbsd.org/baikal/ >> >> It succeeded because many devices on BAIKAL-M use fixed-clock and >> everything is built on DesignWare IP. >> >> But I stopped at the need to write a clock driver necessary for Ethernet >> and PCIe to work. >> >> If anyone would agree to advise me, I would be extremely grateful. >> >> I am willing to provide access to BAIKAL-M but ssh (since USB Ethernet >> works) >> for easier collaboration and learning. >> >> Any help or advice would be appreciated. >> >> I am extremely interested in participating in the FreeBSD porting projec= t >> to the new SOC because I want to contribute to the popularization of >> FreeBSD. >> >> -- >> Yours faithfully, >> Sergey Tyuryukanov >> > --000000000000facbc405c728591e-- From nobody Thu Jul 15 14:53:40 2021 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 F39FC127CA12 for ; Thu, 15 Jul 2021 14:53:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQcnm5Jj6z3rbS for ; Thu, 15 Jul 2021 14:53:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1626360821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bf5w6bhdBIK50yWtJkmFSAL/kj35R6uSxgtyCObWWwg=; b=TcIgUneSvxq0jlThWQgWRGV40B+IVzH9+ApMHOd5+OFKAwpWMhisgWn+Cgp5h1vVeB3zER ng5GHKiz//o0CucFvdzbJwV1eazyeLwz8XWOAgJn9tp395/tTNQTy+e+5hmv0d177YBmHB ZEr7UJfwlXN44eev7iF/GJiAOydhmP4= Received: from skull.home.blih.net (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id f9a3d7a9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 15 Jul 2021 14:53:41 +0000 (UTC) Date: Thu, 15 Jul 2021 16:53:40 +0200 From: Emmanuel Vadot To: Sleep Walker Cc: Free BSD Subject: Re: FreeBSD for new SOC Message-Id: <20210715165340.bfc0e3ca57f841ca7ff13d79@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4GQcnm5Jj6z3rbS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 15 Jul 2021 14:21:53 +0300 Sleep Walker wrote: > Hello FreeBSD ARM community! > > I would like to discuss one issue. > > A lot of devices have already been sold in the world on Amlogic processors. > These are SBCs and VIDEO consoles. > But they all run on Andriod or Linux. No FreeBSD support ;-). > > If it had been, the user community would have grown a lot, FreeBSD would > have grown in popularity, and the number of testers and committers would > have increased. I highly doubt that. If that was true we would have seen a number of new commiters ~12 years ago when we started to add support to armv7 and later when we added arm64. > This would make FreeBSD for ARM even more stable. That would certainly make FreeBSD driver less arch specific (even if with Allwinner/RockChip/NVidia this is less true) but not more stable. > What are your thoughts on porting FreeBSD to Amlogic? > Such attempts have been made before > https://github.com/tomtor/image-freebsd-c2 > NetBSD supports multiple SBCs on Amlogic > http://www.armbsd.org/arm/ > Why don't we add this support too? I can think of a lot of reasons : - Back in the days when I started doing some FreeBSD porting there was no public TRM for Amlogic SoC, I think it changed but I haven't checked every SoC. - Even with docs you will always hit some huge blocker and : - Porting takes time, a lot of time. We're still fixing bugs for Allwinner or RockChip. - ... > I know several Chinese manufacturers who would be happy to send samples > of their products to developers. "Paying" developer with SBC isn't a good way to make things happen. > I recently received a RADXA ZERO on Amlogic S905Y2 as a free samples > https://wiki.radxa.com/Zero/hardware > https://forum.radxa.com/t/introduce-the-radxa-zero/6550 > > It is a very interesting and tiny device, it comes with Android > pre-installed on eMMC, > not even Mainline Linux support yet. > > I've been studying FreeBSD for ARM for two years now and really want to > learn > add support for new SOCs to FreeBSD. > > I now have 3 SOCs to add > 1) Pine64 Quartz64, > 2) Radxa Zero > 3) First Russian ARM SOC - BAIKAL-M > https://www.baikalelectronics.com/products/338/ > > In all three variants, I have the necessary equipment. > And I have a great desire to learn. > > I have already written a USB driver for BAIKAL-M and am successfully > booting the system in multi-user mode. > The results can be viewed here https://pkg.personalbsd.org/baikal/ > > It succeeded because many devices on BAIKAL-M use fixed-clock and > everything is built on DesignWare IP. > > But I stopped at the need to write a clock driver necessary for Ethernet > and PCIe to work. > > If anyone would agree to advise me, I would be extremely grateful. Read other SoC clock driver. Clock drivers are hard, they always were and always will be hard. Not having docs on the clock api doesn't help for sure (and I need to take time to document that) but that didn't stopped others (me included) to write clock drivers. > I am willing to provide access to BAIKAL-M but ssh (since USB Ethernet > works) > for easier collaboration and learning. > > Any help or advice would be appreciated. > > I am extremely interested in participating in the FreeBSD porting project > to the new SOC because I want to contribute to the popularization of > FreeBSD. > > -- > Yours faithfully, > Sergey Tyuryukanov All that being said, I don't really see an interest for Amlogic over say Allwinner or Rockchip. I've never seen the interest in adding a SoC/board just "because". What do they provide that other SoCs can't do ? I suggest you start by doing some work on drivers for already supported SoC, it's way easier and that way you will familiarize yourself with FreeBSD kernel interfaces. Cheers, -- Emmanuel Vadot From nobody Thu Jul 15 14:55:33 2021 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 3241B127CFDD for ; Thu, 15 Jul 2021 14:55:35 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQcqp6nW5z3rxk for ; Thu, 15 Jul 2021 14:55:34 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1626360933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w3ByLyx7mH7ckE0tJ4qyjBPIJEyQ6BcxW2NUHik3Rv4=; b=sxuwCa1fX/boXRk8pGfOrp/vrCqYAS3AbyGUtDhfgVR58DfydslL/ymsOuBVP5LAfzMg50 6EtRV2wE7OM0hs3E3c9BSvkqnH2khTq5oEPeNuSERHjLRFUtYHusEyqF8u0s3mO6ZbjVv7 6IsJmIul/rbfhoj1YfEnmPHrxGTyO/E= Received: from skull.home.blih.net (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 25a35eb9 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 15 Jul 2021 14:55:33 +0000 (UTC) Date: Thu, 15 Jul 2021 16:55:33 +0200 From: Emmanuel Vadot To: Sleep Walker Cc: Ganbold Tsagaankhuu , Free BSD Subject: Re: FreeBSD for new SOC Message-Id: <20210715165533.cfe9cb32bf767ff9e18599ce@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4GQcqp6nW5z3rxk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 15 Jul 2021 15:09:11 +0300 Sleep Walker wrote: > Yes, I know that, I will try to experiment with the old code Don't bother, it doesn't support clock in a good way, that's mostly why I've deleted the code. >=20 > ??, 15 ???. 2021 ?. ? 14:43, Ganbold Tsagaankhuu : >=20 > > > > > > On Thu, Jul 15, 2021 at 7:23 PM Sleep Walker > > wrote: > > > >> Hello FreeBSD ARM community! > >> > >> I would like to discuss one issue. > >> > >> A lot of devices have already been sold in the world on Amlogic > >> processors. > >> These are SBCs and VIDEO consoles. > >> But they all run on Andriod or Linux. No FreeBSD support ;-). > >> > >> If it had been, the user community would have grown a lot, FreeBSD wou= ld > >> have grown in popularity, and the number of testers and committers wou= ld > >> have increased. > >> This would make FreeBSD for ARM even more stable. > >> > >> What are your thoughts on porting FreeBSD to Amlogic? > >> Such attempts have been made before > >> https://github.com/tomtor/image-freebsd-c2 > >> NetBSD supports multiple SBCs on Amlogic > >> http://www.armbsd.org/arm/ > >> Why don't we add this support too? > >> > > > > Amlogic support was removed last November since there wasn't anyone who > > could maintain amlogic related codes: > > > > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D367993 > > > > Ganbold > > > > > > > >> > >> I know several Chinese manufacturers who would be happy to send samples > >> of their products to developers. > >> > >> I recently received a RADXA ZERO on Amlogic S905Y2 as a free samples > >> https://wiki.radxa.com/Zero/hardware > >> https://forum.radxa.com/t/introduce-the-radxa-zero/6550 > >> > >> It is a very interesting and tiny device, it comes with Android > >> pre-installed on eMMC, > >> not even Mainline Linux support yet. > >> > >> I've been studying FreeBSD for ARM for two years now and really want to > >> learn > >> add support for new SOCs to FreeBSD. > >> > >> I now have 3 SOCs to add > >> 1) Pine64 Quartz64, > >> 2) Radxa Zero > >> 3) First Russian ARM SOC - BAIKAL-M > >> https://www.baikalelectronics.com/products/338/ > >> > >> In all three variants, I have the necessary equipment. > >> And I have a great desire to learn. > >> > >> I have already written a USB driver for BAIKAL-M and am successfully > >> booting the system in multi-user mode. > >> The results can be viewed here https://pkg.personalbsd.org/baikal/ > >> > >> It succeeded because many devices on BAIKAL-M use fixed-clock and > >> everything is built on DesignWare IP. > >> > >> But I stopped at the need to write a clock driver necessary for Ethern= et > >> and PCIe to work. > >> > >> If anyone would agree to advise me, I would be extremely grateful. > >> > >> I am willing to provide access to BAIKAL-M but ssh (since USB Ethernet > >> works) > >> for easier collaboration and learning. > >> > >> Any help or advice would be appreciated. > >> > >> I am extremely interested in participating in the FreeBSD porting proj= ect > >> to the new SOC because I want to contribute to the popularization of > >> FreeBSD. > >> > >> -- > >> Yours faithfully, > >> Sergey Tyuryukanov > >> > > --=20 Emmanuel Vadot From nobody Thu Jul 15 20:48:11 2021 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 B686A1275E0E for ; Thu, 15 Jul 2021 20:48:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQmfl37cpz3wPj for ; Thu, 15 Jul 2021 20:48:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626382093; bh=VdWIVLrJ17QlNtc/C3DlP3OWmO/G9LxjEUV2/WYuSaI=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=rIQSUsue+8s0CYlCWJN4YyzpHrfkOwomE7AOXxJeTEbwrXV2BR2MmRTsCn/1qmAYODs/2pLJQbdmLJnKnZA2cI3eXdbUrtA9SgjTi5JhuiGeGrA6Bidc50YBkVUg2DryyQyQUI+SytWtTaQZ+lTKjDneJeihrosuMlJNnaQFb9xvRzFYdlfaM0wlFrfopkp7tntX+Qkbm02uGWzi39tEtSkfY/AlnaIy62hrktEdTH/AqkK+9khL7SM3484bfxjSsnxyFKNPdlNXbe6yH/6Am/Z3R96l43F0Cnu7EHPYwZVGfAU2KF1uJH8ttbj2bRdbv1UKBpgrHItKUJuxWJVCCA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626382093; bh=YJkildxwmQmShk14pCXwhNM7YQG1OpGLxbG4d0zOtRu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Tn40p6gpfPrAE575H/gtboaQeqdXwp5DsuPlRWx3fYa/rynkJ5LUx0PdfNGn2dRRteY4BPuNyG6jv6cwCcI5C2ZKoRzLgknDkhR1YU/tc+DfJDsARiBtPxaJK3UHjiloNAScq/4Prx2YAuGdRibWdBnDHpthSjZ+xGjKWZpPQY5jZAh7yortU2IrWoJpVtgxWWLEaR/7IM2N3CRYqlYf8zVfkyGKi8jd4BUQGwKKTnvIUxfR3lkHxBd97rZwCWAP/8Uw6Yfhm9lfJUMFN0x3ObSQYn7Z7+sYND+D//iAfWxoOPR4xi1/ObCcI0DeeqOvIQO1Y2ze7Khx0YzOKYn6RQ== X-YMail-OSG: zvGozTQVM1nGR99.ZcfYXLc8pgGWgoE1I62xCGrj3pM8A7hC026rNIAgp51SboX Yw9UzsZoamCxlOpDQIAFsAlKhL_43XFiz4rT2htqiFeK41.39LaZtNJpsOCNAUVn_oVg8mGq8zGN NaINpfJz3AlW9cMzxV7aX.q.s3XLeC.aeVEkODV0e053SxG0fax0NBEqpOtCQqvqofz.uzW8aspp ouNcU5wfRk34PIaaLuk_QcBgPWKRQO7GHWCH9iZcGQAA8UZDUsMHH1uNQMk7KDu6_STIALSx72yt c1PgLoa3HWWv1H.5d940hlKRwmYNmsDUvGa6gS6pCQ2UGlKSS_MX5vW6Fl3y8N9FTl_.yUHXGOZI 8ZxuovIFQntWb_YmDTTOaZyDxzRo1QJV3PNISwhjRmo8AqGkkk7bsMZsIS9Hk4Ndxy620oG_jxuZ V4lqSPHOyEQz9JAG8jBH33HkCYwbEVyH908FDckphxxYqow9YSlWRbUUTZN0ZaKlGXZDkXXvL.5D r2B3hLmM_8UfiDrHI2M0MaNFacOx0MABcYv.2rGKX.IfNy2CTlvUHKYQAyEsH7PprgAmoFvriru0 d_3VjU7t4n2eCfYzIENeuImUXOnHCHg.owQHBGfMS.PhAIjQHi6PaNv_qL5a2ItpMAP1tZocUpYj S6bqfWO68KWXjwXGQfH.xFB4tiQBpYqSdJ7chVJNgVnyRTcWnof6rq9jMUxKN1Xl56PMjXA5ibgC jZ9.brimxsd0kH72HXnjSCQKIcyyRtMmv84E1TeufKVlC9Uxzat77GtzSBeRJEBnM0URRrU.kPwd SLNbYB8wwdw2IqQVZ8XJPItXq_KwaPY2QjHa2uzHP5SkxAjjcUEaI7DvjqYbuLxvDfOm7VhtZYkJ 59E9qWB.xBsXeiP8ytCSm.hOQFjgn7AFFGF_3s5mO8GJADOGvZXT.UaRpQIWUYyVTk3i2rMfieCn mkUPUa9bq.CDvpnUqq5B4IZpZLjvAaGk3qcfWuxx5WdAUBVE8glguzVOvewig0uoiEJJN6Uyc_pQ R4Rvlp0XOT5MHukblRaEOrUM0s_DEn4CSbZClWCgWD1YHa0QmM2nesIy_GB8Ob0hat28zpf5rjqX lTZu2SoRN4B2MTeuTjAQQcMcoNzdbOTKxpzngs3w1xmduQzKALjdWPotLL8SxiEqczxUJHCh9gpP InBwFU0r8UiKEp._VcnHf9Bw0dwSuA109.RBlbfYWQdypFhKJGjcr4xY42FT1kavg.vQmVQo7D75 gyKSdGHn9Zs7ni7GMOuAv0umWmu1VknB857S.d2h2XWZvPbpr_l8tVGg5sWtFxsMKHA2emDTRMvI kDEmtTnXc6VeJoF6JUpCGacO7mW8fArImruQUQtrSaR4djcLTqx_rWRzo2IJVMr9bDTIjJwMM1yy UEfdScG62v7tSkcepRz0h.BmLE7AndqSwNUNGH5d60DlC45YwfFe_hILYdjox_e532OdnURDuZLf Lo8b22.lXjCldr7bBX96kmMMvaWiUbFERo.3vta.TwI.9DJJl.kyRzQMbOQQkSIMbXUxtcA7pFym wxOqjY7.iN5aS7qp1gTogVKa_A2v55QEZvRwAIJN8JF6oozbfr_Eg0G4_burpQNmaN1r4GBjYn9C 8o.LxZgk.dh4lWsI25.IkeselYYQD2QUQa3YXq8tbpu7xXzUMaxKNrPXyJ_y7JuIDGwhykVTqS5k phUIgDrCCs21QXPRkoYytEIoAu0fAUJEx8ie_YnLkiODykP1VI8Gdynf.tp.cgE7drVCvv41Bk2U .xbq_yAjUVWzkaTRqQOqHKrCLuQa55hvwV0x24P6YLlTY8kXRrGLh3J1PtUIWRTChtPsrhtqkriy p3BZNRXWibr_XiFbWc2JUxKrkyIKS1NmBv0vXeZgXw2BrvCFP4yTJ21g3Vj38rLCUlIm7CUFRCdW Vk2DGs73UDqquzWTGJjR0SL5b0h.O_OX.C2hmV8w.qPK9FiC0tyabP_ns8CVbTbl3UZyhkknxW58 TF0gx7pBdyyZHrU1zX0TAdrjl31aAUs8QGuinYw.6kd8JmEFfAAXLcrdi8ycY7UlUvSsCqmeVBPg zQR6VhV4x3OOLDVbMU.2pBrS_MNbKbQ.TowlXwckVOdK9qzbPUkwt_Af4dJv7w3a3jLI6vAfX7YC cNphZqTiHxfl4JYb3orlELzXQTeqwzTemMgTb9T6nskFC6i_dSbIsXQlMP6IJc_PkNENl.BNoKf_ WmE.pQwGh3pQvt1SSctHgY8ROM9hwf.GtHCmmXoCgHvMBYH5eZsgI8_g_asT2fdHWviJwjlO4EtC n3ldnDJGVrGCcf9sRk4GtNuCrrGdIvGB12vMH_SlofPwesEsrdGuonjihuQwGVGI9K8.Bb0P4VhO D6RqEA7HecPbTx0_.pBJg0.lYV5BALeAez35DCWqgxi_j6oidVL_zy8BWhbK_rXL4FoQO.v7ucyf mDJFDtb1jBNwEMlKLZDCi_FnB4ENN9d1DtuMJ700cuW_n6riSSKY0fluAGhsTLJ1JcaREIgY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Jul 2021 20:48:13 +0000 Received: by kubenode536.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 942a22b367400cd569665d0b60b5c35c; Thu, 15 Jul 2021 20:48:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: HoneyComb first-boot notes [a L3/L2/L1/RAM performance oddity: fix identified] Date: Thu, 15 Jul 2021 13:48:11 -0700 References: <8A6C415F-A57B-4F2F-861F-052B487166D6.ref@yahoo.com> <8A6C415F-A57B-4F2F-861F-052B487166D6@yahoo.com> <40AE6447-77AF-4D0E-864F-AD52D9F3346F@yahoo.com> <12A4EDD1-A2AB-4CE3-AB0E-A4B5D6FB4674@yahoo.com> <5B1B5E1A-8AE4-4889-ABE6-50C206F896FB@yahoo.com> <7DBDC8AB-C80B-4E26-B58F-251A3D29CE41@yahoo.com> <5BBF1B55-F02C-4817-B805-677EDDC5B809@yahoo.com> <0B577668-97AB-44B6-B1A7-C68F6CC299E5@yahoo.com> To: freebsd-arm In-Reply-To: Message-Id: <10364E05-8BCD-4A15-9D3A-CB5DD9952AED@yahoo.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GQmfl37cpz3wPj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rIQSUsue; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.148:from]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[98.137.64.148:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-11, at 18:29, Mark Millard wrote: >>>> . . . >>>=20 >>> I've run into an issue where what FreeBSD calls cpu 0 has >>> significantly different L3/L2/L1/RAM subsystem performance >>> than all the other cores (cpu 0 being worse). Similarly for >>> compared/contrasted to all 4 MACCHIATObin Double Shot cores. >>>=20 >>> A plot with curves showing the issue is at: >>>=20 >>> = https://github.com/markmi/acpphint/blob/master/acpphint_example_data/Honey= CombFreeBSDcpu0RAMAccessPerformanceIsOdd.png >>>=20 >>> The dark red curves in the plot show the expected general >>> shape for such and are for cpu 0. The lighter colored >>> curves are the MACCHIATObin curves. The darker ones are >>> the HoneyComb curves, where the L3/L2/L1 is relatively >>> effective (other than cpu 0). >>>=20 >>> My notes on Discord (so far) are . . . >>>=20 >>> The curves are from my C++ variant of the old Hierarchical >>> INTegration benchmark (historically abbreviated HINT). You >>> can read the approximate size of a level of cache from=20 >>> the x-axis for where the curve drops faster. So, right >>> (most obvious) to left (least obvious): L3 8 MiByte, L2 1 >>> MiByte (per core pair, as it turns out), L1 32 KiByte. >>>=20 >>> The curves here are for single thread benchmark >>> configurations with cpuset used to control which CPU is >>> used. I first noticed this via odd performance variations >>> in multithreading with more cores allowed than in use (so >>> migrations to a variety of cpus over time). >>>=20 >>> I explored all the CPUs (cores), not just what I plotted. >>> Only the one gets the odd performing memory access >>> structure in its curve. >>>=20 >>> FYI: The FreeBSD boot is UEFI/ACPI based for both systems, >>> not U-Boot based. >>>=20 >>=20 >> Jon Nettleton has replicated the memory access performance >> issue on the one cpu via a different HoneyComb, running >> some Linux kernel, using tinymembench as the benchmark. >>=20 >=20 > Jon reports that for HoneyCombs older and newer, EDK2's older > and newer: All show the behavior on cpu 0. "[I]t may have > always existed." >=20 > Jon also reports that U-Boot based booting does not get the > behavior. >=20 > (I've never used U-Boot to boot the HoneyComb for any OS > media that I've got around. In my U-Boot ignorance, my > quick attempts failed for FreeBSD main and Fedora 34 > Server media that I've been using with EDK2's UEFI/ACPI.) The problem in the: lx2160a_uefi/build/arm-trusted-firmware/plat/nxp/soc-lx2160a/soc.c code has been identified and my testing of the proposed fix indicates things are working. Some very early code setting up the L1 Data prefetch configuration was depending on not-well-initialized memory and an initialization routine needed to be used a little earlier in the sequencing to avoid that. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jul 16 00:40:01 2021 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 1320112A1B3B for ; Fri, 16 Jul 2021 00:40:06 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQspF5Tyyz3JyY for ; Fri, 16 Jul 2021 00:40:05 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 91968721E2825 for ; Fri, 16 Jul 2021 02:40:02 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 14.0 \(3654.100.0.2.22\)) Subject: register x18 Message-Id: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> Date: Fri, 16 Jul 2021 02:40:01 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4GQspF5Tyyz3JyY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; local_wl_from(0.00)[freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Dear all, register x18 seems to be special. What is it used for in FreeBSD? Best regards Michael From nobody Fri Jul 16 02:06:47 2021 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 23A311243596 for ; Fri, 16 Jul 2021 02:06:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GQvkQ5rWQz3nLx for ; Fri, 16 Jul 2021 02:06:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626401212; bh=ozvy6KOUSmyEppdK7gg5zwVaWhcLljhIlEKDybSMdxA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fETEYiMacUr37nSFc9u+TaAU2sgyRZljYM8zlfJ7w/ujQuLa6uJeGYRLOKCfj/Fl/lpG49saMcRQfpSAlNPhdISc+57rJrj91ih2kFj8z2jfiLoZT59JzS6//x1EETBrhGz0bJ5p3Bes4S2E1gjRR1iXcis9hwKsUNrjB/QHDxMhDMOD4yVmx6c0fLFGHcFunfkgHw/GNfLHTi8SItBUpKtWQ4Dhlgm0UoOwZrh6xpAjk6/IUwR+cgBOHFMQcJ9uie1YOkB0BufQa1ioDbkMhjRr6507M1pJeGWtD/YMxIEflgFTvqiufx8QxzK8aBFWHTd6qVKH6Y13MauI1Xl6EA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626401212; bh=UfFXEcpFImqzRcV8jeiUNKJQlyWILqT4X5EBGkc0y+j=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=do04vLuOldqzfSyfPNNEinizkHP5lPf1Qe88Gds6Davzfe03HOCBC6sfvnRnQEBF9AY5K89q3itqMHCEJ2ST4K077lvV79nX1vjbrO/KJGuM+gLp8hGE81mqAc6c5d1xao4B6sLAkXY0mztQJJsZnCB5C/VqDHKt7UOlp51dn709oEbd8YKpIY0fegv0Rjmz+FzcWRR9oHOrRgb6nG24BiNgED3iORBSAZ3DsCDzNayvzupqg62ZYIhnQB8kuVMIGfltw/f7rabAgFgG05O4StnyaY14QPnu4b/4AcvBSdgJckVQcpZdtBdWK7KANxkVH5RVia9NWk7kDdpLar/LMw== X-YMail-OSG: UIufG2wVM1k_qE8vlWkI5WJFZ8SuEByqh3es2pkgCS3zpJPOR9XU0LW2Oql4mua J1VnMvJ3b.G0xsxYV_Dxgwx4b5w8r5C5P7.UcgHxKlds9HMySEAtA0V3vsvNQ3rpa204taFizRaj JGSXCllrb_VUDT50GpPRqPREao9wQhYNMuQSOipKO_IOlbgyUdcvUN5H.or3GMAJAbKepxSsebbp toHpSgeEq5D26HekuywvHcbhYjlsMXvClPEkDlZwcSx0DO_X4.mrrE_8Nhp6CQQv_6CLIm6Q4oi3 3VZVPUDwl4NC.M7xAvNc3Vw6zO3A8XIFPM8YLgtmE2QxiM6E2aGn0fwrSPWKA0nbWW_3.ipS8BjN IILDxr6qEDP1TF2n1vJYnkgoVbGQSe1dZSBDE5o8rT8M_pV25tOnLjAFCl0DsJhaY5U1gaNzbRPQ RWwWbZ5K5pJSXaoiLg1eyYAECLEPWoMH1UutmragyH9h8zpENcqPVsmXDh4rX..fQqo8Q595lVfq DzwiLuuiNoo4W8SFyihNVs2j_yc9uJ4xUsyH73702tPmGRvFTMA7fnEyvVUvAwt66mWQO4F2xpwZ D3YE28uovnlsWaetaU5Iga6XCD40VaEFDENAZVaZ4Vh91znJEgzUU1iK0g8u7XdbUC08H2393TzF x8vsJXJ5Os9MoGxA6wLqjEcK2_k234BmRCMByt75.j6Z8SU8q.BhzeCJeoEQXP1qpeXpFiD0DJUD wTidm004oID5eGZdsdC30gNE3ei7DIuIe8LTJmJWbUw0rMpF8CZOSyE3uq4DVOEdPcEcS21Zo1IG WZElOl70YIQOUTL7L9yjWHtZg5dwLWE.39TVyrqIg7b41ImtxNxybpGQNbHbtvHMpxvWLucuF_h. K3DvbZFowyK7tcPlLdNPatJxMwu_6c_nwpZWx0PWrpVBYMqwh7flJzqyd_25z2TaNdbfLA0xk1K2 lmg_bho1Ub5bQ2.5PbgFGcqmGBjVbhP5sOMsvtBXTVg0bJQLYgYUewjZm1vJKp.L5T5X51UY4.VS 0wIM2iRPEBxZcXayRu81WQqD6dH6uGK_PvO68_133ASBmtEm51n.rr261PUbTONfb6qSi2rukRz_ BW3X2vXY4K1aQc2xe3XgRL.sXnjJm9GlMKzHmUSFeIc7nLc_jXZqSCs8cq3AJc9zM4EynrpK9Zvo drHz4uZm_aIfV5.VXoUI4zSiOTYaZtvKqYrnY4lWGvPlFocUWvbyaPWSkZger12ZkKAEkovGa6aU Gmu5b_SzAVynR9mxlZvRSklsOH5B9rabgPf5ur0rIuFEH0vyIDQDh4OBeoRKH11G4zKpD59_ungq 7AyKIVYPj5VB2ZIA.XhlsOWYmAcqWJT14q.Nkw2tEsqu5qBWWSZHcehX6OPUpEebGMzuzj.dlzX2 ucaOFTwObXeNGvHv.4zFxHlRWw6Ya8maHimP1zZMdZ4Isb2ghtIzS9qi9BVlR3mjs55Kf2PTyHql uRjntfPq3oVtKBL2eY1wQA5RKFeLAmQVBq5_.UZj5iEVUOyo3dk_psWlymqVdkiOQGctx1vF2wWO 1JNMlP2H0q_Nsh9Va8YlQzyuPQxXhKdImenOqXj3Q2HvuXOStPbr1fzv5cqgj3hXDQ2hGgXDCeIQ mJ1fZo29fJiWGyMwA3_jI82ma9b1hAJof5xygXw2SZ.DHrdajvfuPwnXKW303_qKue1smFvyZwTR tDT1EFmZKzutpGjhdVIbNq5H07HifBc2Fe2t_oxgBvstVwbiTUVPMnVHfU1pHAojRrDhXRWXfhfs lVe9zLxM0JA1CNnr_I50JKG4XRZ9bdvnhuXqP_R6zh_EFC89Qxe23KJmpsiFLrJkeVuXsGHY5kIC XU4g.iC4XhwYm1h0NnqUIBV6YHd7jsurs4CIkP3MGGJ.uV13K2TYjBYeqgdUB6_ZCMl0pIjIufxw LTiBL8Y4V3bozFkM3djETJcYoEDmD89njg97anwsAL_iDuGpePWk5jiLjtNXigpUT8NMhNOr9c6D bu3Qmjxdsxq3dfHsm2sJWlJRe1Zhh3zzajzSRIZZqZWiY3hmk1dSyhqQOXGfrMd2Dp3ZYbIkfrq2 D9epXaP7QmrBuqcCq83sZdNeMSQUH_zrdq8HWZciXjfBCTHUZHnI4myQbFl8URrSfjRmchv56ag_ 6IRX5yHpAas4pkpp09sQMAO8rkJ9TNWfa6U5n0Mx.EYVLWpBoeYQDqLKHeqE0Kr2uxByxNyDNB5v v0XHlzROx4aobc3G.G8yXBBBTP3ESyQolG85FFNpK6mAmpqR42CKf5QPxgKIVtsRsl16f3lnSe6L Q_MsWUHS061mK14ZVxRl8_iTvLIOEJXE9dawHB02qJHQdJUsE4DV8h2ZPUdw2MwaAEdxPcNNXIpF YM.P2FwrNK.0zDLSJgHZpjPgxDn_3OVdW_hTqEcSnLUuYs1wvN9A81jvIVBG4dHoI0liU0e9yE6r uv1rb49qt.DasHFDJr8zUg1CKJrWOfqyNPF94t15na93CEhBJ.tdHcMFuZ24pxZ.Osc38aqmfIQ. G5ofOu4IqHcwoPsFIkcF80r8aNR9zWbZPX1Z93Ihavx8X8PVNCDU2MhXvM_jIMAJTlIa35R44dSc Y0.Qc3HYRbIZ059LjECjLXYC.jaKVmCo.8gV9VZ7YeSAF4RSetC2igUO5PQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Jul 2021 02:06:52 +0000 Received: by kubenode577.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d11cf7f663a5c70f7a2bf89ddd6fe8a9; Fri, 16 Jul 2021 02:06:49 +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 14.0 \(3654.100.0.2.22\)) Subject: Re: register x18 In-Reply-To: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> Date: Thu, 15 Jul 2021 19:06:47 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> To: Michael Tuexen X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GQvkQ5rWQz3nLx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-15, at 17:40, Michael Tuexen wrote: > Dear all, >=20 > register x18 seems to be special. What is it used for in FreeBSD? >=20 > Best regards > Michael = https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-A= rchitecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters= -in-general-purpose-registers reports: QUOTE =E2=80=A2 X18 is the platform register and is reserved for the = use of platform ABIs. This is an additional temporary register on = platforms that don't assign a special meaning to it. END QUOTE So, special, yes. But I do not know what the "platform ABI" usage for it might be on FreeBSD. So, for the most part, this does not well-answer your question. Sorry. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jul 16 07:39:50 2021 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 6FBCD8D4243 for ; Fri, 16 Jul 2021 07:39:54 +0000 (UTC) (envelope-from SRS0=nAK+=MI=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 4GR36d30vgz3h3v for ; Fri, 16 Jul 2021 07:39:53 +0000 (UTC) (envelope-from SRS0=nAK+=MI=klop.ws=ronald-lists@realworks.nl) Date: Fri, 16 Jul 2021 09:39:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1626421191; 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=sioBEfxKr9iKY3B/FrxWkpLu5iQsEUfO5q2176V3xWA=; b=qHihFL+3Qz+EQBbJI/PJdg8tUbaaJzXQ/3NlL7RAXU/nJ6FKJlPmkFlHX47aWPkPcO2U+T pQCVpz6wVyqpFc4W1pPXMQRyz1RvlI7vdrqvdxSLMgLCosnDP3fZFzd/1dPaShJIB3+Rss gBnoh6Q6icKhhldUGolnWF0JImt0ZG8wwptFWKPTue40DcfZgDVocwmHhSA2F/cJyUp0+Y GGHBG2ksUEPZ4oHbSQKD84Xbg3bB7EwmLm5ZWc18eLzINiMirFLWQ7WZfFCzTLCNoO71R2 QRipFOVYc0ptASPWqNU1nPk3LCewijX9qKJ/wzhVHi2QFSWCxfZZK9PsB9YU/w== From: Ronald Klop To: freebsd-arm@freebsd.org Message-ID: <1013702052.4.1626421190068@localhost> Subject: Assertion failed since clang12 (mongodb42) 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_3_670410470.1626421189988" X-Mailer: Realworks (569.1326.4c8feb162b1) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4GR36d30vgz3h3v X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=qHihFL+3; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of SRS0=nAK@realworks.nl designates 194.109.157.24 as permitted sender) smtp.mailfrom=SRS0=nAK@realworks.nl X-Spamd-Result: default: False [-1.26 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_MEDIUM(0.94)[0.942]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=nAK@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[=MI=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=nAK@realworks.nl]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_3_670410470.1626421189988 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm maintaining some databases/mongodb* ports. On aarch64/14-CURRENT they started failing since the llvm/clang12 update. See: http://www.ipv6proxy.net/go.php?u=http://ampere2.nyi.freebsd.org/data/main-arm64-default/pf44e1c1de734_s63ca9ea4f3/logs/errors/mongodb42-4.2.14.log And look for: Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file /usr/local/poudriere/jails/main-arm64/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 269. This does not happen with LLVM 11 or on AMD64. Can anybody point me in the right direction for fixing this? Regards, Ronald. ------=_Part_3_670410470.1626421189988-- From nobody Fri Jul 16 07:43:58 2021 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 C135A8D54D1 for ; Fri, 16 Jul 2021 07:43:59 +0000 (UTC) (envelope-from SRS0=nAK+=MI=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 4GR3CM13jcz3j95 for ; Fri, 16 Jul 2021 07:43:58 +0000 (UTC) (envelope-from SRS0=nAK+=MI=klop.ws=ronald-lists@realworks.nl) Date: Fri, 16 Jul 2021 09:43:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1626421438; 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=D/PunhRPv1Vnqm7yWG5RZFZVt+yRbvg8vHYho4frZQE=; b=zlV6pxAC1bjm0DPkXUjoI5LADiOoKSEWTuFlS5NH351guuk5I5H/1ohqIi3TcJWbcszKye zc8gEocFvjcEMPbkjK9nPkPiT7RIkIzwjBvT1VuTPWITEljEVWuX6gvjyYOnZ9rPO26Pxd NMxt8hwzhsH94OfkrxIhmHxk7zA8PY2YPs3lgPq2VjmWNgYOoLzNt+5dXuUNNHPu0u3Skp WjA4VD3MUhUg+RXe6fNw8g+VRi6MSUZU7LYlko54DhH9+AQfMm2wn1+xwXeTl/ePo7r23+ rviZr3KJR6lsJgh+ywaTeajtRrJAsLHb41paM2Mb/uyTTdmsrColrb7NETaWow== From: Ronald Klop To: freebsd-arm@freebsd.org Message-ID: <561167089.7.1626421438153@localhost> Subject: undefined symbol: __aarch64_ldadd8_acq_rel since llvm12 (mongodb44) 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_6_804470015.1626421438148" X-Mailer: Realworks (569.1326.4c8feb162b1) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4GR3CM13jcz3j95 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=zlV6pxAC; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of SRS0=nAK@realworks.nl designates 194.109.157.24 as permitted sender) smtp.mailfrom=SRS0=nAK@realworks.nl X-Spamd-Result: default: False [-1.25 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DKIM_TRACE(0.00)[klop.ws:+]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=nAK@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; TAGGED_FROM(0.00)[=MI=klop.ws=ronald-lists]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=nAK@realworks.nl]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_6_804470015.1626421438148 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm also maintaining databases/mongodb44 and this gives undefined symbols since llvm12 (I think). See: http://www.ipv6proxy.net/go.php?u=http://ampere2.nyi.freebsd.org/data/main-arm64-default/pf44e1c1de734_s63ca9ea4f3/logs/errors/mongodb44-4.4.6.log And look for: ld.lld: error: undefined symbol: __aarch64_ldadd8_acq_rel There are a bunch of similar symbols not found while linking. This compiles fine using llvm11 or on amd64. Any thoughts or suggestions? Regards, Ronald. ------=_Part_6_804470015.1626421438148-- From nobody Fri Jul 16 11:08:55 2021 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 2E6498D49BD for ; Fri, 16 Jul 2021 11:09:00 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GR7lw0G7Zz4jQN for ; Fri, 16 Jul 2021 11:08:59 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 22AD6721E282D; Fri, 16 Jul 2021 13:08:56 +0200 (CEST) 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 14.0 \(3654.100.0.2.22\)) Subject: Re: register x18 From: tuexen@freebsd.org In-Reply-To: Date: Fri, 16 Jul 2021 13:08:55 +0200 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <32C24DDC-C8A1-43CD-9220-8009B229E452@freebsd.org> References: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> To: Mark Millard X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4GR7lw0G7Zz4jQN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 16. Jul 2021, at 04:06, Mark Millard wrote: >=20 >=20 >=20 > On 2021-Jul-15, at 17:40, Michael Tuexen = wrote: >=20 >> Dear all, >>=20 >> register x18 seems to be special. What is it used for in FreeBSD? >>=20 >> Best regards >> Michael >=20 > = https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-A= rchitecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters= -in-general-purpose-registers >=20 > reports: >=20 > QUOTE > =E2=80=A2 X18 is the platform register and is reserved for the = use of platform ABIs. This is an adional temporary register on platforms = that don't assign a special meaning to it. > END QUOTE >=20 > So, special, yes. But I do not know what the "platform ABI" usage > for it might be on FreeBSD. So, for the most part, this does not > well-answer your question. Sorry. Yepp, I found the above text. However, x18 seems to be used when = accessing global variables. I am looking at a panic, where the system panics on = accessing global variable, which can be controlled by sysctl. It seems that x18 does not have the expected value, but it is also not = set in the function... Best regards Michael >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 From nobody Fri Jul 16 12:51:33 2021 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 3F627127D68E for ; Fri, 16 Jul 2021 12:52:12 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4GRB300Vhtz3LNB; Fri, 16 Jul 2021 12:52:11 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.1.66] (67.red-83-54-23.dynamicip.rima-tde.net [83.54.23.67]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 9AFDB4E729; Fri, 16 Jul 2021 12:51:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1626439895; bh=9bvieHEsz5FWVgK/+atmXlPZubyDizWWwuZL/d7w1eI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ulAWqpLJ6PlmEmFjCbq3GPewBT4nr8fc+oGLqf2cc4zxdy13vHsAJe1SKeKaoQrwq RTlRbMNRY2yURsxKAMPpPVJbJJuXR1iuuH8QfQd3oP5fATg/X3RjnoSR0Py3GsMNT4 VpXLQ3RMvi4HvGMZ/dsOtR0lMRuONTrGsV9W3SA45oCT1N9sQ2CPPg4u1lOgSN33D1 rdBiGs9kQxi7jBdEZaRZIxneWczSab4NVsGSMmC+mO/7UPJ05xspSLjeHvNocZ46et f4KWJtvndGGjwcU2wHNecRHPyHdOhXYxkp75OmJJ4fXzZme5bEIKot53C7kQBLok97 RxsHWQSTPkUmfl9028ypXYXMZ7P7AnwGGpmHEB3NOgzTIb5fgBmcSlKKmbAzL9GIjW me1bMjJeYtvvMCCF+BJDeDQnPO66tVS4VMi4olWO8R6dfGWpyE81WxfeNj1w2yPZUU boEqifZxAjN+m1iLrwDTReAe9lN7Uc//9gm6famMcCnPz0/yNQPALbN9Q9WK307nSX SzeNHj1lgOS1W1QRSSqfsMltR7Ux7vT7xj66OzvjCCG3o5nAdeO2ozfRV/LPXjLVMy DvOuamYGUH94hHz23EMHK7rQqwRu1lPQx3uYBnZ9YAzBFGxd28X/Q0IEcSKcgX4IrW V8126QHU4gVtc9PJE8O/ODrA= From: Andrew Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E2948D8D-109E-4D83-852B-ACC868B1F99C" 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 12.4 \(3445.104.20\)) Subject: Re: register x18 Date: Fri, 16 Jul 2021 14:51:33 +0200 In-Reply-To: <32C24DDC-C8A1-43CD-9220-8009B229E452@freebsd.org> Cc: Mark Millard , freebsd-arm@freebsd.org To: tuexen@freebsd.org References: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> <32C24DDC-C8A1-43CD-9220-8009B229E452@freebsd.org> X-Mailer: Apple Mail (2.3445.104.20) X-Rspamd-Queue-Id: 4GRB300Vhtz3LNB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_E2948D8D-109E-4D83-852B-ACC868B1F99C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2021, at 13:08, tuexen@freebsd.org wrote: >=20 >> On 16. Jul 2021, at 04:06, Mark Millard > wrote: >>=20 >>=20 >>=20 >> On 2021-Jul-15, at 17:40, Michael Tuexen = wrote: >>=20 >>> Dear all, >>>=20 >>> register x18 seems to be special. What is it used for in FreeBSD? >>>=20 >>> Best regards >>> Michael >>=20 >> = https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-A= rchitecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters= -in-general-purpose-registers >>=20 >> reports: >>=20 >> QUOTE >> =E2=80=A2 X18 is the platform register and is reserved for the = use of platform ABIs. This is an adional temporary register on platforms = that don't assign a special meaning to it. >> END QUOTE >>=20 >> So, special, yes. But I do not know what the "platform ABI" usage >> for it might be on FreeBSD. So, for the most part, this does not >> well-answer your question. Sorry. > Yepp, I found the above text. However, x18 seems to be used when = accessing > global variables. I am looking at a panic, where the system panics on = accessing > global variable, which can be controlled by sysctl. > It seems that x18 does not have the expected value, but it is also not = set in > the function... X18 is used to store the pointer to the pcpu data It should only ever be = set when we enter the kernel from userland by the exception handler. Andrew= --Apple-Mail=_E2948D8D-109E-4D83-852B-ACC868B1F99C-- From nobody Fri Jul 16 15:07:42 2021 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 0243D1272365 for ; Fri, 16 Jul 2021 15:07:54 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRF3Z5nLbz4S3k for ; Fri, 16 Jul 2021 15:07:54 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 67321721E2825; Fri, 16 Jul 2021 17:07:43 +0200 (CEST) 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 14.0 \(3654.100.0.2.22\)) Subject: Re: register x18 From: Michael Tuexen In-Reply-To: Date: Fri, 16 Jul 2021 17:07:42 +0200 Cc: Mark Millard , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4361A215-BB47-4166-BC3F-386E7834B788@freebsd.org> References: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> <32C24DDC-C8A1-43CD-9220-8009B229E452@freebsd.org> To: Andrew Turner X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4GRF3Z5nLbz4S3k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 16. Jul 2021, at 14:51, Andrew Turner wrote: >=20 >=20 >> On 16 Jul 2021, at 13:08, tuexen@freebsd.org wrote: >>=20 >>> On 16. Jul 2021, at 04:06, Mark Millard wrote: >>>=20 >>>=20 >>>=20 >>> On 2021-Jul-15, at 17:40, Michael Tuexen = wrote: >>>=20 >>>> Dear all, >>>>=20 >>>> register x18 seems to be special. What is it used for in FreeBSD? >>>>=20 >>>> Best regards >>>> Michael >>>=20 >>> = https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-A= rchitecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters= -in-general-purpose-registers >>>=20 >>> reports: >>>=20 >>> QUOTE >>> =E2=80=A2 X18 is the platform register and is reserved for the = use of platform ABIs. This is an adional temporary register on platforms = that don't assign a special meaning to it. >>> END QUOTE >>>=20 >>> So, special, yes. But I do not know what the "platform ABI" usage >>> for it might be on FreeBSD. So, for the most part, this does not >>> well-answer your question. Sorry. >> Yepp, I found the above text. However, x18 seems to be used when = accessing >> global variables. I am looking at a panic, where the system panics on = accessing >> global variable, which can be controlled by sysctl. >> It seems that x18 does not have the expected value, but it is also = not set in >> the function... >=20 > X18 is used to store the pointer to the pcpu data It should only ever = be set when we enter the kernel from userland by the exception handler. Hi Andrew, thanks for the response. Hmm. I was hoping that the answers helps me to = understand a panic that I'm observing when stress testing the TCP RACK stack. I'm = transferring 10GB via scp and at some point of time (not right at the beginning), the = machine panics. The machine is an eMAG system. Here is what I know: Initially it panics multiple times (always at the same place) in https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n16540 when it is trying to read V_tcp_map_entries_limit. I discussed this with rrs@ and since we had no clue, I tried to just = compile out the if condition. Then is paniced in https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n16928 at https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n15664 which is basically the next place where a V_ variable is accessed. Please note that for debugging I'm using a kernel without VIMAGE = support, since we initially thought that it might be related a VNET bug. So I decided to look at the disassembly of rack_sndbuf_autoscale (I = added some comments): 0xffff000001388a6c <+0>: stp x29, x30, [sp, #-32]! 0xffff000001388a70 <+4>: str x19, [sp, #16] 0xffff000001388a74 <+8>: mov x29, sp 0xffff000001388a78 <+12>: ldr x9, [x0, #24] = // x9 =3D rack->tp; 0xffff000001388a7c <+16>: ldr w8, [x0, #188] = // w8 =3D rack->r_ctl.cwnd_to_use 0xffff000001388a80 <+20>: adrp x12, 0xffff0000013ac000 0xffff000001388a84 <+24>: ldr w10, [x9, #52] = // w10 =3D tp->snd_wnd; 0xffff000001388a88 <+28>: ldr x11, [x18] 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] 0xffff000001388a90 <+36>: cmp w8, w10 0xffff000001388a94 <+40>: csel w10, w8, w10, cc // cc =3D lo, = ul, last // min(rack->r_ctl.cwnd_to_use, tp->snd_wnd); =3D> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] 0xffff000001388a9c <+48>: ldr x12, [x12, #2752] 0xffff000001388aa0 <+52>: ldr w11, [x11, x12] = // w11 =3D V_tcp_do_autosndbuf ??? 0xffff000001388aa4 <+56>: cbz w11, 0xffff000001388be0 = 0xffff000001388aa8 <+60>: ldr x8, [x0, #32] = // x8 =3D rack->rc_inp 0xffff000001388aac <+64>: ldr x19, [x8, #120] = // x19 =3D so =3D x8->inp_socket 0xffff000001388ab0 <+68>: ldrb w8, [x19, #817] = // w8 =3D (x19->so_snd.sb_flags << 8) & 0ff 0xffff000001388ab4 <+72>: tbz w8, #3, 0xffff000001388be0 = so->so_snd.sb_flags & SB_AUTOSIZE =3D=3D 0 0xffff000001388ab8 <+76>: ldr w11, [x9, #52] = // w11 =3D tp->snd_wnd 0xffff000001388abc <+80>: ldr w8, [x19, #740] = // w8 =3D so->so_snd.sb_hiwat 0xffff000001388ac0 <+84>: lsr w11, w11, #2 0xffff000001388ac4 <+88>: add w11, w11, w11, lsl #2 0xffff000001388ac8 <+92>: cmp w11, w8 0xffff000001388acc <+96>: b.cc 0xffff000001388be0 = // b.lo, b.ul, b.last 0xffff000001388ad0 <+100>: ldr w11, [x19, #736] 0xffff000001388ad4 <+104>: lsr w8, w8, #3 0xffff000001388ad8 <+108>: lsl w12, w8, #3 0xffff000001388adc <+112>: sub w8, w12, w8 0xffff000001388ae0 <+116>: cmp w11, w8 0xffff000001388ae4 <+120>: b.cc 0xffff000001388be0 = // b.lo, b.ul, b.last 0xffff000001388ae8 <+124>: ldr x8, [x18] 0xffff000001388aec <+128>: ldr x8, [x8, #1256] 0xffff000001388af0 <+132>: ldr x12, [x8, #40] 0xffff000001388af4 <+136>: adrp x8, 0xffff0000013ac000 0xffff000001388af8 <+140>: ldr x8, [x8, #2760] 0xffff000001388afc <+144>: ldr w12, [x12, x8] 0xffff000001388b00 <+148>: cmp w11, w12 So it seems that the code accessing V_tcp_do_autosndbuf is: 0xffff000001388a80 <+20>: adrp x12, 0xffff0000013ac000 ... 0xffff000001388a88 <+28>: ldr x11, [x18] 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] ... =3D> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] 0xffff000001388a9c <+48>: ldr x12, [x12, #2752] 0xffff000001388aa0 <+52>: ldr w11, [x11, x12] = // w11 =3D V_tcp_do_autosndbuf ??? and for V_tcp_autosndbuf_max it is: 0xffff000001388ae8 <+124>: ldr x8, [x18] 0xffff000001388aec <+128>: ldr x8, [x8, #1256] 0xffff000001388af0 <+132>: ldr x12, [x8, #40] 0xffff000001388af4 <+136>: adrp x8, 0xffff0000013ac000 0xffff000001388af8 <+140>: ldr x8, [x8, #2760] 0xffff000001388afc <+144>: ldr w12, [x12, x8] The #2752 versus #2760 could be the offset of the variable. Does the above code makes sense to you? The code relevant for the crash = seems to be: 0xffff000001388a88 <+28>: ldr x11, [x18] 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] 0xffff000001388a98 <+44>: ldr x11, [x11, #40] Since it is crashing at 0xffff000001388a98 <+44>, my assumption was that = x18 is wrong... But does this use fit to your description? I'm trying to debug this on arm64, since I can reproduce it on arm64. = But there is also a bug report that this happens on amd64: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257195 Any idea what can be wrong? Any hint how to progress? Thank you very much for your help! Best regards Michael >=20 > Andrew From nobody Fri Jul 16 15:53:14 2021 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 04058127EF39 for ; Fri, 16 Jul 2021 15:53:19 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4GRG3y2Fj1z4fqP; Fri, 16 Jul 2021 15:53:17 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.1.66] (67.red-83-54-23.dynamicip.rima-tde.net [83.54.23.67]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 35F274E76C; Fri, 16 Jul 2021 15:53:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1626450796; bh=WQ84TjCkkcARDgNVC0cFmH+flE/Dxrua9CB16RbQlCQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=GEhx+++eesJeVaExrWqQyIgu4tE5kj/zf2NQQn6fT4XglFTp2YidVWobOeJgMV0w4 eDoVpwyLjzu0NzYFiJ/AOJ1kJm94vGb7MtXvscxlQUs+749bWBaOr9bP1S/LeMozUg VAUT1XVUmILEzG28qr6sj/j+shPg+iIBFPzXDakRtqSZ4Q6HevZlUjFX0cOEsu0E1n 2ONMYg0a1NLM++pXAOv+djhZoCE6BFW/Oc8mMwm/afnNizYwCN0bL5XKgjMOxuZ4FF VgWhwaINgZ4EFg2D+0KReIrqpsh6IqSreIBe/L/HkfptVsfoxiXIMP9Rvk+L0gcWj3 MaBqCICNB6ePAybg+qZB/cS217k3L8vX8Zky3W+KtXLdSvm80veQnBoavObztMwnxP TprO078yfEWVHKguw0vmayfGPavdI/qkf8jAfzqrFSQLV7g8vBFoFpUr7Rf4m3R8fh jgXTi4kkBm5tzhOn3fzqxJoa532EZIbHu3PtOGuoVUuC/wWZppqJZkOORCG/kUxuxh Kj3hMUpU2N970Nei00sS6CvuXZoMz9ukDZ6fV1gH3sn2iYcrJ+LXbt95K/mlLFsv/l XLNou6tay+jo0XALuu5rN7Y8aMjl6lxCaCMt1yQ5ptjx7O78FAK+v8KR/zb+QS6W+T Fkz9wy/PsMIkTsKdeOiqm3cs= From: Andrew Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_176D5592-4DF4-4747-A7A9-AD5ED99BB2E6" 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 12.4 \(3445.104.20\)) Subject: Re: register x18 Date: Fri, 16 Jul 2021 17:53:14 +0200 In-Reply-To: <4361A215-BB47-4166-BC3F-386E7834B788@freebsd.org> Cc: Mark Millard , freebsd-arm@freebsd.org To: Michael Tuexen References: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> <32C24DDC-C8A1-43CD-9220-8009B229E452@freebsd.org> <4361A215-BB47-4166-BC3F-386E7834B788@freebsd.org> X-Mailer: Apple Mail (2.3445.104.20) X-Rspamd-Queue-Id: 4GRG3y2Fj1z4fqP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_176D5592-4DF4-4747-A7A9-AD5ED99BB2E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Jul 2021, at 17:07, Michael Tuexen wrote: >=20 >> On 16. Jul 2021, at 14:51, Andrew Turner > wrote: >>=20 >>=20 >>> On 16 Jul 2021, at 13:08, tuexen@freebsd.org = wrote: >>>=20 >>>> On 16. Jul 2021, at 04:06, Mark Millard > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 2021-Jul-15, at 17:40, Michael Tuexen = wrote: >>>>=20 >>>>> Dear all, >>>>>=20 >>>>> register x18 seems to be special. What is it used for in FreeBSD? >>>>>=20 >>>>> Best regards >>>>> Michael >>>>=20 >>>> = https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-A= rchitecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters= -in-general-purpose-registers >>>>=20 >>>> reports: >>>>=20 >>>> QUOTE >>>> =E2=80=A2 X18 is the platform register and is reserved for the = use of platform ABIs. This is an adional temporary register on platforms = that don't assign a special meaning to it. >>>> END QUOTE >>>>=20 >>>> So, special, yes. But I do not know what the "platform ABI" usage >>>> for it might be on FreeBSD. So, for the most part, this does not >>>> well-answer your question. Sorry. >>> Yepp, I found the above text. However, x18 seems to be used when = accessing >>> global variables. I am looking at a panic, where the system panics = on accessing >>> global variable, which can be controlled by sysctl. >>> It seems that x18 does not have the expected value, but it is also = not set in >>> the function... >>=20 >> X18 is used to store the pointer to the pcpu data It should only ever = be set when we enter the kernel from userland by the exception handler. > Hi Andrew, >=20 > thanks for the response. Hmm. I was hoping that the answers helps me = to understand > a panic that I'm observing when stress testing the TCP RACK stack. I'm = transferring > 10GB via scp and at some point of time (not right at the beginning), = the machine panics. > The machine is an eMAG system. >=20 > Here is what I know: >=20 > Initially it panics multiple times (always at the same place) in > https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n16540 = > when it is trying to read V_tcp_map_entries_limit. >=20 > I discussed this with rrs@ and since we had no clue, I tried to just = compile > out the if condition. >=20 > Then is paniced in > https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n16928 = > at > https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n15664 = > which is basically the next place where a V_ variable is accessed. >=20 > Please note that for debugging I'm using a kernel without VIMAGE = support, > since we initially thought that it might be related a VNET bug. >=20 > So I decided to look at the disassembly of rack_sndbuf_autoscale (I = added some comments): >=20 > 0xffff000001388a6c <+0>: stp x29, x30, [sp, #-32]! > 0xffff000001388a70 <+4>: str x19, [sp, #16] > 0xffff000001388a74 <+8>: mov x29, sp > 0xffff000001388a78 <+12>: ldr x9, [x0, #24] = // x9 =3D rack->tp; > 0xffff000001388a7c <+16>: ldr w8, [x0, #188] = // w8 =3D rack->r_ctl.cwnd_to_use > 0xffff000001388a80 <+20>: adrp x12, 0xffff0000013ac000 > 0xffff000001388a84 <+24>: ldr w10, [x9, #52] = // w10 =3D tp->snd_wnd; > 0xffff000001388a88 <+28>: ldr x11, [x18] > 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] > 0xffff000001388a90 <+36>: cmp w8, w10 > 0xffff000001388a94 <+40>: csel w10, w8, w10, cc // cc =3D lo, = ul, last // min(rack->r_ctl.cwnd_to_use, tp->snd_wnd); > =3D> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] > 0xffff000001388a9c <+48>: ldr x12, [x12, #2752] > 0xffff000001388aa0 <+52>: ldr w11, [x11, x12] = // w11 =3D V_tcp_do_autosndbuf ??? > 0xffff000001388aa4 <+56>: cbz w11, 0xffff000001388be0 = > 0xffff000001388aa8 <+60>: ldr x8, [x0, #32] = // x8 =3D rack->rc_inp > 0xffff000001388aac <+64>: ldr x19, [x8, #120] = // x19 =3D so =3D x8->inp_socket > 0xffff000001388ab0 <+68>: ldrb w8, [x19, #817] = // w8 =3D (x19->so_snd.sb_flags << 8) & 0ff > 0xffff000001388ab4 <+72>: tbz w8, #3, 0xffff000001388be0 = so->so_snd.sb_flags & SB_AUTOSIZE =3D=3D 0 > 0xffff000001388ab8 <+76>: ldr w11, [x9, #52] = // w11 =3D tp->snd_wnd > 0xffff000001388abc <+80>: ldr w8, [x19, #740] = // w8 =3D so->so_snd.sb_hiwat > 0xffff000001388ac0 <+84>: lsr w11, w11, #2 > 0xffff000001388ac4 <+88>: add w11, w11, w11, lsl #2 > 0xffff000001388ac8 <+92>: cmp w11, w8 > 0xffff000001388acc <+96>: b.cc = 0xffff000001388be0 // b.lo, b.ul, b.last > 0xffff000001388ad0 <+100>: ldr w11, [x19, #736] > 0xffff000001388ad4 <+104>: lsr w8, w8, #3 > 0xffff000001388ad8 <+108>: lsl w12, w8, #3 > 0xffff000001388adc <+112>: sub w8, w12, w8 > 0xffff000001388ae0 <+116>: cmp w11, w8 > 0xffff000001388ae4 <+120>: b.cc = 0xffff000001388be0 // b.lo, b.ul, b.last > 0xffff000001388ae8 <+124>: ldr x8, [x18] > 0xffff000001388aec <+128>: ldr x8, [x8, #1256] > 0xffff000001388af0 <+132>: ldr x12, [x8, #40] > 0xffff000001388af4 <+136>: adrp x8, 0xffff0000013ac000 > 0xffff000001388af8 <+140>: ldr x8, [x8, #2760] > 0xffff000001388afc <+144>: ldr w12, [x12, x8] > 0xffff000001388b00 <+148>: cmp w11, w12 >=20 > So it seems that the code accessing V_tcp_do_autosndbuf is: >=20 > 0xffff000001388a80 <+20>: adrp x12, 0xffff0000013ac000 > ... > 0xffff000001388a88 <+28>: ldr x11, [x18] > 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] > ... > =3D> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] > 0xffff000001388a9c <+48>: ldr x12, [x12, #2752] > 0xffff000001388aa0 <+52>: ldr w11, [x11, x12] = // w11 =3D V_tcp_do_autosndbuf ??? >=20 > and for V_tcp_autosndbuf_max it is: > 0xffff000001388ae8 <+124>: ldr x8, [x18] > 0xffff000001388aec <+128>: ldr x8, [x8, #1256] > 0xffff000001388af0 <+132>: ldr x12, [x8, #40] > 0xffff000001388af4 <+136>: adrp x8, 0xffff0000013ac000 > 0xffff000001388af8 <+140>: ldr x8, [x8, #2760] > 0xffff000001388afc <+144>: ldr w12, [x12, x8] >=20 > The #2752 versus #2760 could be the offset of the variable. >=20 > Does the above code makes sense to you? The code relevant for the = crash seems to be: >=20 > 0xffff000001388a88 <+28>: ldr x11, [x18] > 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] > 0xffff000001388a98 <+44>: ldr x11, [x11, #40] >=20 > Since it is crashing at 0xffff000001388a98 <+44>, my assumption was = that x18 is wrong... > But does this use fit to your description? This code is loading curthread from the pcpu data, then loading whatever = is 1256 bytes within struct thread. I checked the offset of td_vnet and = found it was at the correct location so it would appear to be using = VIMAGE and has a bad vnet pointer. The other assembly above also looks like it=E2=80=99s using VIMAGE as = they have similar code with the same offsets. >=20 > I'm trying to debug this on arm64, since I can reproduce it on arm64. = But there is > also a bug report that this happens on amd64: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257195 = >=20 > Any idea what can be wrong? Any hint how to progress? If you can reproduce of amd64 it might pay to test with KASAN. How stable is the bad pointer value? It might pay to add KASSERTS to the = code to check curvnet (the macro to get td_vnet) is not the bad value, = or at least greater than VM_MIN_KERNEL_ADDRESS. Andrew= --Apple-Mail=_176D5592-4DF4-4747-A7A9-AD5ED99BB2E6-- From nobody Fri Jul 16 19:32:49 2021 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 D073C1274E62 for ; Fri, 16 Jul 2021 19:32:55 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRLxM4nnlz4bBZ for ; Fri, 16 Jul 2021 19:32:55 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2ADEF721E282D; Fri, 16 Jul 2021 21:32:50 +0200 (CEST) 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 14.0 \(3654.100.0.2.22\)) Subject: Re: register x18 From: Michael Tuexen In-Reply-To: Date: Fri, 16 Jul 2021 21:32:49 +0200 Cc: Mark Millard , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <06B96A5D-AF14-4EEC-8D11-B91F9683A0E8@freebsd.org> References: <86EC9C12-F90C-4D0C-BFA3-41986C9F07B5@freebsd.org> <32C24DDC-C8A1-43CD-9220-8009B229E452@freebsd.org> <4361A215-BB47-4166-BC3F-386E7834B788@freebsd.org> To: Andrew Turner X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4GRLxM4nnlz4bBZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 16. Jul 2021, at 17:53, Andrew Turner wrote: >=20 >=20 >> On 16 Jul 2021, at 17:07, Michael Tuexen wrote: >>=20 >>> On 16. Jul 2021, at 14:51, Andrew Turner = wrote: >>>=20 >>>=20 >>>> On 16 Jul 2021, at 13:08, tuexen@freebsd.org wrote: >>>>=20 >>>>> On 16. Jul 2021, at 04:06, Mark Millard wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2021-Jul-15, at 17:40, Michael Tuexen = wrote: >>>>>=20 >>>>>> Dear all, >>>>>>=20 >>>>>> register x18 seems to be special. What is it used for in FreeBSD? >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>=20 >>>>> = https://developer.arm.com/documentation/den0024/a/The-ABI-for-ARM-64-bit-A= rchitecture/Register-use-in-the-AArch64-Procedure-Call-Standard/Parameters= -in-general-purpose-registers >>>>>=20 >>>>> reports: >>>>>=20 >>>>> QUOTE >>>>> =E2=80=A2 X18 is the platform register and is reserved for the = use of platform ABIs. This is an adional temporary register on platforms = that don't assign a special meaning to it. >>>>> END QUOTE >>>>>=20 >>>>> So, special, yes. But I do not know what the "platform ABI" usage >>>>> for it might be on FreeBSD. So, for the most part, this does not >>>>> well-answer your question. Sorry. >>>> Yepp, I found the above text. However, x18 seems to be used when = accessing >>>> global variables. I am looking at a panic, where the system panics = on accessing >>>> global variable, which can be controlled by sysctl. >>>> It seems that x18 does not have the expected value, but it is also = not set in >>>> the function... >>>=20 >>> X18 is used to store the pointer to the pcpu data It should only = ever be set when we enter the kernel from userland by the exception = handler. >> Hi Andrew, >>=20 >> thanks for the response. Hmm. I was hoping that the answers helps me = to understand >> a panic that I'm observing when stress testing the TCP RACK stack. = I'm transferring >> 10GB via scp and at some point of time (not right at the beginning), = the machine panics. >> The machine is an eMAG system. >>=20 >> Here is what I know: >>=20 >> Initially it panics multiple times (always at the same place) in >> = https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n16540 >> when it is trying to read V_tcp_map_entries_limit. >>=20 >> I discussed this with rrs@ and since we had no clue, I tried to just = compile >> out the if condition. >>=20 >> Then is paniced in >> = https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n16928 >> at >> = https://cgit.freebsd.org/src/tree/sys/netinet/tcp_stacks/rack.c#n15664 >> which is basically the next place where a V_ variable is accessed. >>=20 >> Please note that for debugging I'm using a kernel without VIMAGE = support, >> since we initially thought that it might be related a VNET bug. >>=20 >> So I decided to look at the disassembly of rack_sndbuf_autoscale (I = added some comments): >>=20 >> 0xffff000001388a6c <+0>: stp x29, x30, [sp, #-32]! >> 0xffff000001388a70 <+4>: str x19, [sp, #16] >> 0xffff000001388a74 <+8>: mov x29, sp >> 0xffff000001388a78 <+12>: ldr x9, [x0, #24] = // x9 =3D rack->tp; >> 0xffff000001388a7c <+16>: ldr w8, [x0, #188] = // w8 =3D rack->r_ctl.cwnd_to_use >> 0xffff000001388a80 <+20>: adrp x12, 0xffff0000013ac000 >> 0xffff000001388a84 <+24>: ldr w10, [x9, #52] = // w10 =3D tp->snd_wnd; >> 0xffff000001388a88 <+28>: ldr x11, [x18] >> 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] >> 0xffff000001388a90 <+36>: cmp w8, w10 >> 0xffff000001388a94 <+40>: csel w10, w8, w10, cc // cc =3D lo, = ul, last // min(rack->r_ctl.cwnd_to_use, tp->snd_wnd); >> =3D> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] >> 0xffff000001388a9c <+48>: ldr x12, [x12, #2752] >> 0xffff000001388aa0 <+52>: ldr w11, [x11, x12] = // w11 =3D V_tcp_do_autosndbuf ??? >> 0xffff000001388aa4 <+56>: cbz w11, 0xffff000001388be0 = >> 0xffff000001388aa8 <+60>: ldr x8, [x0, #32] = // x8 =3D rack->rc_inp >> 0xffff000001388aac <+64>: ldr x19, [x8, #120] = // x19 =3D so =3D x8->inp_socket >> 0xffff000001388ab0 <+68>: ldrb w8, [x19, #817] = // w8 =3D (x19->so_snd.sb_flags << 8) & 0ff >> 0xffff000001388ab4 <+72>: tbz w8, #3, 0xffff000001388be0 = so->so_snd.sb_flags & SB_AUTOSIZE =3D=3D 0 >> 0xffff000001388ab8 <+76>: ldr w11, [x9, #52] = // w11 =3D tp->snd_wnd >> 0xffff000001388abc <+80>: ldr w8, [x19, #740] = // w8 =3D so->so_snd.sb_hiwat >> 0xffff000001388ac0 <+84>: lsr w11, w11, #2 >> 0xffff000001388ac4 <+88>: add w11, w11, w11, lsl #2 >> 0xffff000001388ac8 <+92>: cmp w11, w8 >> 0xffff000001388acc <+96>: b.cc 0xffff000001388be0 = // b.lo, b.ul, b.last >> 0xffff000001388ad0 <+100>: ldr w11, [x19, #736] >> 0xffff000001388ad4 <+104>: lsr w8, w8, #3 >> 0xffff000001388ad8 <+108>: lsl w12, w8, #3 >> 0xffff000001388adc <+112>: sub w8, w12, w8 >> 0xffff000001388ae0 <+116>: cmp w11, w8 >> 0xffff000001388ae4 <+120>: b.cc 0xffff000001388be0 = // b.lo, b.ul, b.last >> 0xffff000001388ae8 <+124>: ldr x8, [x18] >> 0xffff000001388aec <+128>: ldr x8, [x8, #1256] >> 0xffff000001388af0 <+132>: ldr x12, [x8, #40] >> 0xffff000001388af4 <+136>: adrp x8, 0xffff0000013ac000 >> 0xffff000001388af8 <+140>: ldr x8, [x8, #2760] >> 0xffff000001388afc <+144>: ldr w12, [x12, x8] >> 0xffff000001388b00 <+148>: cmp w11, w12 >>=20 >> So it seems that the code accessing V_tcp_do_autosndbuf is: >>=20 >> 0xffff000001388a80 <+20>: adrp x12, 0xffff0000013ac000 >> ... >> 0xffff000001388a88 <+28>: ldr x11, [x18] >> 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] >> ... >> =3D> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] >> 0xffff000001388a9c <+48>: ldr x12, [x12, #2752] >> 0xffff000001388aa0 <+52>: ldr w11, [x11, x12] = // w11 =3D V_tcp_do_autosndbuf ??? >>=20 >> and for V_tcp_autosndbuf_max it is: >> 0xffff000001388ae8 <+124>: ldr x8, [x18] >> 0xffff000001388aec <+128>: ldr x8, [x8, #1256] >> 0xffff000001388af0 <+132>: ldr x12, [x8, #40] >> 0xffff000001388af4 <+136>: adrp x8, 0xffff0000013ac000 >> 0xffff000001388af8 <+140>: ldr x8, [x8, #2760] >> 0xffff000001388afc <+144>: ldr w12, [x12, x8] >>=20 >> The #2752 versus #2760 could be the offset of the variable. >>=20 >> Does the above code makes sense to you? The code relevant for the = crash seems to be: >>=20 >> 0xffff000001388a88 <+28>: ldr x11, [x18] >> 0xffff000001388a8c <+32>: ldr x11, [x11, #1256] >> 0xffff000001388a98 <+44>: ldr x11, [x11, #40] >>=20 >> Since it is crashing at 0xffff000001388a98 <+44>, my assumption was = that x18 is wrong... >> But does this use fit to your description? >=20 > This code is loading curthread from the pcpu data, then loading = whatever is 1256 bytes within struct thread. I checked the offset of = td_vnet and found it was at the correct location so it would appear to = be using VIMAGE and has a bad vnet pointer. >=20 > The other assembly above also looks like it=E2=80=99s using VIMAGE as = they have similar code with the same offsets. >=20 >>=20 >> I'm trying to debug this on arm64, since I can reproduce it on arm64. = But there is >> also a bug report that this happens on amd64: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257195 >>=20 >> Any idea what can be wrong? Any hint how to progress? >=20 > If you can reproduce of amd64 it might pay to test with KASAN. >=20 > How stable is the bad pointer value? It might pay to add KASSERTS to = the code to check curvnet (the macro to get td_vnet) is not the bad = value, or at least greater than VM_MIN_KERNEL_ADDRESS. Thank you very much! I double checked my kernel config, and after disabling VIMAGE, it was = enabled again. So, yes this is a VIMAGE kernel and I guess the problem is related to = it. Your explanations were very helpful. Best regards Michael >=20 > Andrew From nobody Fri Jul 16 20:32:05 2021 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 B5AC712A537E for ; Fri, 16 Jul 2021 20:32:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRNFd4XCYz4qRq for ; Fri, 16 Jul 2021 20:32:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 848E62397A for ; Fri, 16 Jul 2021 20:32: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 16GKW5S6087867 for ; Fri, 16 Jul 2021 20:32:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16GKW5h9087866 for freebsd-arm@FreeBSD.org; Fri, 16 Jul 2021 20:32: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 229953] src/sys/arm64/rockchip/clk/rk_clk_composite.c:167]: (error) Division by zero. Date: Fri, 16 Jul 2021 20:32:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229953 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed CC| |manu@freebsd.org --- Comment #1 from Emmanuel Vadot --- Fixed a long time ago --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jul 17 11:14:02 2021 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 396741274CEA for ; Sat, 17 Jul 2021 11:14:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GRlqG0rrKz3mrS for ; Sat, 17 Jul 2021 11:14:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 0592C7526 for ; Sat, 17 Jul 2021 11:14:02 +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 16HBE1j5046584 for ; Sat, 17 Jul 2021 11:14:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16HBE1R5046583 for freebsd-arm@FreeBSD.org; Sat, 17 Jul 2021 11:14:01 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 257127] kernel.bin creation fails, empty file: arm_kernel_boothdr.awk: missing kernbase/_start/_end symbol(s) Date: Sat, 17 Jul 2021 11:14:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@oldach.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257127 Helge Oldach changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jul 18 12:57:24 2021 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 392D1127CECF for ; Sun, 18 Jul 2021 12:57:29 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GSQ476mqXz4THv for ; Sun, 18 Jul 2021 12:57:27 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id a13so18046529wrf.10 for ; Sun, 18 Jul 2021 05:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7MOu8JruFMBTlz50awGIRGubJ3LB+lWAN8xcB3Jlyxk=; b=n5tI5nCzKUq8qc04lETf15+k6BlUwGbWtKFIVSJ0RljOIDmemzWRxO6/Vy7X8Hs2hm B6eh6an6kSIusxuhUEnaZ6aN4qvfHsH2XQ26JuSk29j2wRK96wwypC2SnRzAIRsSUpAy qFUuGBWFwsSCu0fULCGSakN4zMlm9f+zaczqUjeXvM4N2cO1XWcdZpIblgO1sxaaMGe+ DU7dY4mewYcvmaXJilbZpzlsGQrVcJ6bMOw8KdnN6FnGbjkourh06RphdU/P7p5jsLmA WIImmGns0vfdrsr5lDSN30wtA5Zx1l8MIrGT5BC4ro/ugaPf1xLFdixhvURMlgDf2eT8 5EyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7MOu8JruFMBTlz50awGIRGubJ3LB+lWAN8xcB3Jlyxk=; b=SXt+8OMC9iN8ZER9zmBhUWvElb2CGE8dJxlPqU38QyRtkUWgE4eHpYqgTAyRUG6DP0 uCQvB+nkbvtTDb2R3XRXSWqMxi9lrEJ6jQHMSco+brNsJJMF89BKFvnBjIxgspOQczlD Mwqi6ilIpjYyB1tyO7E9l8K1RL5GAR0hCwfUY5QA9Abm/83zFF2TPnMnqhKAoR56Dyh4 5xdb0eR005QDkUhhE8poTs3KIbOtqtAMRgi/pBr8ja+xIuoa11pRURiM1Bm/K08R6Vah qBDlb5cYUOZ6e9Z9jcfJqTXmd1uuI6YMSBO8GhgzAiwW03MTnu5m3DKHUPV1yPYdijvf IsMw== X-Gm-Message-State: AOAM532ieUZZbScS3Xkz+dRuTz4xE1OQoIJ8UXKIZIlKjNs9Tqbf28OR EC4HzC7w66pV/wHw0lQHr+brmdIgvOo= X-Google-Smtp-Source: ABdhPJwVG+1c+bz/kdTSQrlNMFNAajJJhr5j/ov3o/uz53x7ErX3xzzwXCZDr0IwWr0Cpobc1L3dnA== X-Received: by 2002:a5d:4b46:: with SMTP id w6mr24727337wrs.352.1626613046186; Sun, 18 Jul 2021 05:57:26 -0700 (PDT) Received: from mac.deepcore.dk ([85.27.186.9]) by smtp.gmail.com with ESMTPSA id u16sm20131075wrw.36.2021.07.18.05.57.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jul 2021 05:57:25 -0700 (PDT) From: =?utf-8?Q?S=C3=B8ren_Schmidt?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_521145A4-77A2-4FA7-AE63-FD4E727FC8D4" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: FreeBSD on PINE64 Quartz64a Rocchiprk3566 Date: Sun, 18 Jul 2021 14:57:24 +0200 In-Reply-To: Cc: Free BSD To: Sleep Walker References: X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4GSQ476mqXz4THv X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=n5tI5nCz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sorenschmidt@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=sorenschmidt@gmail.com X-Spamd-Result: default: False [1.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_MIXED_CHARSET(0.62)[subject]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::42e:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.1.44:email,0.0.0.100:email,0.0.0.200:email,0.0.0.0:email]; NEURAL_SPAM_SHORT(1.00)[0.998]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_521145A4-77A2-4FA7-AE63-FD4E727FC8D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi gang! Got some time and whipped a clk driver up and now it even gets to the = login prompt :) I=E2=80=99ll put the bits up for grabs later the still need som cleanup = nut clk driver fro cru and pmucru is done (more or less) OK boot -v Booting... Using DTB provided by EFI at 0x8200000. EFI framebuffer information: addr, size 0x0, 0x0 dimensions 0 x 0 stride 0 masks 0x00000000, 0x00000000, 0x00000000, 0x00000000 ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Type Physical Virtual #Pages Attr ConventionalMemory 000000200000 200000 00008000 WB=20 BootServicesData 000008200000 8200000 00000006 WB=20 ConventionalMemory 000008206000 200000 000001fa WB=20 ConventionalMemory 000009400000 9400000 000d94d9 WB=20 LoaderData 0000e28d9000 e28d9000 00000001 WB=20 LoaderData 0000e28da000 e28da000 00004000 WB=20 LoaderData 0000e68da000 e68da000 00004000 WB=20 LoaderData 0000ea8da000 ea8da000 00000113 WB=20 RuntimeServicesData 0000ea9ed000 ea9ed000 00000001 WB RUNTIME Reserved 0000ea9ee000 ea9ee000 00000001 WB=20 Reserved 0000ea9ef000 ea9ef000 00000001 WB=20 Reserved 0000ea9f0000 ea9f0000 00000001 WB=20 Reserved 0000ea9f1000 ea9f1000 00000001 WB=20 Reserved 0000ea9f2000 ea9f2000 00000001 WB=20 Reserved 0000ea9f3000 ea9f3000 00000001 WB=20 Reserved 0000ea9f4000 ea9f4000 00000001 WB=20 Reserved 0000ea9f5000 ea9f5000 00000001 WB=20 Reserved 0000ea9f6000 ea9f6000 00000001 WB=20 Reserved 0000ea9f7000 ea9f7000 00000001 WB=20 Reserved 0000ea9f8000 ea9f8000 00000001 WB=20 LoaderData 0000ea9f9000 ea9f9000 000034af WB=20 RuntimeServicesCode 0000edea8000 edea8000 00000001 WB RUNTIME LoaderData 0000edea9000 ea9f9000 00002157 WB=20 Physical memory chunk(s): 0x00200000 - 0x083fffff, 130 MB ( 33280 pages) 0x09400000 - 0xea9edfff, 3605 MB ( 923118 pages) 0xea9f9000 - 0xedea7fff, 52 MB ( 13487 pages) 0xedea9000 - 0xefffffff, 33 MB ( 8535 pages) Excluded memory regions: 0xe2a00000 - 0xe3843fff, 14 MB ( 3652 pages) NoAlloc=20 0xea9ed000 - 0xea9f8fff, 0 MB ( 12 pages) NoAlloc=20 0xedea8000 - 0xedea8fff, 0 MB ( 1 pages) NoAlloc=20 Found 4 CPUs in the device tree Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-STABLE #72 r561:563M ba56ee36e: Sun Jul 18 14:40:57 CEST = 2021 = sos@repo.deepcore.dk:/usr/home/sos/FreeBSD/embedded/aarch64-obj/usr/home/s= os/FreeBSD/stable13/arm64.aarch64/sys/QUARTZ64 arm64 FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) VT: init without driver. Preloaded elf kernel "/boot/kernel/kernel" at 0xffff000000c16000. real memory =3D 4007608320 (3821 MB) Physical memory chunk(s): 0x00000000200000 - 0x000000083fffff, 136314880 bytes (33280 pages) 0x00000009400000 - 0x000000dcb4dfff, 3547652096 bytes (866126 pages) 0x000000e3844000 - 0x000000ea9ecfff, 119181312 bytes (29097 pages) 0x000000ea9f9000 - 0x000000edea7fff, 55242752 bytes (13487 pages) 0x000000edea9000 - 0x000000efffffff, 34959360 bytes (8535 pages) avail memory =3D 3892834304 (3712 MB) Starting CPU 1 (100) Starting CPU 2 (200) Starting CPU 3 (300) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Enabling LSE atomics in the kernel random: no preloaded entropy cache arc4random: WARNING: initial seeding bypassed the cryptographic random = device because it was not yet seeded and the knob = 'bypass_before_seeding' was enabled. hostuuid: using 00000000-0000-0000-0000-000000000000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 random: entropy device external interface MAP ea9ed000 mode 2 pages 1 MAP edea8000 mode 2 pages 1 crypto: openfirm: kbd0 at kbdmux0 mem: null: WARNING: Device "ata" is Giant locked and may be deleted before FreeBSD = 14.0. ofwbus0: clk_fixed0: on ofwbus0 clk_fixed1: on ofwbus0 clk_fixed2: on ofwbus0 clk_fixed3: on ofwbus0 rk3568_pmucru0: mem = 0xfdd00000-0xfdd00fff on ofwbus0 clknode_link_recalc: Attempt to use unresolved linked clock: cpll Cannot get frequency for clk: cpll, error: 9 Clock: cpll, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: gpll Cannot get frequency for clk: gpll, error: 9 Clock: gpll, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: usb480m Cannot get frequency for clk: usb480m, error: 9 Clock: usb480m, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: = clk_32k_pvtm Cannot get frequency for clk: clk_32k_pvtm, error: 9 Clock: clk_32k_pvtm, parent: (NULL)(-1), freq: 9 clk_rtc32k_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_rtc_32k, parent: clk_rtc32k_frac(2), freq: 24000000 Clock: sclk_uart0_mux, parent: xin24m(2), freq: 24000000 Clock: ppll, parent: xin24m(0), freq: 100000000 Clock: hpll, parent: xin24m(0), freq: 594000000 Clock: ppll_ph0, parent: ppll(0), freq: 50000000 Clock: ppll_ph180, parent: ppll(0), freq: 50000000 Clock: hpll_ph0, parent: hpll(0), freq: 297000000 Clock: clk_pdpmu, parent: ppll(0), freq: 100000000 Clock: pclk_pdpmu, parent: clk_pdpmu(0), freq: 50000000 Clock: clk_i2c0, parent: clk_pdpmu(0), freq: 50000000 Clock: clk_rtc32k_frac, parent: xin24m(0), freq: 24000000 Clock: xin_osc0_div, parent: xin24m(0), freq: 24000000 Clock: sclk_uart0_div, parent: ppll(0), freq: 100000000 sclk_uart0_frac: rk_clk_fract_recalc denominator is zero! Clock: sclk_uart0_frac, parent: sclk_uart0_div(0), freq: 100000000 Clock: dbclk_gpio0_c, parent: xin24m(0), freq: 24000000 Clock: clk_pwm0, parent: xin24m(0), freq: 12000000 Clock: clk_ref24m, parent: clk_pdpmu(0), freq: 10000000 Clock: clk_usbphy0_ref, parent: xin_osc0_usbphy0_g(1), freq: 24000000 Clock: clk_usbphy1_ref, parent: xin_osc0_usbphy1_g(1), freq: 24000000 Clock: clk_mipidsiphy0_ref, parent: xin_osc0_mipidsiphy0_g(1), freq: = 24000000 Clock: clk_mipidsiphy1_ref, parent: xin_osc0_mipidsiphy1_g(1), freq: = 24000000 Clock: clk_wifi_div, parent: clk_pdpmu(0), freq: 16666666 Clock: clk_wifi, parent: clk_wifi_osc0(0), freq: 24000000 Clock: clk_pciephy0_div, parent: ppll_ph0(0), freq: 12500000 Clock: clk_pciephy0_ref, parent: clk_pciephy0_div(1), freq: 12500000 Clock: clk_pciephy1_div, parent: ppll_ph0(0), freq: 12500000 Clock: clk_pciephy1_ref, parent: clk_pciephy1_div(1), freq: 12500000 Clock: clk_pciephy2_div, parent: ppll_ph0(0), freq: 12500000 Clock: clk_pciephy2_ref, parent: clk_pciephy2_div(1), freq: 12500000 Clock: clk_hdmi_ref, parent: hpll(0), freq: 594000000 Clock: pclk_pmu, parent: pclk_pdpmu(0), freq: 50000000 Clock: dbclk_gpio0, parent: dbclk_gpio0_c(0), freq: 24000000 Clock: clk_pmu, parent: xin24m(0), freq: 24000000 Clock: pclk_i2c0, parent: pclk_pdpmu(0), freq: 50000000 Clock: pclk_uart0, parent: pclk_pdpmu(0), freq: 50000000 Clock: sclk_uart0, parent: sclk_uart0_mux(0), freq: 24000000 Clock: pclk_gpio0, parent: pclk_pdpmu(0), freq: 50000000 Clock: pclk_pwm0, parent: pclk_pdpmu(0), freq: 50000000 Clock: clk_capture_pwm0_ndft, parent: xin24m(0), freq: 24000000 Clock: pclk_pmupvtm, parent: pclk_pdpmu(0), freq: 50000000 Clock: clk_pmupvtm, parent: xin24m(0), freq: 24000000 Clock: clk_core_pmupvtm, parent: xin24m(0), freq: 24000000 Clock: xin_osc0_usbphy0_g, parent: xin24m(0), freq: 24000000 Clock: xin_osc0_usbphy1_g, parent: xin24m(0), freq: 24000000 Clock: xin_osc0_mipidsiphy0_g, parent: xin24m(0), freq: 24000000 Clock: xin_osc0_mipidsiphy1_g, parent: xin24m(0), freq: 24000000 Clock: clk_wifi_osc0, parent: xin24m(0), freq: 24000000 Clock: clk_pciephy0_osc0, parent: xin24m(0), freq: 24000000 Clock: clk_pciephy1_osc0, parent: xin24m(0), freq: 24000000 Clock: clk_pciephy2_osc0, parent: xin24m(0), freq: 24000000 Clock: clk_pcie30phy_ref_m, parent: ppll_ph0(0), freq: 50000000 Clock: clk_pcie30phy_ref_n, parent: ppll_ph180(0), freq: 50000000 Clock: xin_osc0_edpphy_g, parent: xin24m(0), freq: 24000000 rk3568_cru0: mem = 0xfdd20000-0xfdd20fff on ofwbus0 clknode_link_recalc: Attempt to use unresolved linked clock: dummy Cannot get frequency for clk: dummy, error: 9 Clock: dummy, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: usb480m_phy Cannot get frequency for clk: usb480m_phy, error: 9 Clock: usb480m_phy, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: clk_ddr1x Cannot get frequency for clk: clk_ddr1x, error: 9 Clock: clk_ddr1x, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: = gpu_pvtpll_out Cannot get frequency for clk: gpu_pvtpll_out, error: 9 Clock: gpu_pvtpll_out, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: = npu_pvtpll_out Cannot get frequency for clk: npu_pvtpll_out, error: 9 Clock: npu_pvtpll_out, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: gmac0_clkin Cannot get frequency for clk: gmac0_clkin, error: 9 Clock: gmac0_clkin, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: = clk_gmac0_xpcs_mii Cannot get frequency for clk: clk_gmac0_xpcs_mii, error: 9 Clock: clk_gmac0_xpcs_mii, parent: (NULL)(-1), freq: 9 clknode_link_recalc: Attempt to use unresolved linked clock: = clk_gmac1_xpcs_mii Cannot get frequency for clk: clk_gmac1_xpcs_mii, error: 9 Clock: clk_gmac1_xpcs_mii, parent: (NULL)(-1), freq: 9 Clock: apll, parent: xin24m(0), freq: 816000000 Clock: dpll, parent: xin24m(0), freq: 528000000 Clock: gpll, parent: xin24m(0), freq: 1188000000 Clock: cpll, parent: xin24m(0), freq: 1000000000 Clock: npll, parent: xin24m(0), freq: 1200000000 Clock: vpll, parent: xin24m(0), freq: 500000000 Clock: armclk, parent: apll(0), freq: 816000000 Clock: gpll_400m, parent: gpll(0), freq: 396000000 Clock: gpll_300m, parent: gpll(0), freq: 297000000 Clock: gpll_200m, parent: gpll(0), freq: 198000000 Clock: gpll_150m, parent: gpll(0), freq: 148500000 Clock: gpll_100m, parent: gpll(0), freq: 99000000 Clock: gpll_75m, parent: gpll(0), freq: 74250000 Clock: gpll_20m, parent: gpll(0), freq: 19800000 Clock: cpll_500m, parent: cpll(0), freq: 500000000 Clock: cpll_333m, parent: cpll(0), freq: 333333333 Clock: cpll_250m, parent: cpll(0), freq: 250000000 Clock: cpll_125m, parent: cpll(0), freq: 125000000 Clock: cpll_100m, parent: cpll(0), freq: 100000000 Clock: cpll_62p5, parent: cpll(0), freq: 62500000 Clock: cpll_50m, parent: cpll(0), freq: 50000000 Clock: cpll_25m, parent: cpll(0), freq: 25000000 Clock: clk_osc0_div_750k, parent: xin24m(0), freq: 750000 Clock: clk_osc0_div_375k, parent: clk_osc0_div_750k(0), freq: 375000 Clock: xin_osc0_half, parent: xin24m(0), freq: 12000000 Clock: usb480m, parent: xin24m(0), freq: 24000000 Clock: sclk_core_src, parent: apll(0), freq: 408000000 Clock: sclk_core, parent: sclk_core_src(0), freq: 408000000 Clock: atclk_core, parent: armclk(0), freq: 204000000 Clock: gicclk_core, parent: armclk(0), freq: 204000000 Clock: pclk_core_pre, parent: armclk(0), freq: 204000000 Clock: periphclk_core_pre, parent: armclk(0), freq: 204000000 Clock: tsclk_core, parent: periphclk_core_pre(0), freq: 102000000 Clock: cntclk_core, parent: periphclk_core_pre(0), freq: 102000000 Clock: aclk_core, parent: sclk_core(0), freq: 204000000 Clock: aclk_core_niu2bus, parent: gpll_150m(0), freq: 148500000 Clock: clk_gpu_src, parent: cpll(2), freq: 500000000 Clock: clk_gpu_pre_mux, parent: clk_gpu_src(0), freq: 500000000 Clock: aclk_gpu_pre, parent: clk_gpu_pre_mux(0), freq: 250000000 Clock: pclk_gpu_pre, parent: clk_gpu_pre_mux(0), freq: 100000000 Clock: clk_npu_src, parent: npll(0), freq: 600000000 Clock: clk_npu_pre_ndft, parent: clk_npu_src(0), freq: 600000000 Clock: clk_npu, parent: clk_npu_pre_ndft(0), freq: 600000000 Clock: hclk_npu_pre, parent: clk_npu(0), freq: 150000000 Clock: pclk_npu_pre, parent: clk_npu(0), freq: 100000000 Clock: clk_ddrphy1x_src, parent: dpll(0), freq: 528000000 clknode_link_recalc: Attempt to use unresolved linked clock: clk_ddr1x Cannot get frequency for clk: clk_ddr1x, error: 9 Clock: clk_msch, parent: clk_ddr1x(0), freq: 9 Clock: aclk_gic_audio, parent: gpll_200m(0), freq: 198000000 Clock: hclk_gic_audio, parent: gpll_150m(0), freq: 148500000 Clock: dclk_sdmmc_buffer, parent: gpll_100m(0), freq: 99000000 Clock: mclk_pdm, parent: gpll_300m(0), freq: 297000000 Clock: mclk_spdif_8ch_src, parent: cpll(0), freq: 50000000 Clock: mclk_spdif_8ch, parent: mclk_spdif_8ch_src(0), freq: 50000000 mclk_spdif_8ch_frac: rk_clk_fract_recalc denominator is zero! Clock: mclk_spdif_8ch_frac, parent: mclk_spdif_8ch_src(0), freq: = 50000000 Clock: sclk_audpwm_src, parent: gpll(0), freq: 99000000 Clock: sclk_audpwm, parent: sclk_audpwm_src(0), freq: 99000000 sclk_audpwm_frac: rk_clk_fract_recalc denominator is zero! Clock: sclk_audpwm_frac, parent: sclk_audpwm_src(0), freq: 99000000 Clock: clk_acdcdig_i2c, parent: gpll_200m(0), freq: 198000000 Clock: aclk_secure_flash, parent: gpll_200m(0), freq: 198000000 Clock: hclk_secure_flash, parent: gpll_150m(0), freq: 148500000 Clock: clk_crypto_ns_core, parent: gpll_150m(1), freq: 148500000 Clock: clk_crypto_ns_pka, parent: gpll_300m(0), freq: 297000000 Clock: nclk_nandc, parent: gpll_150m(1), freq: 148500000 Clock: sclk_sfc, parent: gpll_100m(3), freq: 99000000 Clock: bclk_emmc, parent: gpll_200m(0), freq: 198000000 Clock: cclk_emmc, parent: clk_osc0_div_375k(5), freq: 375000 Clock: aclk_pipe, parent: gpll_200m(2), freq: 198000000 Clock: pclk_pipe, parent: aclk_pipe(0), freq: 49500000 Clock: clk_usb3otg0_suspend, parent: xin24m(0), freq: 24000000 Clock: clk_usb3otg1_suspend, parent: xin24m(0), freq: 24000000 Clock: clk_xpcs_eee, parent: gpll_200m(0), freq: 198000000 Clock: aclk_php, parent: gpll_300m(0), freq: 297000000 Clock: hclk_php, parent: gpll_150m(0), freq: 148500000 Clock: pclk_php, parent: aclk_php(0), freq: 99000000 Clock: clk_sdmmc0, parent: cpll_50m(4), freq: 50000000 Clock: clk_sdmmc1, parent: xin24m(0), freq: 24000000 Clock: clk_mac0_2top, parent: cpll_125m(0), freq: 125000000 Clock: clk_mac0_out, parent: cpll_125m(0), freq: 125000000 Clock: clk_gmac0_ptp_ref, parent: cpll_62p5(0), freq: 62500000 Clock: clk_gmac0, parent: clk_mac0_2top(0), freq: 125000000 Clock: clk_gmac0_tx_div5, parent: clk_gmac0(0), freq: 25000000 Clock: clk_gmac0_tx_div50, parent: clk_gmac0(0), freq: 2500000 Clock: clk_gmac0_rx_div2, parent: clk_gmac0(0), freq: 62500000 Clock: clk_gmac0_rx_div20, parent: clk_gmac0(0), freq: 6250000 Clock: clk_gmac0_rgmii_speed, parent: clk_gmac0(0), freq: 125000000 Clock: clk_gmac0_rmii_speed, parent: clk_gmac0_rx_div20(0), freq: = 6250000 Clock: clk_gmac0_rx_tx, parent: clk_gmac0_rgmii_speed(0), freq: = 125000000 Clock: aclk_usb, parent: gpll_300m(0), freq: 297000000 Clock: hclk_usb, parent: gpll_150m(0), freq: 148500000 Clock: pclk_usb, parent: aclk_usb(0), freq: 99000000 Clock: clk_sdmmc2, parent: xin24m(0), freq: 24000000 Clock: clk_mac1_2top, parent: cpll_125m(0), freq: 125000000 Clock: clk_mac1_out, parent: cpll_125m(0), freq: 125000000 Clock: clk_gmac1_ptp_ref, parent: cpll_62p5(0), freq: 62500000 Clock: clk_gmac1, parent: clk_mac1_2top(0), freq: 125000000 Clock: clk_gmac1_tx_div5, parent: clk_gmac1(0), freq: 25000000 Clock: clk_gmac1_tx_div50, parent: clk_gmac1(0), freq: 2500000 Clock: clk_gmac1_rx_div2, parent: clk_gmac1(0), freq: 62500000 Clock: clk_gmac1_rx_div20, parent: clk_gmac1(0), freq: 6250000 Clock: clk_gmac1_rgmii_speed, parent: clk_gmac1(0), freq: 125000000 Clock: clk_gmac1_rmii_speed, parent: clk_gmac1_rx_div20(0), freq: = 6250000 Clock: clk_gmac1_rx_tx, parent: clk_gmac1_rgmii_speed(0), freq: = 125000000 Clock: aclk_perimid, parent: gpll_300m(0), freq: 297000000 Clock: hclk_perimid, parent: gpll_150m(0), freq: 148500000 Clock: aclk_vi, parent: gpll_400m(0), freq: 396000000 Clock: hclk_vi, parent: aclk_vi(0), freq: 198000000 Clock: pclk_vi, parent: aclk_vi(0), freq: 99000000 Clock: dclk_vicap, parent: cpll_333m(0), freq: 333333333 Clock: clk_isp, parent: cpll(0), freq: 500000000 Clock: clk_cif_out, parent: xin24m(3), freq: 24000000 Clock: clk_cam0_out, parent: xin24m(3), freq: 24000000 Clock: clk_cam1_out, parent: xin24m(3), freq: 24000000 Clock: aclk_vo, parent: gpll_300m(0), freq: 297000000 Clock: hclk_vo, parent: aclk_vo(0), freq: 148500000 Clock: pclk_vo, parent: aclk_vo(0), freq: 74250000 Clock: aclk_vop_pre, parent: cpll(0), freq: 500000000 Clock: dclk_vop0, parent: hpll(0), freq: 594000000 Clock: dclk_vop1, parent: hpll(0), freq: 297000000 Clock: dclk_vop2, parent: hpll(0), freq: 148500000 Clock: clk_edp_200m, parent: gpll_200m(0), freq: 198000000 Clock: aclk_vpu_pre, parent: gpll(0), freq: 297000000 Clock: hclk_vpu_pre, parent: aclk_vpu_pre(0), freq: 148500000 Clock: aclk_rga_pre, parent: gpll_300m(0), freq: 297000000 Clock: hclk_rga_pre, parent: aclk_rga_pre(0), freq: 148500000 Clock: pclk_rga_pre, parent: aclk_rga_pre(0), freq: 99000000 Clock: clk_rga_core, parent: gpll_300m(0), freq: 297000000 Clock: clk_iep_core, parent: gpll_300m(0), freq: 297000000 Clock: dclk_ebc, parent: gpll_400m(0), freq: 396000000 Clock: aclk_rkvenc_pre, parent: gpll(0), freq: 297000000 Clock: hclk_rkvenc_pre, parent: aclk_rkvenc_pre(0), freq: 99000000 Clock: clk_rkvenc_core, parent: gpll(0), freq: 297000000 Clock: aclk_rkvdec_pre, parent: gpll(0), freq: 396000000 Clock: hclk_rkvdec_pre, parent: aclk_rkvdec_pre(0), freq: 198000000 Clock: clk_rkvdec_ca, parent: gpll(0), freq: 297000000 Clock: clk_rkvdec_core, parent: gpll(0), freq: 297000000 Clock: clk_rkvdec_hevc_ca, parent: gpll(0), freq: 594000000 Clock: aclk_bus, parent: gpll_150m(1), freq: 148500000 Clock: pclk_bus, parent: cpll_50m(2), freq: 50000000 Clock: clk_tsadc_tsen, parent: xin24m(0), freq: 24000000 Clock: clk_tsadc, parent: clk_tsadc_tsen(0), freq: 1200000 Clock: clk_uart1_src, parent: gpll(0), freq: 99000000 clk_uart1_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart1_frac, parent: clk_uart1_src(0), freq: 99000000 Clock: sclk_uart1_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart2_src, parent: gpll(0), freq: 99000000 clk_uart2_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart2_frac, parent: clk_uart2_src(0), freq: 99000000 Clock: sclk_uart2_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart3_src, parent: gpll(0), freq: 99000000 clk_uart3_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart3_frac, parent: clk_uart3_src(0), freq: 99000000 Clock: sclk_uart3_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart4_src, parent: gpll(0), freq: 99000000 clk_uart4_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart4_frac, parent: clk_uart4_src(0), freq: 99000000 Clock: sclk_uart4_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart5_src, parent: gpll(0), freq: 99000000 clk_uart5_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart5_frac, parent: clk_uart5_src(0), freq: 99000000 Clock: sclk_uart5_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart6_src, parent: gpll(0), freq: 99000000 clk_uart6_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart6_frac, parent: clk_uart6_src(0), freq: 99000000 Clock: sclk_uart6_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart7_src, parent: gpll(0), freq: 99000000 clk_uart7_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart7_frac, parent: clk_uart7_src(0), freq: 99000000 Clock: sclk_uart7_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart8_src, parent: gpll(0), freq: 99000000 clk_uart8_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart8_frac, parent: clk_uart8_src(0), freq: 99000000 Clock: sclk_uart8_mux, parent: xin24m(2), freq: 24000000 Clock: clk_uart9_src, parent: gpll(0), freq: 99000000 clk_uart9_frac: rk_clk_fract_recalc denominator is zero! Clock: clk_uart9_frac, parent: clk_uart9_src(0), freq: 99000000 Clock: sclk_uart9_mux, parent: xin24m(2), freq: 24000000 Clock: clk_can0, parent: gpll(0), freq: 297000000 Clock: clk_can1, parent: gpll(0), freq: 297000000 Clock: clk_can2, parent: gpll(0), freq: 297000000 Clock: clk_i2c, parent: xin24m(2), freq: 24000000 Clock: clk_spi0, parent: gpll_200m(0), freq: 198000000 Clock: clk_spi1, parent: gpll_200m(0), freq: 198000000 Clock: clk_spi2, parent: gpll_200m(0), freq: 198000000 Clock: clk_spi3, parent: gpll_200m(0), freq: 198000000 Clock: clk_pwm1, parent: xin24m(1), freq: 24000000 Clock: clk_pwm2, parent: xin24m(1), freq: 24000000 Clock: clk_pwm3, parent: xin24m(1), freq: 24000000 Clock: dbclk_gpio, parent: xin24m(0), freq: 24000000 Clock: aclk_top_high, parent: gpll_300m(2), freq: 297000000 Clock: aclk_top_low, parent: gpll_200m(2), freq: 198000000 Clock: hclk_top, parent: gpll_150m(0), freq: 148500000 Clock: pclk_top, parent: cpll_50m(2), freq: 50000000 Clock: clk_optc_arb, parent: xin24m(0), freq: 24000000 Clock: clk_core_pvtm, parent: xin24m(0), freq: 24000000 Clock: clk_core_pvtm_core, parent: armclk(0), freq: 816000000 Clock: clk_core_pvtpll, parent: armclk(0), freq: 816000000 Clock: pclk_core_pvtm, parent: pclk_core_pre(0), freq: 204000000 Clock: clk_gpu, parent: clk_gpu_pre_mux(0), freq: 500000000 Clock: pclk_gpu_pvtm, parent: pclk_gpu_pre(0), freq: 100000000 Clock: clk_gpu_pvtm, parent: xin24m(0), freq: 24000000 Clock: clk_gpu_pvtm_core, parent: clk_gpu_src(0), freq: 500000000 Clock: clk_gpu_pvtpll, parent: clk_gpu_src(0), freq: 500000000 Clock: aclk_npu_pre, parent: clk_npu(0), freq: 600000000 Clock: aclk_npu, parent: aclk_npu_pre(0), freq: 600000000 Clock: hclk_npu, parent: hclk_npu_pre(0), freq: 150000000 Clock: pclk_npu_pvtm, parent: pclk_npu_pre(0), freq: 100000000 Clock: clk_npu_pvtm, parent: xin24m(0), freq: 24000000 Clock: clk_npu_pvtm_core, parent: clk_npu_pre_ndft(0), freq: 600000000 Clock: clk_npu_pvtpll, parent: clk_npu_pre_ndft(0), freq: 600000000 Clock: clk24_ddrmon, parent: xin24m(0), freq: 24000000 Clock: hclk_sdmmc_buffer, parent: hclk_gic_audio(0), freq: 148500000 Clock: aclk_gic600, parent: aclk_gic_audio(0), freq: 198000000 Clock: aclk_spinlock, parent: aclk_gic_audio(0), freq: 198000000 Clock: hclk_pdm, parent: hclk_gic_audio(0), freq: 148500000 Clock: hclk_vad, parent: hclk_gic_audio(0), freq: 148500000 Clock: hclk_spdif_8ch, parent: hclk_gic_audio(0), freq: 148500000 Clock: hclk_audpwm, parent: hclk_gic_audio(0), freq: 148500000 Clock: hclk_acdcdig, parent: hclk_gic_audio(0), freq: 148500000 Clock: aclk_crypto_ns, parent: aclk_secure_flash(0), freq: 198000000 Clock: hclk_crypto_ns, parent: hclk_secure_flash(0), freq: 148500000 Clock: clk_crypto_ns_rng, parent: hclk_secure_flash(0), freq: 148500000 Clock: hclk_trng_ns, parent: hclk_secure_flash(0), freq: 148500000 Clock: clk_trng_ns, parent: hclk_secure_flash(0), freq: 148500000 Clock: pclk_otpc_ns, parent: hclk_secure_flash(0), freq: 148500000 Clock: clk_otpc_ns_sbpi, parent: xin24m(0), freq: 24000000 Clock: clk_otpc_ns_usr, parent: xin_osc0_half(0), freq: 12000000 Clock: hclk_nandc, parent: hclk_secure_flash(0), freq: 148500000 Clock: hclk_sfc, parent: hclk_secure_flash(0), freq: 148500000 Clock: hclk_sfc_xip, parent: hclk_secure_flash(0), freq: 148500000 Clock: aclk_emmc, parent: aclk_secure_flash(0), freq: 198000000 Clock: hclk_emmc, parent: hclk_secure_flash(0), freq: 148500000 Clock: tclk_emmc, parent: xin24m(0), freq: 24000000 Clock: aclk_pcie20_mst, parent: aclk_pipe(0), freq: 198000000 Clock: aclk_pcie20_slv, parent: aclk_pipe(0), freq: 198000000 Clock: aclk_pcie20_dbi, parent: aclk_pipe(0), freq: 198000000 Clock: pclk_pcie20, parent: pclk_pipe(0), freq: 49500000 Clock: clk_pcie20_aux_ndft, parent: xin24m(0), freq: 24000000 Clock: aclk_pcie30x1_mst, parent: aclk_pipe(0), freq: 198000000 Clock: aclk_pcie30x1_slv, parent: aclk_pipe(0), freq: 198000000 Clock: aclk_pcie30x1_dbi, parent: aclk_pipe(0), freq: 198000000 Clock: pclk_pcie30x1, parent: pclk_pipe(0), freq: 49500000 Clock: clk_pcie30x1_aux_ndft, parent: xin24m(0), freq: 24000000 Clock: aclk_pcie30x2_mst, parent: aclk_pipe(0), freq: 198000000 Clock: aclk_pcie30x2_slv, parent: aclk_pipe(0), freq: 198000000 Clock: aclk_pcie30x2_dbi, parent: aclk_pipe(0), freq: 198000000 Clock: pclk_pcie30x2, parent: pclk_pipe(0), freq: 49500000 Clock: clk_pcie30x2_aux_ndft, parent: xin24m(0), freq: 24000000 Clock: aclk_sata0, parent: aclk_pipe(0), freq: 198000000 Clock: clk_sata0_pmalive, parent: gpll_20m(0), freq: 19800000 Clock: clk_sata0_rxoob, parent: cpll_50m(0), freq: 50000000 Clock: aclk_sata1, parent: aclk_pipe(0), freq: 198000000 Clock: clk_sata1_pmalive, parent: gpll_20m(0), freq: 19800000 Clock: clk_sata1_rxoob, parent: cpll_50m(0), freq: 50000000 Clock: aclk_sata2, parent: aclk_pipe(0), freq: 198000000 Clock: clk_sata2_pmalive, parent: gpll_20m(0), freq: 19800000 Clock: clk_sata2_rxoob, parent: cpll_50m(0), freq: 50000000 Clock: aclk_usb3otg0, parent: aclk_pipe(0), freq: 198000000 Clock: clk_usb3otg0_ref, parent: xin24m(0), freq: 24000000 Clock: aclk_usb3otg1, parent: aclk_pipe(0), freq: 198000000 Clock: clk_usb3otg1_ref, parent: xin24m(0), freq: 24000000 Clock: pclk_xpcs, parent: pclk_pipe(0), freq: 49500000 Clock: hclk_sdmmc0, parent: hclk_php(0), freq: 148500000 Clock: hclk_sdmmc1, parent: hclk_php(0), freq: 148500000 Clock: aclk_gmac0, parent: aclk_php(0), freq: 297000000 Clock: pclk_gmac0, parent: pclk_php(0), freq: 99000000 Clock: clk_mac0_refout, parent: clk_mac0_2top(0), freq: 125000000 Clock: hclk_usb2host0, parent: hclk_usb(0), freq: 148500000 Clock: hclk_usb2host0_arb, parent: hclk_usb(0), freq: 148500000 Clock: hclk_usb2host1, parent: hclk_usb(0), freq: 148500000 Clock: hclk_usb2host1_arb, parent: hclk_usb(0), freq: 148500000 Clock: hclk_sdmmc2, parent: hclk_usb(0), freq: 148500000 Clock: aclk_gmac1, parent: aclk_usb(0), freq: 297000000 Clock: pclk_gmac1, parent: pclk_usb(0), freq: 99000000 Clock: clk_mac1_refout, parent: clk_mac1_2top(0), freq: 125000000 Clock: aclk_vicap, parent: aclk_vi(0), freq: 396000000 Clock: hclk_vicap, parent: hclk_vi(0), freq: 198000000 Clock: aclk_isp, parent: aclk_vi(0), freq: 396000000 Clock: hclk_isp, parent: hclk_vi(0), freq: 198000000 Clock: pclk_csi2host1, parent: pclk_vi(0), freq: 99000000 Clock: aclk_vop, parent: aclk_vop_pre(0), freq: 500000000 Clock: hclk_vop, parent: hclk_vo(0), freq: 148500000 Clock: clk_vop_pwm, parent: xin24m(0), freq: 24000000 Clock: aclk_hdcp, parent: aclk_vo(0), freq: 297000000 Clock: hclk_hdcp, parent: hclk_vo(0), freq: 148500000 Clock: pclk_hdcp, parent: pclk_vo(0), freq: 74250000 Clock: pclk_hdmi_host, parent: pclk_vo(0), freq: 74250000 Clock: clk_hdmi_sfr, parent: xin24m(0), freq: 24000000 Clock: clk_hdmi_cec, parent: clk_rtc_32k(0), freq: 24000000 Clock: pclk_dsitx_0, parent: pclk_vo(0), freq: 74250000 Clock: pclk_dsitx_1, parent: pclk_vo(0), freq: 74250000 Clock: pclk_edp_ctrl, parent: pclk_vo(0), freq: 74250000 Clock: aclk_vpu, parent: aclk_vpu_pre(0), freq: 297000000 Clock: hclk_vpu, parent: hclk_vpu_pre(0), freq: 148500000 Clock: aclk_rga, parent: aclk_rga_pre(0), freq: 297000000 Clock: hclk_rga, parent: hclk_rga_pre(0), freq: 148500000 Clock: aclk_iep, parent: aclk_rga_pre(0), freq: 297000000 Clock: hclk_iep, parent: hclk_rga_pre(0), freq: 148500000 Clock: hclk_ebc, parent: hclk_rga_pre(0), freq: 148500000 Clock: aclk_jdec, parent: aclk_rga_pre(0), freq: 297000000 Clock: hclk_jdec, parent: hclk_rga_pre(0), freq: 148500000 Clock: aclk_jenc, parent: aclk_rga_pre(0), freq: 297000000 Clock: hclk_jenc, parent: hclk_rga_pre(0), freq: 148500000 Clock: pclk_eink, parent: pclk_rga_pre(0), freq: 99000000 Clock: hclk_eink, parent: hclk_rga_pre(0), freq: 148500000 Clock: aclk_rkvenc, parent: aclk_rkvenc_pre(0), freq: 297000000 Clock: hclk_rkvenc, parent: hclk_rkvenc_pre(0), freq: 99000000 Clock: aclk_rkvdec, parent: aclk_rkvdec_pre(0), freq: 396000000 Clock: hclk_rkvdec, parent: hclk_rkvdec_pre(0), freq: 198000000 Clock: pclk_tsadc, parent: pclk_bus(0), freq: 50000000 Clock: pclk_saradc, parent: pclk_bus(0), freq: 50000000 Clock: clk_saradc, parent: xin24m(0), freq: 24000000 Clock: pclk_scr, parent: pclk_bus(0), freq: 50000000 Clock: pclk_wdt_ns, parent: pclk_bus(0), freq: 50000000 Clock: tclk_wdt_ns, parent: xin24m(0), freq: 24000000 Clock: aclk_mcu, parent: aclk_bus(0), freq: 148500000 Clock: pclk_intmux, parent: pclk_bus(0), freq: 50000000 Clock: pclk_mailbox, parent: pclk_bus(0), freq: 50000000 Clock: pclk_uart1, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart1, parent: sclk_uart1_mux(0), freq: 24000000 Clock: pclk_uart2, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart2, parent: sclk_uart2_mux(0), freq: 24000000 Clock: pclk_uart3, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart3, parent: sclk_uart3_mux(0), freq: 24000000 Clock: pclk_uart4, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart4, parent: sclk_uart4_mux(0), freq: 24000000 Clock: pclk_uart5, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart5, parent: sclk_uart5_mux(0), freq: 24000000 Clock: pclk_uart6, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart6, parent: sclk_uart6_mux(0), freq: 24000000 Clock: pclk_uart7, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart7, parent: sclk_uart7_mux(0), freq: 24000000 Clock: pclk_uart8, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart8, parent: sclk_uart8_mux(0), freq: 24000000 Clock: pclk_uart9, parent: pclk_bus(0), freq: 50000000 Clock: sclk_uart9, parent: sclk_uart9_mux(0), freq: 24000000 Clock: pclk_can0, parent: pclk_bus(0), freq: 50000000 Clock: pclk_can1, parent: pclk_bus(0), freq: 50000000 Clock: pclk_can2, parent: pclk_bus(0), freq: 50000000 Clock: pclk_i2c1, parent: pclk_bus(0), freq: 50000000 Clock: clk_i2c1, parent: clk_i2c(0), freq: 24000000 Clock: pclk_i2c2, parent: pclk_bus(0), freq: 50000000 Clock: clk_i2c2, parent: clk_i2c(0), freq: 24000000 Clock: pclk_i2c3, parent: pclk_bus(0), freq: 50000000 Clock: clk_i2c3, parent: clk_i2c(0), freq: 24000000 Clock: pclk_i2c4, parent: pclk_bus(0), freq: 50000000 Clock: clk_i2c4, parent: clk_i2c(0), freq: 24000000 Clock: pclk_i2c5, parent: pclk_bus(0), freq: 50000000 Clock: clk_i2c5, parent: clk_i2c(0), freq: 24000000 Clock: pclk_spi0, parent: pclk_bus(0), freq: 50000000 Clock: pclk_spi1, parent: pclk_bus(0), freq: 50000000 Clock: pclk_spi2, parent: pclk_bus(0), freq: 50000000 Clock: pclk_spi3, parent: pclk_bus(0), freq: 50000000 Clock: pclk_pwm1, parent: pclk_bus(0), freq: 50000000 Clock: clk_pwm1_capture, parent: xin24m(0), freq: 24000000 Clock: pclk_pwm2, parent: pclk_bus(0), freq: 50000000 Clock: clk_pwm2_capture, parent: xin24m(0), freq: 24000000 Clock: pclk_pwm3, parent: pclk_bus(0), freq: 50000000 Clock: clk_pwm3_capture, parent: xin24m(0), freq: 24000000 Clock: pclk_gpio1, parent: pclk_bus(0), freq: 50000000 Clock: dbclk_gpio1, parent: dbclk_gpio(0), freq: 24000000 Clock: pclk_gpio2, parent: pclk_bus(0), freq: 50000000 Clock: dbclk_gpio2, parent: dbclk_gpio(0), freq: 24000000 Clock: pclk_gpio3, parent: pclk_bus(0), freq: 50000000 Clock: dbclk_gpio3, parent: dbclk_gpio(0), freq: 24000000 Clock: pclk_gpio4, parent: pclk_bus(0), freq: 50000000 Clock: dbclk_gpio4, parent: dbclk_gpio(0), freq: 24000000 Clock: pclk_timer, parent: pclk_bus(0), freq: 50000000 Clock: clk_timer0, parent: xin24m(0), freq: 24000000 Clock: clk_timer1, parent: xin24m(0), freq: 24000000 Clock: clk_timer2, parent: xin24m(0), freq: 24000000 Clock: clk_timer3, parent: xin24m(0), freq: 24000000 Clock: clk_timer4, parent: xin24m(0), freq: 24000000 Clock: clk_timer5, parent: xin24m(0), freq: 24000000 Clock: pclk_pcie30phy, parent: pclk_top(0), freq: 50000000 Clock: pclk_mipicsiphy, parent: pclk_top(0), freq: 50000000 Clock: pclk_mipidsiphy0, parent: pclk_top(0), freq: 50000000 Clock: pclk_mipidsiphy1, parent: pclk_top(0), freq: 50000000 Clock: pclk_pipephy0, parent: pclk_top(0), freq: 50000000 Clock: pclk_pipephy1, parent: pclk_top(0), freq: 50000000 Clock: pclk_pipephy2, parent: pclk_top(0), freq: 50000000 Clock: pclk_cpu_boost, parent: pclk_top(0), freq: 50000000 Clock: clk_cpu_boost, parent: xin24m(0), freq: 24000000 Clock: pclk_otpphy, parent: pclk_top(0), freq: 50000000 Clock: pclk_edpphy_grf, parent: pclk_top(0), freq: 50000000 rk3568_cru0: Set cpll to 1000000000 rk3568_cru0: Set cpll_333m to 333000000 rk3568_cru0: Set cpll_250m to 250000000 rk3568_cru0: Set cpll_125m to 125000000 rk3568_cru0: Set cpll_100m to 100000000 rk3568_cru0: Set cpll_50m to 50000000 rk3568_cru0: Set cpll_25m to 25000000 sclk_audpwm_frac: rk_clk_fract_recalc denominator is zero! clk_uart1_frac: rk_clk_fract_recalc denominator is zero! clk_uart2_frac: rk_clk_fract_recalc denominator is zero! clk_uart3_frac: rk_clk_fract_recalc denominator is zero! clk_uart4_frac: rk_clk_fract_recalc denominator is zero! clk_uart5_frac: rk_clk_fract_recalc denominator is zero! clk_uart6_frac: rk_clk_fract_recalc denominator is zero! clk_uart7_frac: rk_clk_fract_recalc denominator is zero! clk_uart8_frac: rk_clk_fract_recalc denominator is zero! clk_uart9_frac: rk_clk_fract_recalc denominator is zero! rk3568_cru0: Set gpll to 1200000000 rk3568_cru0: cannot get assigned clock at idx 8 rk3568_cru0: cannot get assigned clock at idx 9 rk3568_cru0: cannot get assigned clock at idx 10 rk3568_cru0: cannot get assigned clock at idx 11 rk3568_cru0: cannot get assigned clock at idx 12 rk3568_cru0: cannot get assigned clock at idx 13 rk3568_cru0: cannot get assigned clock at idx 14 rk3568_cru0: Set aclk_top_high to 500000000 rk3568_cru0: Set aclk_top_low to 400000000 rk3568_cru0: Set pclk_top to 100000000 rk3568_cru0: Set pclk_bus to 100000000 rk3568_cru0: Set aclk_pipe to 400000000 sclk_uart0_frac: rk_clk_fract_recalc denominator is zero! rk3568_cru0: Set ppll to 200000000 rk3568_cru0: Set clk_rtc32k_frac to 32768 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 regfix4: on ofwbus0 regfix5: on ofwbus0 regfix6: on ofwbus0 simple_mfd0: mem = 0xfdc20000-0xfdc2ffff on ofwbus0 simple_mfd1: mem = 0xfdc60000-0xfdc6ffff on ofwbus0 simple_mfd2: mem = 0xfdd90000-0xfdd90fff on ofwbus0 psci0: on ofwbus0 psci0: PSCI version 0.2 compatible gic0: mem = 0xfd400000-0xfd40ffff,0xfd460000-0xfd51ffff irq 10 on ofwbus0 gic0: SPIs: 352, IDs: 65535 gic0: Start searching for Re-Distributor gic0: CPU0 Re-Distributor has been found gic0: CPU0 Re-Distributor woke up gic0: CPU0 enabled CPU interface via system registers its0: mem 0xfd440000-0xfd45ffff = on gic0 its0: Timeout while waiting for CMD completion. rk_i2c0: mem 0xfdd40000-0xfdd40fff irq 15 on ofwbus0 iicbus0: on rk_i2c0 rk_i2c1: mem 0xfe5a0000-0xfe5a0fff irq 78 on ofwbus0 iicbus1: on rk_i2c1 generic_timer0: irq 4,5,6,7 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 efirtc0: cannot read EFI realtime clock, error 5 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu0: missing 'clock-frequency' property cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 cpu1: on cpulist0 cpu1: missing 'clock-frequency' property cpufreq_dt1: on cpu1 cpufreq_dt1: no regulator for cpu@100 device_attach: cpufreq_dt1 attach returned 6 cpu2: on cpulist0 cpu2: missing 'clock-frequency' property cpufreq_dt2: on cpu2 cpufreq_dt2: no regulator for cpu@200 device_attach: cpufreq_dt2 attach returned 6 cpu3: on cpulist0 cpu3: missing 'clock-frequency' property cpufreq_dt3: on cpu3 cpufreq_dt3: no regulator for cpu@300 device_attach: cpufreq_dt3 attach returned 6 ofwbus0: compat operating-points-v2 (no driver = attached) pmu0: irq 0,1,2,3 on ofwbus0 ofwbus0: no default resources for rid =3D 4, type =3D 1 ofwbus0: compat rockchip,cpuinfo (no driver attached) ofwbus0: compat rockchip,display-subsystem (no = driver attached) ofwbus0: compat rockchip,mpp-service (no driver attached) ofwbus0: compat rockchip,system-monitor (no = driver attached) ofwbus0: mem 0x10f000-0x10f0ff compat arm,scmi-shmem = (no driver attached) ofwbus0: mem 0xfc400000-0xfc400fff irq 8 disabled compat = snps,dwc-ahci (no driver attached) ofwbus0: mem 0xfc800000-0xfc800fff irq 9 disabled compat = snps,dwc-ahci (no driver attached) rk_dwc30: on ofwbus0 rk_dwc30: Cannot get grf_clk clock device_attach: rk_dwc30 attach returned 6 rk_dwc30: on ofwbus0 rk_dwc30: Cannot get grf_clk clock device_attach: rk_dwc30 attach returned 6 ehci0: mem 0xfd800000-0xfd83ffff irq 11 on = ofwbus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached ohci0: mem 0xfd840000-0xfd87ffff irq 12 on = ofwbus0 usbus1 on ohci0 ohci0: usbpf: Attached ehci1: mem 0xfd880000-0xfd8bffff irq 13 on = ofwbus0 usbus2: EHCI version 1.0 usbus2 on ehci1 ehci1: usbpf: Attached ohci1: mem 0xfd8c0000-0xfd8fffff irq 14 on = ofwbus0 usbus3 on ohci1 ohci1: usbpf: Attached simple_mfd0: mem 0xfdc20000-0xfdc2ffff compat = rockchip,rk3568-pmu-io-voltage-domain (no driver attached) simple_mfd0: mem 0xfdc20000-0xfdc2ffff compat = syscon-reboot-mode (no driver attached) syscon_generic_dev0: mem 0xfdc50000-0xfdc50fff on ofwbus0 simple_mfd1: mem 0xfdc60000-0xfdc6ffff disabled compat = rockchip,rk3568-io-voltage-domain (no driver attached) simple_mfd1: mem 0xfdc60000-0xfdc6ffff disabled compat = rockchip,rk3568-lvds (no driver attached) simple_mfd1: mem 0xfdc60000-0xfdc6ffff disabled compat = rockchip,rk3568-rgb (no driver attached) syscon_generic_dev1: mem 0xfdc70000-0xfdc70fff on ofwbus0 syscon_generic_dev2: mem 0xfdc80000-0xfdc80fff on ofwbus0 syscon_generic_dev3: mem 0xfdc90000-0xfdc90fff on ofwbus0 syscon_generic_dev4: mem 0xfdca0000-0xfdca7fff on ofwbus0 syscon_generic_dev5: mem 0xfdca8000-0xfdcaffff on ofwbus0 ofwbus0: mem 0xfdcb0000-0xfdcb7fff disabled compat = rockchip,rk3568-edp-phy (no driver attached) ofwbus0: mem 0xfdcc0000-0xfdccafff compat mmio-sram (no = driver attached) iicbus0: at addr 0x38 iicbus0: at addr 0x40 iic0: on iicbus0 ofwbus0: no default resources for rid =3D 0, type =3D 4 ofwbus0: no default resources for rid =3D 0, type =3D 4 uart0: <16750 or compatible> mem 0xfdd50000-0xfdd500ff irq 16 on ofwbus0 uart0: fast interrupt uart0: PPS capture mode: DCD ofwbus0: mem 0xfdd70000-0xfdd7000f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfdd70010-0xfdd7001f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfdd70020-0xfdd7002f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfdd70030-0xfdd7003f disabled compat = rockchip,rk3568-pwm (no driver attached) simple_mfd2: mem 0xfdd90000-0xfdd90fff disabled = compat rockchip,rk3568-power-controller (no driver attached) ofwbus0: mem 0xfde00000-0xfde000ff compat = rockchip,rk3568-core-pvtm (no driver attached) ofwbus0: mem 0xfde40000-0xfde4ffff irq 17 disabled compat = rockchip,rknpu (no driver attached) ofwbus0: compat operating-points-v2 (no driver attached) ofwbus0: mem 0xfde4b000-0xfde4b03f irq 18 disabled = compat rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfde60000-0xfde7ffff irq 19,20,21 disabled = compat arm,mali-t604 (no driver attached) ofwbus0: compat operating-points-v2 (no driver attached) ofwbus0: mem 0xfde80000-0xfde800ff compat = rockchip,rk3568-gpu-pvtm (no driver attached) ofwbus0: mem 0xfde90000-0xfde900ff compat = rockchip,rk3568-npu-pvtm (no driver attached) ofwbus0: mem 0xfdea0400-0xfdea07ff irq 22 compat = rockchip,vpu-decoder-v2 (no driver attached) ofwbus0: mem 0xfdea0800-0xfdea083f irq 23 compat = rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfdeb0000-0xfdeb0fff irq 24 compat = rockchip,rga2 (no driver attached) ofwbus0: mem 0xfdec0000-0xfdec4fff irq 25 disabled compat = rockchip,rk3568-ebc-tcon (no driver attached) ofwbus0: mem 0xfded0000-0xfded03ff irq 26 compat = rockchip,rkv-jpeg-decoder-v1 (no driver attached) ofwbus0: mem 0xfded0480-0xfded04bf irq 27 compat = rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfdee0000-0xfdee03ff irq 28 compat = rockchip,vpu-encoder-v2 (no driver attached) ofwbus0: mem 0xfdee0800-0xfdee083f irq 29 compat = rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfdef0000-0xfdef04ff irq 30 disabled compat = rockchip,iep-v2 (no driver attached) ofwbus0: mem 0xfdef0800-0xfdef08ff irq 31 disabled = compat rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfdf00000-0xfdf00073 irq 32 disabled = compat rockchip,rk3568-eink-tcon (no driver attached) ofwbus0: mem 0xfdf40000-0xfdf403ff irq 33 compat = rockchip,rkv-encoder-v1 (no driver attached) ofwbus0: mem = 0xfdf40f00-0xfdf40f3f,0xfdf40f40-0xfdf40f7f irq 34,35 compat = rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfdf80200-0xfdf805ff irq 36 compat = rockchip,rkv-decoder-v2 (no driver attached) ofwbus0: mem = 0xfdf80800-0xfdf8083f,0xfdf80840-0xfdf8087f irq 37 compat = rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfdfb0000-0xfdfbffff irq 38,39 = disabled compat rockchip,rk3568-mipi-csi2 (no driver attached) ofwbus0: mem 0xfdfe0000-0xfdfe7fff irq 40 disabled = compat rockchip,rk3568-cif (no driver attached) ofwbus0: mem 0xfdfe0800-0xfdfe08ff irq 41 disabled = compat rockchip,iommu (no driver attached) ofwbus0: disabled compat rockchip,rkcif-dvp (no driver = attached) ofwbus0: disabled compat rockchip,rkcif-sditf (no = driver attached) ofwbus0: disabled compat rockchip,rkcif-mipi-lvds (no = driver attached) ofwbus0: disabled compat rockchip,rkcif-sditf = (no driver attached) ofwbus0: mem 0xfdff0000-0xfdffffff irq 42,43,44 = disabled compat rockchip,rk3568-rkisp (no driver attached) ofwbus0: mem 0xfdff1a00-0xfdff1aff irq 45 disabled = compat rockchip,iommu (no driver attached) ofwbus0: disabled compat rockchip,rkisp-vir (no driver = attached) ofwbus0: disabled compat rockchip,rkisp-vir (no driver = attached) ofwbus0: mem 0xfe010000-0xfe01ffff irq 46,47 compat = rockchip,rk3568-gmac (no driver attached) ofwbus0: mem 0xfe040000-0xfe042fff,0xfe044000-0xfe044fff = irq 48 compat rockchip,rk3568-vop (no driver attached) ofwbus0: mem = 0xfe043e00-0xfe043eff,0xfe043f00-0xfe043fff irq 49 compat = rockchip,iommu-v2 (no driver attached) ofwbus0: mem 0xfe060000-0xfe06ffff irq 50 disabled compat = rockchip,rk3568-mipi-dsi (no driver attached) ofwbus0: mem 0xfe070000-0xfe07ffff irq 51 disabled compat = rockchip,rk3568-mipi-dsi (no driver attached) ofwbus0: mem 0xfe0a0000-0xfe0bffff irq 52 compat = rockchip,rk3568-dw-hdmi (no driver attached) ofwbus0: mem 0xfe0c0000-0xfe0cffff irq 53 disabled compat = rockchip,rk3568-edp (no driver attached) syscon_generic_dev6: mem 0xfe128000-0xfe12801f on ofwbus0 syscon_generic_dev7: mem 0xfe138080-0xfe13809f on ofwbus0 syscon_generic_dev8: mem 0xfe138100-0xfe13811f on ofwbus0 syscon_generic_dev9: mem 0xfe138180-0xfe13819f on ofwbus0 syscon_generic_dev10: mem 0xfe148000-0xfe14801f on ofwbus0 syscon_generic_dev11: mem 0xfe148080-0xfe14809f on ofwbus0 syscon_generic_dev12: mem 0xfe148100-0xfe14811f on ofwbus0 syscon_generic_dev13: mem 0xfe150000-0xfe15001f on ofwbus0 syscon_generic_dev14: mem 0xfe158000-0xfe15801f on ofwbus0 syscon_generic_dev15: mem 0xfe158100-0xfe15811f on ofwbus0 syscon_generic_dev16: mem 0xfe158180-0xfe15819f on ofwbus0 syscon_generic_dev17: mem 0xfe158200-0xfe15821f on ofwbus0 syscon_generic_dev18: mem 0xfe158280-0xfe15829f on ofwbus0 syscon_generic_dev19: mem 0xfe158300-0xfe15831f on ofwbus0 syscon_generic_dev20: mem 0xfe180000-0xfe18001f on ofwbus0 syscon_generic_dev21: mem 0xfe190000-0xfe19001f on ofwbus0 syscon_generic_dev22: mem 0xfe190280-0xfe19029f on ofwbus0 syscon_generic_dev23: mem 0xfe190300-0xfe19031f on ofwbus0 syscon_generic_dev24: mem 0xfe190380-0xfe19039f on ofwbus0 syscon_generic_dev25: mem 0xfe190400-0xfe19041f on ofwbus0 syscon_generic_dev26: mem 0xfe198000-0xfe19801f on ofwbus0 syscon_generic_dev27: mem 0xfe1a8000-0xfe1a801f on ofwbus0 syscon_generic_dev28: mem 0xfe1a8080-0xfe1a809f on ofwbus0 syscon_generic_dev29: mem 0xfe1a8100-0xfe1a811f on ofwbus0 ofwbus0: mem 0xfe000000-0xfe003fff irq 54 disabled = compat rockchip,rk3568-dw-mshc (no driver attached) ofwbus0: mem 0xfe230000-0xfe2303ff disabled compat = rockchip,rk3568-dfi (no driver attached) ofwbus0: mem = 0x3c0000000-0x3c03fffff,0xfe260000-0xfe26ffff,0x33f800000-0x33fffffff = irq 55,56,57,58,59 type pci compat rockchip,rk3568-pcie (no driver = attached) rockchip_dwmmc0: mem 0xfe2b0000-0xfe2b3fff irq 60 on ofwbus0 rockchip_dwmmc0: Hardware version ID is 270a rockchip_dwmmc0: Card inserted mmc0: on rockchip_dwmmc0 rockchip_dwmmc1: mem 0xfe2c0000-0xfe2c3fff irq 61 on ofwbus0 rockchip_dwmmc1: Hardware version ID is 270a ofwbus0: mem 0xfe300000-0xfe303fff irq 62 disabled compat = rockchip,sfc (no driver attached) ofwbus0: mem 0xfe310000-0xfe31ffff irq 63 compat = rockchip,rk3568-dwcmshc (no driver attached) ofwbus0: mem 0xfe330000-0xfe333fff irq 64 disabled = compat rockchip,rk-nandc-v9 (no driver attached) ofwbus0: mem 0xfe388000-0xfe389fff compat = rockchip,cryptov2-rng (no driver attached) ofwbus0: mem 0xfe38c000-0xfe38ffff compat = rockchip,rk3568-otp (no driver attached) ofwbus0: mem 0xfe400000-0xfe400fff irq 65 disabled compat = rockchip,rk3568-i2s-tdm (no driver attached) ofwbus0: mem 0xfe410000-0xfe410fff irq 66 disabled compat = rockchip,rk3568-i2s-tdm (no driver attached) ofwbus0: mem 0xfe420000-0xfe420fff irq 67 disabled compat = rockchip,rk3568-i2s-tdm (no driver attached) ofwbus0: mem 0xfe430000-0xfe430fff irq 68 disabled compat = rockchip,rk3568-i2s-tdm (no driver attached) ofwbus0: mem 0xfe440000-0xfe440fff disabled compat = rockchip,rk3568-pdm (no driver attached) ofwbus0: mem 0xfe450000-0xfe45ffff irq 69 disabled compat = rockchip,rk3568-vad (no driver attached) ofwbus0: mem 0xfe460000-0xfe460fff irq 70 disabled = compat rockchip,rk3568-spdif (no driver attached) ofwbus0: mem 0xfe470000-0xfe470fff disabled compat = rockchip,rk3568-audio-pwm (no driver attached) ofwbus0: mem 0xfe478000-0xfe478fff disabled = compat rockchip,rk3568-codec-digital (no driver attached) ofwbus0: mem 0xfe530000-0xfe533fff irq 71,72 disabled = compat arm,pl330 (no driver attached) ofwbus0: mem 0xfe550000-0xfe553fff irq 73,74 disabled = compat arm,pl330 (no driver attached) ofwbus0: mem 0xfe570000-0xfe570fff irq 75 disabled compat = rockchip,canfd-1.0 (no driver attached) ofwbus0: mem 0xfe580000-0xfe580fff irq 76 disabled compat = rockchip,canfd-1.0 (no driver attached) ofwbus0: mem 0xfe590000-0xfe590fff irq 77 disabled compat = rockchip,canfd-1.0 (no driver attached) iicbus1: at addr 0xd0 iic1: on iicbus1 ofwbus0: mem 0xfe5b0000-0xfe5b0fff irq 79 disabled compat = rockchip,rk3399-i2c (no driver attached) ofwbus0: mem 0xfe5c0000-0xfe5c0fff irq 80 disabled compat = rockchip,rk3399-i2c (no driver attached) ofwbus0: mem 0xfe5d0000-0xfe5d0fff irq 81 disabled compat = rockchip,rk3399-i2c (no driver attached) ofwbus0: mem 0xfe5e0000-0xfe5e0fff irq 82 disabled compat = rockchip,rk3399-i2c (no driver attached) ofwbus0: mem 0xfe600000-0xfe6000ff irq 83 compat = snps,dw-wdt (no driver attached) ofwbus0: mem 0xfe610000-0xfe610fff irq 84 disabled compat = rockchip,rk3568-spi (no driver attached) ofwbus0: mem 0xfe620000-0xfe620fff irq 85 disabled compat = rockchip,rk3568-spi (no driver attached) ofwbus0: mem 0xfe630000-0xfe630fff irq 86 disabled compat = rockchip,rk3568-spi (no driver attached) ofwbus0: mem 0xfe640000-0xfe640fff irq 87 disabled compat = rockchip,rk3568-spi (no driver attached) ofwbus0: no default resources for rid =3D 0, type =3D 4 ofwbus0: no default resources for rid =3D 0, type =3D 4 uart1: <16750 or compatible> mem 0xfe650000-0xfe6500ff irq 88 on ofwbus0 uart1: fast interrupt uart1: PPS capture mode: DCD ofwbus0: no default resources for rid =3D 0, type =3D 4 ofwbus0: no default resources for rid =3D 0, type =3D 4 uart2: <16750 or compatible> mem 0xfe660000-0xfe6600ff irq 89 on ofwbus0 uart2: console (1500000,n,8,1) uart2: fast interrupt uart2: PPS capture mode: DCD ofwbus0: mem 0xfe670000-0xfe6700ff irq 90 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe680000-0xfe6800ff irq 91 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe690000-0xfe6900ff irq 92 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe6a0000-0xfe6a00ff irq 93 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe6b0000-0xfe6b00ff irq 94 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe6c0000-0xfe6c00ff irq 95 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe6d0000-0xfe6d00ff irq 96 disabled = compat rockchip,rk3568-uart (no driver attached) ofwbus0: mem 0xfe6e0000-0xfe6e000f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6e0010-0xfe6e001f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6e0020-0xfe6e002f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6e0030-0xfe6e003f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6f0000-0xfe6f000f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6f0010-0xfe6f001f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6f0020-0xfe6f002f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe6f0030-0xfe6f003f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe700000-0xfe70000f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe700010-0xfe70001f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe700020-0xfe70002f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe700030-0xfe70003f disabled compat = rockchip,rk3568-pwm (no driver attached) ofwbus0: mem 0xfe710000-0xfe7100ff irq 97 compat = rockchip,rk3568-tsadc (no driver attached) ofwbus0: mem 0xfe720000-0xfe7200ff irq 98 disabled = compat rockchip,rk3568-saradc (no driver attached) ofwbus0: mem 0xfe780000-0xfe780fff irq 99,100,101,102 = disabled compat rockchip,rk3568-mailbox (no driver attached) ofwbus0: mem 0xfe820000-0xfe8200ff disabled compat = rockchip,rk3568-naneng-combphy (no driver attached) ofwbus0: mem 0xfe830000-0xfe8300ff compat = rockchip,rk3568-naneng-combphy (no driver attached) ofwbus0: mem 0xfe840000-0xfe8400ff compat = rockchip,rk3568-naneng-combphy (no driver attached) ofwbus0: mem 0xfe850000-0xfe85ffff disabled compat = rockchip,rk3568-mipi-dphy (no driver attached) ofwbus0: mem = 0xfe850000-0xfe85ffff,0xfe060000-0xfe06ffff disabled compat = rockchip,rk3568-video-phy (no driver attached) ofwbus0: mem 0xfe860000-0xfe86ffff disabled compat = rockchip,rk3568-mipi-dphy (no driver attached) ofwbus0: mem 0xfe870000-0xfe870fff disabled compat = rockchip,rk3568-csi-dphy (no driver attached) ofwbus0: mem 0xfe8a0000-0xfe8affff irq 103 compat = rockchip,rk3568-usb2phy (no driver attached) ofwbus0: mem 0xfe8b0000-0xfe8bffff irq 104 compat = rockchip,rk3568-usb2phy (no driver attached) ofwbus0: compat rockchip,rk3568-pinctrl (no driver attached) ofwbus0: disabled compat regulator-fixed (no driver = attached) ofwbus0: compat simple-audio-card (no driver attached) ofwbus0: compat simple-audio-card (no driver attached) ofwbus0: compat mmc-pwrseq-simple (no driver attached) ofwbus0: disabled compat wlan-platdata (no driver = attached) ofwbus0: disabled compat bluetooth-platdata (no = driver attached) crypto: assign cryptosoft0 driver id 0, flags 0x6000000 Device configuration finished. Found SMCCC version 1.2 procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached IPsec: Initialized Security Association Processing. tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768 mmc0: Probing bus usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 mmc0: SD 2.0 interface conditions: OK mmc0: SD probe: OK (OCR: 0x40ff8000) mmc0: Current OCR: 0x00ff8000 ugen3.1: at usbus3 uhub0 on usbus3 uhub0: on = usbus3 ugen2.1: at usbus2 uhub1 on usbus2 uhub1: on = usbus2 ugen1.1: at usbus1 uhub2 on usbus1 uhub2: on = usbus1 ugen0.1: at usbus0 uhub3 on usbus0 uhub3: on = usbus0 mmc0: Probing cards mmc0: New card detected (CID 1b534d303030303010616e064e00fa65) mmc0: New card detected (CSD 400e00325b590001dcff7f800a4040f1) mmc0: Card at relative address 0x0001 added: mmc0: card: SDHC 00000 1.0 SN 616E064E MFG 10/2015 by 27 SM mmc0: quirks: 0 mmc0: bus: 4bit, 50MHz (high speed timing) mmc0: memory: 125042688 blocks, erase sector 65536 blocks mmc0: setting transfer rate to 50.000MHz (high speed timing) mmcsd0: 64GB at mmc0 = 50.0MHz/4bit/1021-block Release APs...gic0: Start searching for Re-Distributor gic0: Start searching for Re-Distributor gic0: CPU3 Re-Distributor has been found gic0: CPU1 Re-Distributor has been found gic0: Start searching for Re-Distributor gic0: CPU3 Re-Distributor woke up gic0: CPU2 Re-Distributor has been found gic0: CPU3 enabled CPU interface via system registers gic0: CPU2 Re-Distributor woke up gic0: CPU1 Re-Distributor woke up gic0: CPU2 enabled CPU interface via system registers gic0: CPU1 enabled CPU interface via system registers done CPU 0: ARM Cortex-A55 r2p0 affinity: 0 0 GEOM: new disk mmcsd0 Cache Type =3D <64 byte D-cacheline,64 byte = I-cacheline,VIPT ICache,64 byte ERG,64 byte CWG> Trying to mount root from ufs:/dev/mmcsd0p6 [rw,noatime]... Instruction Set Attributes 0 =3D = mmc0: setting bus width to 4 bits high speed timing Instruction Set Attributes 1 =3D Processor Features 0 =3D Processor Features 1 =3D Memory Model Features 0 =3D = Memory Model Features 1 =3D Memory Model Features 2 =3D <32bit CCIDX,48bit VA,IESB,UAO,CnP> Debug Features 0 =3D <2 CTX BKPTs,4 Watchpoints,6 = Breakpoints,PMUv3+16 bit evtCount,Debugv8.2> GEOM: mmcsd0: the secondary GPT header is not in the last LBA. Debug Features 1 =3D <> GEOM_PART: partition 1 on (mmcsd0, GPT) is not aligned on 33554432 bytes Auxiliary Features 0 =3D <> GEOM_PART: partition 2 on (mmcsd0, GPT) is not aligned on 33554432 bytes Auxiliary Features 1 =3D <> GEOM_PART: partition 3 on (mmcsd0, GPT) is not aligned on 33554432 bytes CPU 1: ARM Cortex-A55 r2p0 affinity: 1 0 CPU 2: ARM Cortex-A55 r2p0 affinity: 2 0 CPU 3: ARM Cortex-A55 r2p0 affinity: 3 0 Unresolved linked clock found: clk_32k_pvtm Unresolved linked clock found: dummy Unresolved linked clock found: usb480m_phy Unresolved linked clock found: clk_ddr1x Unresolved linked clock found: gpu_pvtpll_out Unresolved linked clock found: npu_pvtpll_out Unresolved linked clock found: gmac0_clkin Unresolved linked clock found: clk_gmac0_xpcs_mii Unresolved linked clock found: clk_gmac1_xpcs_mii GEOM: diskid/DISK-616E064E: the secondary GPT header is not in the last = LBA. GEOM_PART: partition 1 on (diskid/DISK-616E064E, GPT) is not aligned on = 33554432 bytes GEOM_PART: partition 2 on (diskid/DISK-616E064E, GPT) is not aligned on = 33554432 bytes GEOM_PART: partition 3 on (diskid/DISK-616E064E, GPT) is not aligned on = 33554432 bytes Warning: no time-of-day clock registered, system time will not be set = accurately Dual Console: Serial Primary, Video Secondary start_init: trying /sbin/init uhub0: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, = generating a new one Setting hostuuid: 061ad261-e7c6-11eb-96c8-fd2cd2da4159. Setting hostid: 0xa910a001. Starting file system checks: /dev/mmcsd0p6: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0p6: clean, 8461 free (173 frags, 1036 blocks, 0.1% = fragmentation) GEOM: diskid/DISK-616E064E: the secondary GPT header is not in the last = LBA. GEOM_PART: partition 1 on (diskid/DISK-616E064E, GPT) is not aligned on = 33554432 bytes GEOM_PART: partition 2 on (diskid/DISK-616E064E, GPT) is not aligned on = 33554432 bytes GEOM_PART: partition 3 on (diskid/DISK-616E064E, GPT) is not aligned on = 33554432 bytes Mounting local filesystems:random: randomdev_wait_until_seeded unblock = wait random: unblocking device. . ELF ldconfig path: /lib /usr/lib /usr/lib/compat Building /boot/kernel/linker.hints Setting hostname: Quartz64. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,A= TTACH,CACHED Feeding entropy: . lo0: link state changed to UP Starting Network: lo0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D680003 inet 127.0.0.1 netmask 0xff000000 groups: lo Starting devd. add host 127.0.0.1: gateway lo0 fib 0: route already in table Clearing /tmp (X related). Updating /var/run/os-release done. Creating and/or trimming log files. Updating motd:. Setting date via ntp. Error resolving gps.dix.dk: Name does not resolve (8) 18 Jul 12:45:48 ntpdate[792]: Can't find host gps.dix.dk: Name does not = resolve (8) 18 Jul 12:45:48 ntpdate[792]: no servers can be used, exiting Mounting late filesystems:. Setting disk spindown:. Generating RSA host key. 2048 SHA256:zFbhjf2DGQGlmWoQ67jvnyl9Wem1Hgq2gjC+iESJ1d8 root@Quartz64 = (RSA) Generating ECDSA host key. 256 SHA256:lyTFZaXM1WiGWJ1RApWoR1dtF2tA1BV7DUu2HgbAjGI root@Quartz64 = (ECDSA) Generating ED25519 host key. 256 SHA256:TUu2B8YGGh+vwQuDJUd9p88NdPuu8biCC6vxSvhNe/U root@Quartz64 = (ED25519) Performing sanity check on sshd configuration. Starting sshd. Starting background file system checks in 60 seconds. Sun Jul 18 12:45:49 UTC 2021 -- S=C3=B8ren Schmidt sos@deepcore.dk / sos@freebsd.org "So much code to hack, so little time" --Apple-Mail=_521145A4-77A2-4FA7-AE63-FD4E727FC8D4-- From nobody Sun Jul 18 13:48:55 2021 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 6305512A78A8 for ; Sun, 18 Jul 2021 13:50:35 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (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 "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GSRFQ2HGRz4bwV for ; Sun, 18 Jul 2021 13:50:33 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sun, 18 Jul 2021 15:48:55 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1626616226; bh=wqsrrZVYDJxCRQ65NP6+PxZM/Y7d28XCgDpqKIaITvQ=; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; b=jQ3BP+3RSVhuFSBfJWbKm9MN/H+wAwzxtsCeZMhYb9PxTB7NJxngdPZYjPLorDV4P mMx/zajivnXZ4dkEid6+nSKd8kTCTrH3YHnpqWnn7t3a6sEorpXBtF0wSolE9Mpwlx O8kf9NHtFbOAT/FDFtOHdJ0prP0ctLy0wWYLfzn1W/tK4v/zHVBPoTjQK+evQN22VT ZH36bIrmCfjbcauQop9ambpKTeNgdrO6N9FYH8XuEsix13TVWbb9cgXicaqo+bjrK8 PUrSp4ahOXYzu/1KtCGH1jQX7ReD9SGc7zRBW7QWodT7gFpVjvjAoYQC8R719YsliN Rk1Nb1q+e5PXA== Message-ID: <87k0lnybp4.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: git: 1dec3639fd0c - main - sysutils/u-boot: Update to 2021.07 In-Reply-To: References: <202107071618.167GIvXd048504@gitrepo.freebsd.org> <874kd3390q.wl-herbert@gojira.at> <87o8b8n1rf.wl-herbert@gojira.at> <87mtqsn0we.wl-herbert@gojira.at> <20210712115010.a405a8f5e313ec75142fa544@bidouilliste.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 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 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4GSRFQ2HGRz4bwV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=jQ3BP+3R; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [0.17 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.33)[-0.326]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On Mon, 12 Jul 2021 13:44:43 +0200, "Herbert J. Skuhra" wrote: > This happens even with the official builds! > > FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210701-6aee7855180-246143.img.xz > ==> OK (U-Boot 2021.04) > FreeBSD-13.0-STABLE-arm64-aarch64-RPI-20210708-f6d448caf69-246212.img.xz > ==> Not OK. (U-Boot 2021.07) > > I am using U-Boot 2021.04 again because I still don't know how to boot > from mmc device 2 automatically. With the below patch my RPI 3 Model B (0xa02082) boots again: --- include/configs/rpi.h.orig 2021-07-18 15:37:55.743031000 +0200 +++ include/configs/rpi.h 2021-07-18 15:38:51.159286000 +0200 @@ -173,7 +173,8 @@ #if CONFIG_IS_ENABLED(CMD_MMC) #define BOOT_TARGET_MMC(func) \ func(MMC, mmc, 0) \ - func(MMC, mmc, 1) + func(MMC, mmc, 1) \ + func(MMC, mmc, 2) #else (sysutils/u-boot-rpi3 / U-Boot 2021.07) -- Herbert From nobody Sun Jul 18 21:00:23 2021 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 3F38B8D58B8 for ; Sun, 18 Jul 2021 21:00:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GScnM6zgBz4mW6 for ; Sun, 18 Jul 2021 21:00:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 D09542637 for ; Sun, 18 Jul 2021 21:00:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 16IL0NdL016072 for ; Sun, 18 Jul 2021 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16IL0N12016071 for freebsd-arm@FreeBSD.org; Sun, 18 Jul 2021 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202107182100.16IL0N12016071@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 18 Jul 2021 21:00:23 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16266420238.B9a9d.15449" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16266420238.B9a9d.15449 Date: Sun, 18 Jul 2021 21:00:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. --16266420238.B9a9d.15449--